Chrome's array.sort() Hides a Zero-Day That's Already in the Wild: CVE-2026-85046 Lands on KEV

The short version//

On Sep 3, Google shipped a stable-channel update that fixed 12 vulnerabilities, one of which — CVE-2026-85046 — is being exploited in the wild. CISA listed it on the KEV catalog within 24 hours, with a federal remediation due date of Sep 18. It's a type-confusion bug (CWE-843, CVSS 8.8) in V8, the JavaScript engine under Chrome and every other Chromium browser: a crafted HTML page gets you arbitrary code execution inside the sandbox.

And it's the sixth actively-exploited Chrome zero-day of 2026. I checked against CISA's own catalog, not press coverage — all five prior ones are in there:

CVE	On KEV since	Component
CVE-2026-2441	Feb 17	Chromium
CVE-2026-3909	Mar 13	Skia
CVE-2026-3910	Mar 13	V8
CVE-2026-5281	Apr 1	Dawn
CVE-2026-11645	Jun 9	V8

That's roughly one exploited Chrome zero-day every six to seven weeks. The browser is the one "server" every homelab runs, so treat this as infrastructure news, not tab news.

What actually broke (the fun part)//

The reporter — Salvatore Gulizia (Serotav) — published a full root-cause write-up on Aug 28, before the stable fix even shipped, which is genuinely rare for an in-the-wild fix. Here's the shape of it:

V8 has a compiler tier called Maglev that sits between interpreted JS and TurboFan. As part of optimizing Array.prototype.sort, Maglev's TryReduceArrayPrototypeSort will inline a small insertion sort directly into your function when the array is 16 elements or fewer — skipping the overhead of the full builtin.

The inline path only supports two array "maps" (V8's internal bookkeeping for what an array holds): PACKED_SMI_ELEMENTS (small integers) and PACKED_ELEMENTS (generic objects). If your function gets trained on both kinds of arrays, Maglev accepts both maps as valid.

Here's the bug: after the sort runs on a temporary copy, V8 re-checks that the receiver array still has one of those maps — but it only checks membership in the set of previously-seen maps, not whether the map changed during the sort. And the comparator function you pass to sort() runs inside the sort. So:

1. Train a function with both integer arrays and object arrays.
2. Call confuse([{},{},{}]) — the array starts as PACKED_ELEMENTS.
3. Inside your (harmless-looking) comparator, call arr.fill(0). V8's fill, when replacing every element, is allowed to migrate the map backwards in place — now the same backing store is mapped as PACKED_SMI_ELEMENTS holding zeros.
4. The inlined sort copies its object pointers back into that array. The guard passes (the map is one of the two trained maps).

Result: an array whose map says "small integers" but whose slots hold object pointers. Anything V8 does based on the map treats those pointers as 64-bit numbers — and you have arbitrary read/write on the JS heap from a crafted HTML page. Gulizia's write-up walks through building addrof off this directly, and getting fakeobj by making V8 skip a write barrier with an unshift. The fix was simple in hindsight: don't inline sort when the function was trained on mixed element kinds.

What "in the wild" does and doesn't mean//

Google's blog states only that "an exploit for CVE-2026-85046 exists in the wild" — no details on who, what payload, or which pages were hit, the usual "get people to update first" silence. Two honest caveats:

• The reporter's public chain is a v8CTF exploit: his in-sandbox code-exec bug plus an n-day sandbox escape he flagged separately. That's not necessarily what's running in the wild — Google shipped no exploitation details, so don't overclaim.
• KEV's short description notes the flaw "could affect multiple web browsers that utilize Chromium, including, but not limited to, Google Chrome, Microsoft Edge, and Opera." That's CISA quoting the vulnerability record, and it's the line that matters if you run anything Chromium-derived: Edge, Brave, Opera, Vivaldi, headless scrapers, Electron apps.

The Hacker News reports a $1,000 bounty for the disclosure; Google's own release post prints it next to the CVE entry, so it's primary-sourced after all.

What you should do tonight//

1. Update Chrome to 152.0.7977.82 or later (.83 on Windows/macOS, .82 on Linux). More > Help > About Google Chrome, then relaunch. Confirm the version string — "updated" is a claim, not a fact, until you read it back.
2. Audit your Chromium derivatives. Headless Chromium in Docker images (puppeteer, playwright), CI containers, and Electron apps (VS Code et al.) each pin their own V8. If an image or app hasn't been rebuilt since Sep 4, it's still vulnerable. This is the part of the patch window that actually touches a homelab.
3. If you run Edge (or Opera, Brave, whatever): watch for the vendor's Chromium-based update and apply it. CISA named them explicitly in the KEV entry — they're not "probably fine."
4. Use Sep 18 as your deadline. That's the federal due date; for a personal lab it's just a number with good properties, but it works as one.
5. If you want the full root-cause walkthrough, read Gulizia's write-up — it's exactly the kind of "why does this patch matter" detail that makes V8 bugs worth reading instead of skimming. If you're keeping score on what KEV membership means for patch priority, our SonicWall SMA1000 post covers the "KEV = patch now" framing.