Google shipped an emergency Chrome Stable update on September 3 and confirmed that one of the twelve bugs it patched is already being exploited in the wild. The flaw, CVE-2026-85046, is a type confusion vulnerability in V8 with a CVSS score of 8.8. It is the sixth actively exploited Chrome zero-day of 2026, and all six have carried the same 8.8 rating, which is either a coincidence or a pricing signal.
The fixed versions are 152.0.7977.82/.83 on Windows and macOS and 152.0.7977.82 on Linux. The rollout is gradual, which means a fully patched Chrome today may not actually be patched yet. If your organization depends on auto-update, check the version string and force the update rather than waiting for the schedule.
What the bug actually is
V8 is Chrome’s JavaScript and WebAssembly engine, and its optimizing compilers, Maglev and TurboFan, guess aggressively about what types your objects will be so they can generate fast machine code. When those guesses break, you get type confusion: memory laid out for one type gets interpreted as another. The researcher who reported this one, Salvatore Gulizia (Serotav), described it as an array carrying the PACKED_ELEMENTS map receiving the PACKED_SMI_ELEMENTS map instead, which can be turned into arbitrary read and write on the JavaScript heap. The bug existed in both compiler pipelines.
In practice, a specially crafted HTML page can trigger the confusion and give an attacker code execution inside Chrome’s sandboxed renderer process. That is a serious foothold and a bad afternoon, but it is not automatically full machine compromise. Escaping the renderer sandbox to own the operating system requires chaining a second vulnerability, typically a sandbox escape or privilege escalation bug. Google has not said whether in-the-wild attacks were paired with an escape, and the underlying Chromium issue tracker stays restricted while the update propagates. Treat that as an open question, not a reassurance.
Gulizia reported the bug on August 4 and received a $1,000 bounty. It took a month from report to emergency patch, and the exploit was live before the fix. A thousand dollars against whatever a working renderer exploit sells for on the gray market tells you roughly how much the bounty program is buying relative to what attackers can pay. Google withholds technical details for actively exploited bugs, which is the right call, but the economics still look lopsided.
The blast radius is bigger than Chrome
Every Chromium-based browser inherits this one. Microsoft Edge, Brave, Opera, and Vivaldi all carry V8 and need their own downstream patches on their own release cadence, which in practice means days or weeks after Google’s fix. Firefox (SpiderMonkey) and Safari (JavaScriptCore) run different engines and are not affected by this specific bug, though neither browser has a clean record on engine-level zero-days either. If you manage browser fleets, the CVE matters more than the product name: scan for Chromium-family browsers below their respective patched builds.
The 2026 pattern
The six exploited Chrome zero-days fixed so far this year, per Google’s advisories: CVE-2026-2441, use-after-free in CSS (February); CVE-2026-3909, out-of-bounds write in Skia, and CVE-2026-3910 in the V8 engine (March); CVE-2026-5281, use-after-free in Dawn, the WebGPU component (April); CVE-2026-11645, out-of-bounds access in V8 (June); and now CVE-2026-85046 (September). Memory corruption in the renderer is the constant. Four of the six are V8 or V8-adjacent, which says the compiler pipeline remains the softest part of the browser despite years of hardening work.
What to do this week
Update Chrome to 152.0.7977.82 or later and relaunch, on every machine you control, including the ones people use for demos and the kiosks nobody remembers. Fleets on Chrome Browser Cloud Management or MDM can push the restart centrally, which is worth doing today rather than waiting for the gradual rollout to reach you. After patching, it is worth having your EDR look backwards: renderer crashes followed by unexpected child processes, or visits to sketchy domains immediately before anomalous activity, are the signals that matter. Google has not published indicators of compromise, so process telemetry is what you have.
Nothing about this update is unusual, which is the point. Six exploited zero-days in eight months means browser patch latency is now a real attack surface, and the teams that treat Chrome updates as urgent deployable changes are simply correct.
A note on renderer exploits and reality
It helps to be precise about what an in-sandbox exploit gets an attacker, because the panic cycle around every Chrome zero-day tends to blur it. The renderer process is where web content runs, and Chrome’s sandbox strips most of its rights: no arbitrary file reads, no process creation, no network access outside the broker’s rules. A renderer RCE gives an attacker the page’s own powers, plus a toehold for finding a second bug. That is still enough for cookie theft within the browser context, drive-by payloads, and reconnaissance of anything the profile can touch. And the second bug is not hypothetical: renderer-plus-sandbox-escape chains are the standard product in exploit markets, and a V8 bug this exposed is exactly the kind of thing bought to pair with a kernel or broker flaw later.
For defenders the practical translation is simple. Patch speed is the whole game on bugs Google confirms as exploited, because the exploit exists whether or not it is efficient. Every hour a fleet spends below 152.0.7977.82 is an hour with a known, purchased, working exploit against it.