Google promoted Chrome 152 to the stable channel on August 25, 2026, and the update carries 327 security fixes across Windows, Mac, and Linux. The one worth paying attention to is CVE-2026-79282, a critical use-after-free vulnerability in ANGLE, the graphics layer Chrome uses to translate WebGL and other rendering calls into your GPU’s native API. A remote attacker could trigger it with nothing more than a crafted HTML page, and it lets code run outside the browser’s sandbox. Google paid the reporting researcher, credited only as “Goodluck,” a $25,000 bounty for the find.
What Chrome 152 actually fixes
The ANGLE flaw is the standout, but it’s one bug among hundreds. The release notes list dozens more use-after-free and memory corruption issues across Aura, Chromecast, Views, Bluetooth, and the sandbox itself, most reported internally by Google’s own security team rather than external researchers. That volume is normal for a major version bump, not a sign of an unusually bad month for Chrome specifically.
Google is rolling the update out gradually “over the coming days/weeks,” so not everyone gets it the moment it ships. If you want to check your own build, go to Chrome’s menu, then Help, then About Google Chrome, and it will update on the spot if it hasn’t already.
This is the second Chrome patch worth flagging in about a week. Chrome 151 fixed two critical sandbox-escape bugs in WebGL and Dawn on August 19, and this release lands a similar kind of fix in the same general rendering subsystem again.
What to actually do about it
For most people this update is invisible. Chrome auto-updates in the background and just needs a restart to apply it. A few situations are worth a manual check instead of assuming it’s handled:
- Managed or kiosk devices where an IT policy pins Chrome to a specific build.
- Electron apps or embedded WebViews that bundle their own Chromium runtime instead of relying on the system browser.
- Headless browser testing or scraping infrastructure pinned to a Chrome version in CI.
None of this requires a code change on your own site. It’s a browser-side fix, not something in your stack that needs a release. If you’d rather not track browser patch cycles and version pins yourself, that kind of ongoing check is part of what a Website Development Care Plan is built to catch.
