HIGH: Chrome V8 Zero-Day CVE-2026-85046 Exploited in the Wild

Six. That is how many actively exploited Chrome zero-days Google has patched in 2026, and there are still four months left on the calendar. The latest one landed on September 3, when Google pushed a Stable Channel update that closed twelve security holes. One of them was already being used against real people before most of us had finished our first coffee of the day.

The flaw is CVE-2026-85046, a type confusion bug in V8, the JavaScript and WebAssembly engine that powers Chrome and every Chromium derivative you have ever installed. It carries a CVSS score of 8.8, which puts it in high severity territory rather than critical. If that number tempts you to slow walk this one, resist. Google's advisory includes the line that matters far more than any score, confirming that an exploit for CVE-2026-85046 exists in the wild. That is the vendor's measured way of telling you somebody is already using this against actual humans.

The bug itself

Type confusion sounds abstract until you look at what is happening underneath, and this one is a textbook example of why V8 keeps generating zero-days.

Salvatore Gulizia, who works under the handle Serotav, reported the issue to Google on August 4, 2026. His technical summary describes a V8 bug in the compilers that causes an array containing PACKED_ELEMENTS to receive the map PACKED_SMI_ELEMENTS, which can then be turned into arbitrary read and write access on the JavaScript heap.

Translated out of engine internals, V8 speeds up JavaScript by tracking what kind of values an array holds. An array tagged PACKED_SMI_ELEMENTS is promised to contain nothing but small integers, so the engine can treat its contents as raw numbers and skip a pile of expensive safety checks. An array tagged PACKED_ELEMENTS can hold arbitrary objects, which in memory means pointers. When the optimizing compiler hands an array full of real object pointers a map that swears it holds only small integers, the engine starts doing arithmetic on values that are actually memory addresses. From there an attacker can read memory that should be off limits and write values where they do not belong. Arbitrary read and write access on the JavaScript heap is not the end of an attack, it is the foundation that every serious browser exploit chain gets built on top of.

Google paid Gulizia a thousand dollars for it. A bug that is currently being exploited in the wild, in the most widely deployed piece of software on the planet, went for roughly the price of a decent laptop. Make of that what you will.

The other eleven fixes in this release did not come with an in the wild caveat, which is the only reason they are not the story. The pattern across 2026 is worth sitting with, though. February brought CVE-2026-2441, a use after free in CSS. March delivered two in a single month, an out of bounds write in the Skia graphics library tracked as CVE-2026-3909 alongside CVE-2026-3910 in V8 itself. April added CVE-2026-5281, a use after free in the Dawn WebGPU component, and June contributed CVE-2026-11645, an out of bounds memory access back in V8 again. Every one of them carried a CVSS score of 8.8, and every one of them was being exploited before a patch existed. V8 accounts for three of the six, which is not a coincidence. A just in time compiler whose entire job is turning untrusted script into native code is doing the hardest work in the browser, and it has the bug density to prove it.

Who needs to care

Anything running Chrome older than 152.0.7977.82 is exposed. Google shipped 152.0.7977.82 and .83 for Windows and macOS, and 152.0.7977.82 for Linux, with the rollout happening gradually over the coming days and weeks. That gradual rollout language is the part that quietly hurts you, because a machine that checked for updates this morning may still be sitting on a vulnerable build tonight through no fault of anyone in your organization.

The blast radius extends well past Chrome itself. V8 is Chromium's engine, so Microsoft Edge, Brave, Opera, Vivaldi and the rest of the Chromium family inherit the same defect and depend on their own vendors to ship rebuilt binaries on their own timelines. The uglier long tail is Electron. Every desktop application built on Electron bundles its own private Chromium runtime, which means the messaging client, the ticketing app and the internal tool your developers wrote three years ago are each carrying a copy of V8 that no browser update will ever reach. Those get fixed when the application vendor decides to rebase onto a newer Chromium, and a fair number of them are shockingly slow about it.

How this looks in the wild

Exploitation is drive by, which is the polite industry term for the user did nothing wrong. A victim visits a malicious page or, far more commonly, a legitimate page carrying a malicious ad or an injected script. Crafted JavaScript runs automatically, corrupts memory through the type confusion and executes attacker controlled code inside the renderer process. There is no attachment to open, no macro to enable and no installer to click through.

It is worth being honest about the boundary here rather than overselling the panic. Code execution in V8 lands an attacker inside Chrome's renderer sandbox, not directly on your bare operating system. Turning renderer access into full host compromise normally requires a second vulnerability to escape that sandbox, which is why sophisticated operators collect and chain these bugs rather than firing them off alone. That is not a reason to relax. A foothold in the renderer already exposes session cookies, authentication tokens and page content for whatever that browser process is handling, and the actors who tend to be holding working Chrome zero-days are precisely the ones who also hold sandbox escapes. Commercial spyware vendors and state aligned groups have been chaining exactly this combination for years.

Google is withholding the specifics for now, noting as it always does that bug details and links stay restricted until a majority of users have updated. That is standard practice and entirely reasonable, though it does mean defenders spend the next few weeks patching partly on faith. Expect technical writeups and public proof of concept code to surface once that window closes, at which point the population of people capable of exploiting this expands from a handful of well funded teams to anyone who can copy and paste.

Fixing it properly

Patching Chrome is easy, and that is exactly why it gets done badly.

Chrome downloads updates in the background, but it does not apply them until the browser actually restarts. Every environment has that one user with forty tabs open who has not closed Chrome since sometime in July. Their browser has the fix sitting on disk and is still cheerfully running the vulnerable code. Verifying you are on 152.0.7977.82 or later means checking the version and forcing the relaunch, not trusting that auto update quietly did its job.

At any real scale, do this with policy rather than a politely worded email. Chrome Enterprise gives you RelaunchNotification and RelaunchNotificationPeriod, which together let you tell managed browsers to nag and then force a restart inside a window you define. Somewhere between twenty four and forty eight hours is a sane setting for an actively exploited renderer bug. Chrome Enterprise Core reports installed versions back to a console, which converts the awkward question of how many vulnerable browsers do we actually have into a number you can look at directly. If you do not have that in place, your RMM can inventory the Chrome executable version across every endpoint in a few minutes and give you the same answer.

Then repeat the whole exercise for Edge and any other Chromium browser your users have quietly installed, and go find your Electron applications. That second inventory is usually the uncomfortable one.

On detection, browser exploitation is noisy in a fairly specific way once it succeeds. Renderer processes spawning command interpreters is the signal worth alerting on, so any chrome.exe or msedge.exe parent process launching cmd, powershell, rundll32 or wscript deserves immediate attention rather than a ticket in the morning queue. Watch for unexpected child processes under the browser generally, and for browser initiated connections out to freshly registered domains. If your EDR supports weighting it, treating browser process trees as high value telemetry for the next month is a cheap posture change that costs you nothing but attention.

The MSP angle

An actively exploited browser flaw is the easiest conversation you will ever have with a client who has been putting off centralized browser management, because everyone in the building uses Chrome and nobody has been auditing which version they run. Package browser lifecycle management, enforced relaunch policy and version reporting into your managed endpoint tier and price it as an ongoing service rather than a one time cleanup. The Electron inventory problem is a quieter second upsell, since almost nobody has a list of which applications ship their own Chromium runtime, and building that list is billable discovery work that leads naturally into a broader software asset management engagement.

Patch now, force the relaunch, verify the version number yourself. This is the sixth time this year, and it will not be the last.