Google’s August 11 Chrome 151 Stable update closed five high-severity use-after-free flaws across five browser surfaces. Managed Windows, macOS, and Linux endpoints remain exposed to the published defects until the running browser reaches the fixed release line and restarts.
The Chrome 151 Stable update moved Windows and macOS to 151.0.7922.137/.138 and Linux to 151.0.7922.137. Google described a rollout over days or weeks. That schedule makes fleet state the important fact: an available update does not show that a browser has installed it.
Five faults share one release
Google classified all five findings as use-after-free flaws. It has restricted the underlying bug records, so the public release does not establish a shared trigger, exploit path, or practical impact beyond the affected component names.
The release covers CVE-2026-19556 in V8, CVE-2026-19557 in TabStrip, CVE-2026-19558 in Extensions, CVE-2026-19559 in HTML, and CVE-2026-19560 in Blink. Google rated every one High.
Figure details
One Chrome 151 Stable release branches to five component cards. CVE-2026-19556 maps to V8 and Jihyeon Jeong, CVE-2026-19557 to TabStrip and Google, CVE-2026-19558 to Extensions and @bean5oup, CVE-2026-19559 to HTML and Google, and CVE-2026-19560 to Blink and Huynh Dinh Vu. Every branch is rated High and shares Chrome 151.0.7922.137 or the Windows and macOS .138 build as the fixed release line.
Google awarded Jihyeon Jeong of Seoul National University’s Compsec Lab $500 for the V8 report. It credited @bean5oup for the Extensions finding, Huynh Dinh Vu for the Blink finding, and its own researchers for TabStrip and HTML.
Restricted details hide exposure
“This update includes 5 security fixes,” Google wrote. Its release record does not report active exploitation, victims, or a public proof of concept. It also does not quantify how many browsers remained on a vulnerable build when the staged rollout began.
Google is withholding bug details until most users receive the fixes. That limits precise detection engineering: defenders cannot derive a reliable exploit signature from the advisory alone. A crash, renderer anomaly, or extension event may deserve investigation, but none is a published campaign indicator for these CVEs.
The shared weakness class also does not establish one common attack path. Treat the five component boundaries separately during incident review. A browser process crash and an unexpected extension event carry different context even when both ultimately involve unsafe object lifetime.
Measure the installed build
Inventory the running Chrome version across managed Windows, macOS, and Linux endpoints. The expected result is 151.0.7922.137 or .138 on the Chrome 151 line. Any later Chrome release supersedes these builds and also clears this version check.
Force the normal update and browser-restart workflow on lagging devices, then query the inventory again. A successful deployment ends with no active endpoint below 151.0.7922.137. Record devices that cannot update, isolate their browser use from untrusted sites and extensions, and track the exception until the browser reaches a superseding release.
Use browser-management telemetry to compare the installed version with the device’s last check-in and last restart. The verification test is concrete: every in-scope endpoint reports a running build at or above 151.0.7922.137 after the deployment window. An update policy or deployment receipt is only the expected state; the reported running build is the measured result.