Chrome patches its sixth exploited zero-day of 2026, a V8 type confusion
On September 4, 2026, Google shipped an emergency Chrome update fixing CVE-2026-85046, a type confusion in the V8 engine already exploited in the wild and rated 8.8 on the CVSS scale. Update to Chrome 152.0.7977.82 or later and check every Chromium browser in your fleet, including Edge, Brave and Opera.
September 4, 2026. Google ships an emergency Chrome update fixing CVE-2026-85046, a type confusion in the V8 engine already exploited in the wild. August 4, 2026. Researcher Salvatore Gulizia, known as Serotav, had reported the flaw and earned a $1,000 bounty. 2026. It is the sixth actively exploited Chrome zero-day Google has patched since January. Why it matters: visiting a crafted page is enough to trigger the exploit, and the flaw lives in V8, the component shared by every Chromium browser — not just Chrome.
A type confusion in V8, the black box
The flaw is a textbook type confusion. V8 runs JavaScript and WebAssembly at near-native speed thanks to its JIT compilers — TurboFan and Maglev — which make aggressive assumptions about variable types based on profiling. When a compiler gets an object’s type wrong, it treats one kind of data as another: exactly what happens here.
Google rates the vulnerability high severity, with a CVSS 8.8 score. An attacker can craft web content that pushes V8 to mishandle memory. Depending on the exploit chain, the outcome ranges from a crash to running attacker-controlled code inside Chrome’s renderer process. The vector is trivial: a malicious or compromised page, a phishing link, a poisoned ad.
What the bug actually does
The technical analysis published by Gulizia details the mechanism. V8 tracks object structure through Maps, hidden classes that describe an object’s shape and, for arrays, their element kind. Two kinds sit at the heart of the exploit: PACKED_SMI_ELEMENTS, a dense array of small integers stored inline, and PACKED_ELEMENTS, a generic array that can hold objects, floats and pointers.
The vulnerability fires when the compiler lets an array initialized as PACKED_ELEMENTS receive the Map of a PACKED_SMI_ELEMENTS array. That mismatch breaks memory safety in two ways. On read, V8 believes it is reading integers while the memory holds real pointers: the attacker leaks real addresses and defeats ASLR. On write, V8 writes an integer interpreted as a pointer into the backing store. Chaining the two primitives gives the attacker arbitrary read and write over the JavaScript heap — the holy grail of a browser exploit chain.
Google is not disclosing exploit details or targets, standard restraint for an active zero-day: as long as most users have not updated, publishing the mechanics is arming the opportunists and the botnets that scrape disclosures.
The sixth zero-day of the year
The statistic puts the problem in scale. CVE-2026-85046 is the sixth exploited Chrome zero-day fixed in 2026, after CVE-2026-2441, CVE-2026-3909, CVE-2026-3910, CVE-2026-5281 and CVE-2026-11645. Most target V8, by far the browser’s largest attack surface: it is the piece that runs untrusted web code at native speed.
The update does not contain only that fix. The Chrome release lists 12 security fixes in total, several of them high severity across V8, WebGL, the network component, DevTools, Skia, CacheStorage, compositing and crash reporting — an out-of-bounds write in WebGL, use-after-frees in compositing, DevTools and Skia, a race in V8. The fix moves Chrome to 152.0.7977.82/.83 on Windows and macOS, and 152.0.7977.82 on Linux.
None of the six bugs shares the same technical shape — use-after-free, race condition, type confusion — but all share the same origin: the complexity of a JIT compiler running untrusted code at native speed. The pattern is stable enough that security teams now plan for it the way they plan for Patch Tuesday: a Chrome zero-day is a matter of when, not if.
Who is exposed
The perimeter extends beyond Chrome. Every browser built on Chromium shares the same V8 engine: Microsoft Edge, Brave, Opera and Vivaldi are equally exposed to CVE-2026-85046. Each vendor runs its own update schedule, but upstream Chromium fixes are usually integrated quickly. An administrator cannot stop at patching Chrome: they must check every browser in the fleet.
On the enterprise side, the instruction is to verify managed endpoints have reached 152.0.7977.82 or later, and to watch endpoint telemetry and web-filtering logs for phishing campaigns using freshly registered domains or deceptive update prompts.
# Check the installed version on a Linux endpoint
google-chrome --version
# The result must be Chrome 152.0.7977.82 or higherHow the exploit reaches the victim
The trigger is web content: a victim only has to visit a malicious or compromised page for an exploit attempt to begin. Attackers then distribute the links through every usual channel — phishing emails, malicious advertisements, social media messages, compromised legitimate sites. Google has not disclosed the targets or the actors behind the active exploitation, but the real perimeter extends well beyond Chrome: every Chromium browser ships the same V8.
Google’s restraint on technical details is not discretion: it is defensive. As long as most users have not installed the fix, publishing the mechanism hands the opportunists and the botnets that scrape disclosures a ready-made proof of concept. That is why the advisory says an exploit “exists in the wild” without saying more.
Finally, the fix rolls out gradually, over several days and weeks. An administrator therefore cannot assume an endpoint is protected just because the version is out: they must check the installed version — 152.0.7977.82 or later — and relaunch the browser, since the fix only takes effect after a restart. For a managed fleet, verification runs through a browser inventory: an endpoint can have an up-to-date Chrome next to an Edge stuck on an older version, both vulnerable through the same V8. Enterprise management tooling — Chrome Enterprise, group policy or an MDM — can enforce a minimum version and confirm the restart, while telemetry and web-filtering logs should hunt freshly registered domains and deceptive update prompts.
Why V8 stays the number-one surface
V8 zero-days keep coming for a structural reason: JIT compilers trade safety margin for speed. The faster TurboFan and Maglev get, the more edge cases slip through testing — and the faster attackers, often state-sponsored groups or commercial surveillance vendors, find them. Google notes the update will roll out gradually over days: the window where an endpoint stays vulnerable is not zero.
That is why patching the browser is not enough defense. A sandbox escape — the leap from the renderer process to the system — remains the next step of any V8 chain, and that is where network segmentation, an EDR that flags renderer-process anomalies and site isolation take over. The question is not whether another V8 zero-day will come, but whether the rest of the stack stops it.
Verdict
For users, open Help → About Google Chrome, let the update download and relaunch the browser. Confirm the version reaches 152.0.7977.82 or higher.
For fleet administrators, do not stop at Chrome: check Edge, Brave, Opera and Vivaldi on managed endpoints and force a redeploy if a browser lags. An actively exploited V8 flaw is a known attack path, not a hypothesis.
For security teams, treat this sixth zero-day as the sign of an invariant: the JIT surface will keep producing bugs. An up-to-date browser is the first line, but segmentation, EDR and site isolation remain the only thing standing between a V8 exploit and full compromise.