Chrome's 6th Zero-Day of 2026 Is Live: One Type Confusion, Full Sandbox RCE

Chrome shipped its 6th zero-day patch of 2026. It had already been exploited for a month.

On September 3rd, Google pushed Chrome 152.0.7977.82. Buried in the release notes: CVE-2026-85046, CVSS 8.8, described as "type confusion in V8." That phrasing is doing a lot of work to sound boring. It isn't boring. It's a bug that turns a JavaScript array-shape mismatch into arbitrary read/write on the heap, and Google confirmed exploitation was already happening in the wild before the fix went out. CISA added it to the Known Exploited Vulnerabilities catalog the next day, with a September 18 remediation deadline for federal systems.

If you run Chrome, Edge, Brave, Opera, Vivaldi, or any Electron app that renders remote content, this is your problem right now, not next sprint.

What actually broke

V8 tags every array with a "map" describing its internal shape, because that's how the optimizing compiler picks fast machine code. A PACKED_SMI_ELEMENTS array (small integers, unboxed) compiles to different code than a PACKED_ELEMENTS array (arbitrary JS values, boxed pointers). TurboFan bakes assumptions about an array's map directly into the compiled code and only re-validates at specific guard points.

The researcher who reported it, Salvatore Gulizia, described the primitive in one sentence: get an array that TurboFan believes is PACKED_SMI_ELEMENTS to actually be carrying the PACKED_ELEMENTS map. Once compiled code treats a heap slot as a raw tagged integer when it's actually a boxed pointer — or the reverse — you have a type-confused read/write. Not a crash. A primitive. From JavaScript. No native code, no plugin, no download.

Google's own advisory line is almost comically terse for what it enables:

Type confusion in V8 in Google Chrome prior to 152.0.7977.82 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page.

"A crafted HTML page." That's the entire delivery mechanism. No click on a file, no macro, no plugin permission dialog. Visit a page, run untrusted JavaScript, corrupt memory, get code execution inside the renderer sandbox.

Why "inside the sandbox" still isn't good news

The sandbox is supposed to contain exactly this. A renderer process running attacker-controlled code is bad, but it's supposed to be boxed — no filesystem access, no arbitrary syscalls, nothing outside its jail. That's the whole design bet Chrome has made since 2008.

Gulizia's own write-up chains this V8 bug with a separate, previously known sandbox-escape flaw to demonstrate full exploitation. That's the pattern security researchers keep pointing at with this vulnerability class in 2026: a memory-corruption primitive in the JS engine, paired with a sandbox-escape bug, delivered as a two-stage exploit. It's the same architecture that's historically shown up in campaigns tied to commercial spyware vendors and state-aligned operators — because it's reliable, it's fast to weaponize, and V8 bugs get found constantly. This is the sixth actively-exploited Chrome zero-day patched in 2026 alone. Not the sixth reported. The sixth one that was already being used against real targets before the fix existed.

Patch status, by product

Product	Vulnerable	Fixed version
Chrome (Win/Mac)	< 152.0.7977.82/.83	152.0.7977.82/.83
Chrome (Linux)	< 152.0.7977.82	152.0.7977.82
Edge	Chromium < 152 merge	vendor rollout, check edge://settings/help
Brave / Opera / Vivaldi	Chromium < 152 merge	vendor-dependent, verify per browser
Electron apps (Slack, Discord desktop, VS Code webviews, your internal tools)	Whatever Chromium they bundle	Depends entirely on when the app was last rebuilt

That last row is the one teams forget. If you ship an Electron app, your users are running a frozen Chromium snapshot until you rebuild and release. "Chrome patched it" doesn't help someone using your app on an old Electron runtime. Go check your package.json.

Check your actual exposure, don't trust the auto-updater

Chrome's background updater downloads the fix but doesn't apply it until the browser restarts. A fleet that "auto-updates" can still be running the vulnerable binary for days if nobody's closing their tabs. Verify directly:

$FixedVersion = [version]"152.0.7977.82"
$chromePath = "${env:ProgramFiles}\Google\Chrome\Application\chrome.exe"
$installed = [version](Get-Item $chromePath).VersionInfo.ProductVersion
if ($installed -lt $FixedVersion) { Write-Output "[VULNERABLE] $installed" }

If you're on Microsoft Defender / Sentinel, query fleet-wide instead of endpoint-by-endpoint:

DeviceTvmSoftwareInventory
| where SoftwareName has "Google Chrome"
| extend Vulnerable = parse_version(SoftwareVersion) < parse_version("152.0.7977.82")
| where Vulnerable

Then force the restart. GPO's RelaunchNotification, Intune, Jamf, whatever you've got — auto-update alone is not remediation, restart is remediation.

If you think you were hit before the patch

There's no clean file-based IOC for the initial exploit — it runs in renderer memory and leaves little behind. The signal you're actually looking for is a Chromium-family process spawning something it has no business spawning:

let BrowserProcesses = dynamic(["chrome.exe", "msedge.exe", "brave.exe", "opera.exe"]);
let SuspiciousChildren = dynamic(["cmd.exe", "powershell.exe", "mshta.exe", "rundll32.exe"]);
DeviceProcessEvents
| where InitiatingProcessFileName in~ (BrowserProcesses) or InitiatingProcessParentFileName in~ (BrowserProcesses)
| where FileName in~ (SuspiciousChildren)

A successful chain to sandbox escape looks like a browser process spawning a shell, or writing an executable into a user-writable temp path. Hunt back at least 14 days — the exploit was live for roughly a month before disclosure, and "we patched it" doesn't retroactively check whether you were already popped.

The part worth sitting with

Gulizia got a $1,000 bounty for finding a bug that CISA is treating as an active federal incident risk with a hard deadline. Meanwhile the exploit chain built on top of it is worth real money on the grey market, and was apparently worth enough to someone that it was burned on live targets for weeks before Google even knew to look.

V8's optimizing compiler making unchecked assumptions about object shape isn't a new bug class — it's been the source of a meaningful fraction of Chrome's zero-days for years, because TurboFan's whole performance model depends on trusting map assumptions that JavaScript's dynamic typing makes fundamentally hard to guarantee. Six exploited-in-the-wild zero-days in nine months isn't an anomaly. It's the tax on running a JIT compiler in front of every hostile input on the internet.

Patch today. Check your Electron apps. Restart the fleet. And don't assume "auto-update" means "already fixed."