Chrome’s 327 Security Fixes Were Only the Warm-Up
Update, 6 September 2026: Google has confirmed that an exploit for CVE-2026-85046 exists in the wild. The high-severity type-confusion vulnerability affects V8 and can let a remote attacker execute arbitrary code inside the Chrome sandbox through a crafted HTML page.
Chrome 152 Is No Longer Just a Patch Story
This is a newly fixed vulnerability in a later Chrome 152 security update. It is not confirmation that attackers are exploiting any of the ten critical flaws discussed in the original article. Google’s 3 September release moves the fixed desktop build to 152.0.7977.82 on Linux and 152.0.7977.82 or 152.0.7977.83 on Windows and macOS.
CISA added CVE-2026-85046 to its Known Exploited Vulnerabilities catalogue on 4 September and set 18 September 2026 as the due date for US Federal Civilian Executive Branch agencies covered by its directive. For other organisations, KEV status is an authoritative exploitation signal and a strong prioritisation input, not a universal regulatory deadline.
The operational status has changed. Organisations should verify the Chrome build that is actually running, complete a browser restart where required and prioritise devices that remain below the fixed version.
Google has released Chrome 152 with fixes for 327 security vulnerabilities, including ten rated critical. The scale of the release matters, but the operational question is simpler: organisations need to verify the version that is actually running, not merely assume that the browser has downloaded an update.
The original stable desktop channel moved to 152.0.7977.64 on Linux and 152.0.7977.64 or 152.0.7977.65 on Windows and macOS. Those builds are now superseded. The current fixes are 152.0.7977.82 or 152.0.7977.83 on Windows and macOS, and 152.0.7977.82 on Linux.
Google’s original Chrome 152 bulletin listed 10 critical, 61 high, 184 medium and 72 low-severity fixes. It did not say that any of those flaws was being exploited, and BlackTree found no credible public proof of concept for the ten critical vulnerabilities at the time of writing. The later 3 September bulletin changed the broader Chrome 152 risk picture by adding a separate V8 flaw, CVE-2026-85046, that Google confirms has an exploit in the wild.
Ten critical flaws converge on browser trust boundaries
Eight of the ten critical vulnerabilities are use-after-free or related memory-safety failures. They affect several components that sit close to rendering, interface or device-integration boundaries:
- CVE-2026-79282: use after free in ANGLE, the translation layer used by Chrome for graphics APIs. Google credited external researcher Goodluck and listed a $25,000 reward.
- CVE-2026-79290: use after free in Aura, Chrome’s cross-platform user-interface framework.
- CVE-2026-79054: use after free in Chromecast.
- CVE-2026-79121: improper input validation in Chromecast.
- CVE-2026-79224: use after free in Chromecast.
- CVE-2026-79052: use after free in Aura.
- CVE-2026-79150: use after free in Views, another part of Chromium’s interface framework.
- CVE-2026-78935: use of an uninitialised variable in Mobile.
- CVE-2026-79012: use after free in SafeBrowsing.
- CVE-2026-79200: use after free in Aura.
The public CVE records describe the critical class in terms of a crafted HTML page potentially leading to arbitrary code execution outside Chrome’s sandbox. The precise route and prerequisites differ by component, and Google is restricting access to detailed bug reports until a majority of users have received the update. That disclosure policy limits immediate technical validation, but it also reduces the amount of implementation detail available to attackers during the rollout.
The evidence changed, but not for the original ten critical flaws
The distinction between the two Chrome 152 bulletins matters. Google has not said that any of the ten critical vulnerabilities from the original release is being exploited. Its exploitation warning applies to CVE-2026-85046, a high-severity V8 type-confusion flaw fixed in the later 3 September update.
A crafted HTML page can trigger the vulnerability and execute arbitrary code inside the browser sandbox. Google has not publicly described the attacks, targets or exploit chain. The confirmed exploitation is still enough to move every desktop below the fixed build into the urgent patch queue.
A 327-fix release tests the patching system
The number 327 is striking, but it does not mean every enterprise faces 327 equally practical attack paths. Many findings were detected through Google’s internal testing, sanitizers, fuzzing and automated analysis. Severity, reachability, platform and attacker prerequisites still determine practical risk.
For defenders, the larger concern is deployment certainty. Chrome can download an update in the background while continuing to run the vulnerable build until it is restarted. A staged vendor rollout can also leave devices on different versions, even when they share the same management policy. Virtual desktop pools, long-lived kiosk sessions and rarely restarted endpoints are especially easy to miss.
The release also affects more than unmanaged desktop installations. Security teams should account for managed Windows, macOS and Linux fleets, Android devices, embedded or kiosk deployments, virtual desktops and other Chromium-based products that consume upstream fixes on their own schedules. A Chrome release is the start of that verification work, not proof that every Chromium browser is already protected.
What defenders should do now
- Verify the running version. On desktop, open
chrome://settings/helpand confirm 152.0.7977.82 or later on Windows, macOS and Linux. - Complete the restart. A downloaded update does not replace the active browser process until Chrome restarts. Use endpoint or browser-management telemetry to confirm the fixed process is running.
- Measure the estate. Use browser-management or endpoint telemetry to identify devices that remain below the fixed build, including inactive endpoints and persistent sessions.
- Check adjacent Chromium products. Edge, Brave, Opera and embedded Chromium runtimes follow separate release schedules. Track their vendor advisories instead of assuming the Chrome build number applies.
- Prioritise exposed and high-value users. Accelerate deployment for administrators, developers, finance teams and other groups likely to handle untrusted web content or sensitive sessions.
- Watch for more exploitation detail. Google has confirmed an exploit in the wild but has not disclosed targets, attack volume or whether the browser-sandbox foothold was paired with a second vulnerability.
The restart is now part of the incident response
Chrome 152 began as an unusually large security release. The later discovery of active exploitation does not rewrite the status of its original ten critical flaws, but it does change the urgency of the version running on every endpoint.
Automatic updates reduce risk only after the fixed build reaches the device and the browser restarts. With CVE-2026-85046 being exploited in the wild, proving that transition is no longer routine patch hygiene. It is the control that separates a patched fleet from an exposed one.
Sources
- Google Chrome Releases: Stable Channel Update for Desktop, published 3 September 2026. The page provides no publication time.
- Canadian Centre for Cyber Security: Google security advisory AV26-883, published 4 September 2026. The page provides no publication time.
- CISA Known Exploited Vulnerabilities catalogue entry for CVE-2026-85046, added 4 September 2026, with a due date of 18 September 2026 for covered US federal agencies.
- Google Chrome Releases: Stable Channel Update for Desktop, published 25 August 2026. The source provides no publication time.
- NVD record for the first listed critical vulnerability, published 25 August 2026 at 17:18:22 UTC.
- SecurityWeek: Chrome 152 Patches Over 300 Vulnerabilities, published 26 August 2026 at 05:50 ET.
