Chrome CVE-2026-85046: Exploited V8 Zero-Day, Update Now

Google's V8 JavaScript engine has produced its sixth actively exploited Chrome zero-day of 2026, and this one carries a lesson that infrastructure teams keep filing under "not my problem." CVE-2026-85046 is a type confusion bug that gives an attacker arbitrary read and write on the JavaScript heap, and Google has confirmed a working exploit is already circulating. For the servers you run, a browser flaw reads like an endpoint concern. It is really the shortest path an attacker has to the workstation that holds your keys.

What CVE-2026-85046 breaks

The flaw is a type confusion issue in V8, the JavaScript and WebAssembly engine inside Chrome and every Chromium browser, rated CVSS 8.8. Security researcher Salvatore Gulizia reported it on August 4, 2026. In his description, a V8 compiler bug lets an array holding PACKED_ELEMENTS receive the map for PACKED_SMI_ELEMENTS, and that mismatch becomes arbitrary read and write on the JavaScript heap. From there, a crafted web page can run code inside the browser's renderer sandbox.

Google shipped the fix in Chrome 152.0.7977.82 for Linux and 152.0.7977.82 or .83 for Windows and macOS on September 3, 2026. CISA added the flaw to its Known Exploited Vulnerabilities catalog the next day, setting a federal patch deadline of September 18. Any Chrome build before 152.0.7977.82 is exposed.

Is CVE-2026-85046 being exploited?

Yes. Google acknowledged that a working exploit for the flaw is already being used against Chrome users, and the KEV listing on September 4 is independent confirmation that active exploitation is happening now. Google withheld the attack details and the identity of who is using it, a standard move to give users a window to update before more attackers reverse the patch.

Why a browser flaw is an infrastructure problem

Your servers do not run Chrome. The laptops that SSH into them do. That workstation holds SSH private keys, live cloud console sessions, a password manager, and browser cookies for every admin panel you touch. A renderer-sandbox code-execution bug is one link in a drive-by chain, and attackers routinely pair it with a sandbox escape to reach the host. When that host is an operator's machine, the browser stops being an endpoint story and becomes an identity story. We made the same point when malware was shown hijacking Chrome passkey logins: the browser is where your credentials live, so it is where attackers go first.

This is also why "patched before the fix shipped" keeps happening. We saw it with two Microsoft zero-days exploited ahead of their patch. Widely deployed client software is a dependable initial-access surface, and browser engines sit at the very front of it.

"We updated Chrome" is not "we patched V8"

The same V8 engine ships inside Microsoft Edge, Brave, Opera, and Vivaldi, and each vendor releases its own fix on its own timeline, usually within a few days of Google. Electron desktop apps go further: they bundle their own Chromium build and update on the app maker's schedule, not Chrome's. So a fleet that force-updated Chrome this week can still be running the vulnerable engine inside Edge, a chat client, a note app, or an IDE. Inventory the whole Chromium footprint, not the flagship browser, or you close one door and leave four open. This is the gap the wire coverage skips, and it is where Chrome's faster patch cadence quietly raises the bar on everyone downstream who inherits the engine.

Detecting exploitation when there is no signature

Because Google withheld the technique, there are no published indicators for this CVE: no domains, no payload hashes, no exploitation infrastructure. That leaves patching as the fix and hunting as the only way to know whether you were hit in the window before you patched. Treat detection as a threat-hunting problem, not a signature you can drop into a rule. The observable that survives an unknown technique is process lineage: a browser spawning a child it has no reason to spawn, or a renderer that crashes and is immediately followed by a fresh process in the browser's tree.

version floor (chrome://version): 152.0.7977.82  [Linux, Windows, macOS]
ATT&CK:
  T1189  Drive-by Compromise
  T1203  Exploitation for Client Execution
hunt (no vendor signature exists; Google withheld the technique):
  browser process (chrome|msedge|brave|opera|vivaldi) spawns a child
    not in {crashpad_handler, chrome_crashpad, renderer, gpu-process, utility}
  renderer crash followed within seconds by a new process in the browser tree

In our own triage over the last 90 days, Chrome was the second most common product across the CVEs we tracked, appearing 132 times, behind only the Linux kernel. V8 type confusion is not a one-off; it is a recurring shape, and building the browser process tree into your hunting now pays off on the next one.

Push 152.0.7977.82 across the fleet, then hunt

Force the version floor of 152.0.7977.82 to every Chromium instance you manage, browsers and Electron apps alike, and verify the running build at chrome://version rather than trusting that auto-update already ran. A browser has to restart to apply the fix, so an operator who never closes their session stays vulnerable after the update lands. Then run the process-lineage hunt across the last few weeks to catch anything that slipped through, and fold Chromium version tracking into your vulnerability detection and SOC workflow so the next V8 zero-day is a patch job, not a fire drill. The federal deadline of September 18 is a floor, not a target.