Chrome 154 Security Update Fixes 108 Flaws

The Chrome 154 security update is rolling out to Windows, macOS and Linux with 108 security fixes, including 11 vulnerabilities Google rates critical. The practical priority is simple: organisations should verify that managed browsers reach Chrome 154.0.8037.57 on Linux and 154.0.8037.57 or .58 on Windows and Mac, while treating the unusually broad patch set as a deployment event rather than a routine background update.

Chrome 154 security update: what changed

Google’s September 22 stable-channel notice lists four platform-specific desktop builds and says some bug details will remain restricted until most users have received fixes. That disclosure practice matters: defenders have enough information to prioritise the update, but not necessarily enough to model every exploit path immediately.

The critical group includes buffer overflows in ANGLE and WebGL, out-of-bounds writes affecting GPU and WebGL components, and use-after-free defects in ServiceWorker, Fullscreen, WindowDialog and AdFilter. SecurityWeek reports that nine of the 11 critical issues came from external researchers, while Google found the rest internally.

Release fact	Verified value
Stable date	September 22, 2026
Total security fixes	108
Critical vulnerabilities	11
Desktop versions	154.0.8037.57 on Linux; .57/.58 on Windows and Mac

Why the patch count needs context

A count of 108 does not mean 108 bugs are being exploited. Google’s notice does not identify any Chrome 154 flaw as actively exploited, and Lapaas Voice found no primary statement making that claim. The risk signal comes instead from the concentration of critical memory-corruption defects in browser components that process untrusted web content.

The release also lands after Chrome 153 fixed an exploited V8 zero-day. That history should raise operational urgency without turning an undisclosed exploit possibility into a reported fact.

The two-week cadence changes patch operations

Chrome 154 is the first full milestone under Google’s new two-week stable cycle. Google announced that shift in March and said shorter milestones should reduce the time between fixes entering the codebase and reaching users. Our earlier explainer on Chrome’s two-week release cycle covers the schedule change.

For enterprises, faster milestones change the bottleneck. Testing, extension compatibility checks and restart enforcement now have less room to drift. A sound response is to stage the build to a representative group, monitor browser crashes and policy regressions, and then expand deployment while checking that devices actually relaunch into the patched version.

Chrome 154 is not merely a large list of CVEs; it is a test of whether browser patch operations can keep pace with shorter release intervals. Organisations that measure only package distribution can miss devices that downloaded an update but have not restarted, leaving the vulnerable process running.

What administrators should verify

Google says the build will roll out over days or weeks, so absence from a device at the first check is not proof of a failed policy. Administrators should compare the active browser version, restart state and platform build, then document temporary exceptions. Teams can also use the risk-oriented approach described in our report on CISA’s vulnerability bulletin shift: prioritise exposure and exploitability, not raw counts alone.

Bug details may remain restricted while adoption grows. That is another reason to keep claims narrow: the verified facts are the release versions, the 108-fix total, the 11 critical issues independently counted by SecurityWeek, and the classes of defects named in Google’s advisory.

FAQs

What version contains the Chrome 154 fixes?

Google lists 154.0.8037.57 for Linux and 154.0.8037.57 or .58 for Windows and macOS.

Are any Chrome 154 flaws being exploited?

Google’s release notice does not say that any of the Chrome 154 vulnerabilities are under active exploitation.

Why are Chrome milestones arriving faster?

Google moved stable milestones from four weeks to two weeks to deliver fixes and platform changes sooner while keeping each release smaller.

What is the main enterprise action?

Verify the active browser version after restart across managed devices, rather than relying only on evidence that the package downloaded.