Google released another Chrome 151 desktop security update on August 11, 2026. The fixed versions are 151.0.7922.137/.138 for Windows and macOS and 151.0.7922.137 for Linux. The release includes five high-severity use-after-free fixes.
This update follows the larger Chrome 151 release from the previous week. Organizations that completed that rollout still need to verify the newer build. “Chrome 151 installed” is no longer precise enough.
The five security fixes
- CVE-2026-19556 — use after free in V8.
- CVE-2026-19557 — use after free in TabStrip.
- CVE-2026-19558 — use after free in Extensions.
- CVE-2026-19559 — use after free in HTML.
- CVE-2026-19560 — use after free in Blink.
Google rated each issue high severity. The release post does not say that any of these vulnerabilities is being exploited in the wild. Do not add an active-exploitation claim merely because the bugs affect memory safety.
Why use-after-free matters
A use-after-free flaw occurs when software continues to use memory after the object that owned it has been released. An attacker may try to influence how that memory is reused and turn the resulting corruption into a crash, information disclosure, or code execution.
Real-world impact depends on the vulnerable component, available mitigations, exploit reliability, and whether a second vulnerability is needed to escape the browser sandbox. Defenders do not need to predict the final exploit chain before updating. The browser is a high-exposure application that processes untrusted content continuously.
Deployment steps
- Update policy. Confirm that Windows, macOS, and Linux management systems are targeting the new fixed build.
- Restart enforcement. A downloaded update may not protect a running browser process until Chrome restarts. Use user prompts and deadlines appropriate to the organization.
- Version verification. Measure the running version after restart rather than only the package staged on disk.
- Exception grouping. Separate failures into pending restart, unsupported OS, disabled update service, policy conflict, network restriction, and unmanaged installation.
- Derivative browsers. Check vendor advisories for Chromium-based browsers; do not assume their fixed build number or release timing matches Chrome.
Extensions deserve separate attention
One of the fixes affects the Extensions component. The vulnerability does not mean that every extension is malicious, but it reinforces the need to manage extension exposure. Maintain an allowlist for business environments, remove abandoned extensions, restrict developer mode, and monitor unexpected extension installation or permission changes.
Browser extensions operate close to sensitive browsing sessions. Reducing the extension set lowers both vulnerability exposure and the chance of malicious or compromised add-ons.
How to verify at scale
| Population | Evidence |
|---|---|
| Managed Windows/macOS | Browser telemetry with running version and last-seen time |
| Managed Linux | Package inventory plus active-process version |
| VDI and shared hosts | Base image version and persistent-session restart status |
| Unmanaged/BYOD | Access policy or browser-version signal where lawful and appropriate |
| Exceptions | Named owner, reason, temporary control, and expiration date |
Common reporting errors
Counting downloads as patched devices. The browser may still be running the old process.
Reporting only the major version. Multiple security releases can share Chrome 151.
Assuming auto-update covers every install. Portable packages, golden images, developer workstations, and disabled services often escape the standard path.
Calling every memory bug a zero-day. Google’s release did not report exploitation for these five CVEs.
Practical takeaway
Move the fleet to Chrome 151.0.7922.137/.138 or later, make users restart, and measure the running build. The operational lesson is simple: browser patching is a continuous control, not a monthly event.
