CVE-2026-85046: Chrome's Actively Exploited Zero-Day

CVE-2026-85046 is a type confusion bug in V8, the engine that runs JavaScript and WebAssembly inside Chrome. It’s fixed in Chrome 152.0.7977.82, and it’s not theoretical: Google confirmed an exploit for it already exists in the wild. If your Chrome fleet hasn’t restarted since the patch shipped, some of it is still vulnerable right now.

What CVE-2026-85046 actually is

Type confusion happens when code treats a piece of memory as one data type when it actually holds another. Here, the researcher who reported it, Salvatore Gulizia (Serotav), described the root cause plainly: a V8 compiler bug lets an array holding PACKED_ELEMENTS end up tagged with the map for PACKED_SMI_ELEMENTS instead. Once the engine believes an array is one shape when it’s really another, that mismatch becomes arbitrary read and write access on the JavaScript heap.

Arbitrary heap read/write is not the end of an exploit chain, it’s the foundation of one. From there, an attacker who controls what gets written and where can start building toward full code execution inside the renderer sandbox. The trigger is a page. No download, no extension install, no “are you sure” dialog. A tab loading a malicious or compromised site is enough exposure.

Google rated it CVSS 8.8 and, per its usual practice for actively-exploited bugs, held back the deeper technical writeup. That’s not obfuscation, it’s the same reasoning Redis and Apache and every other maintainer uses when a fix ships before every user has installed it: publishing a working proof-of-concept while millions of installs are still vulnerable hands attackers a head start they don’t currently have.

Two Chrome 152 security events, not one

We covered Chrome 152’s base security release when it shipped 327 fixes, including a $25,000-bounty use-after-free in ANGLE. That was a scheduled release. CVE-2026-85046 is a different animal: a point release, 152.0.7977.82, that exists because this specific bug was already live in attacks. Same major version number, two unrelated security stories. If you patched for the 327-fix release and haven’t checked your version since, you’re not covered for this one.

Google’s tally for the year now stands at six actively-exploited Chrome zero-days patched, this one included. That pace isn’t unusual for a browser with Chrome’s install base and attack surface, but it’s a useful number to have on hand the next time someone on your team asks whether “just use Chrome” is a complete security posture on its own. It’s necessary. It’s not sufficient without a patching cadence behind it.

Checking whether you’re exposed

Confirm your version directly rather than assuming auto-update already handled it:

# Chrome, Edge, Brave, or any Chromium browser
chrome://settings/help

# From the command line (macOS)
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --version

# From the command line (Linux)
google-chrome --version

Below 152.0.7977.82 (or .83 on Windows and macOS), you’re running the vulnerable code path. Chrome downloads updates in the background automatically for most users, but the fix isn’t live until the browser restarts. That’s the gap that matters operationally: a workstation that’s been asleep, a kiosk browser that never gets closed, a CI runner that spins up a headless Chrome image built weeks ago, all of these can carry the vulnerable version well past the day the patch shipped.

Enterprise Chrome policy has also been in flux this year for unrelated reasons, Manifest V2’s removal from the Chrome Web Store broke a chunk of managed extension deployments back in the spring, so if your Chrome management console already has open tickets from that, this is one more reason to look at it this week instead of letting the backlog grow. For a managed fleet, don’t take restart compliance on faith:

1. Push the update through your MDM or Chrome Browser Cloud Management rather than relying on background auto-update alone.
2. Query chrome://policy or your endpoint management console for the minimum enforced version across managed devices.
3. Flag any machine that’s been running the same Chrome process for more than a few days. Long uptime is exactly the profile that misses a restart-gated patch.
4. If you build Chromium into a product (Electron, CEF, an embedded browser control), check the Chromium version your build bundles separately. It does not inherit fixes from the system browser on the same machine.

Why the reporter-to-KEV timeline matters

Gulizia reported this on August 4. Google fixed it and CISA didn’t add it to the Known Exploited Vulnerabilities catalog until September 4, a full month later, once active exploitation was confirmed independently of the original report. That gap is the useful part: it means the window between “a researcher found this” and “this is now definitely being used against real targets” was about four weeks, which lines up with how quickly working exploits for browser memory-safety bugs tend to get weaponized once the underlying bug class is understood. Waiting for a KEV listing before patching a browser is waiting for confirmation of a fact that was already true.

CISA’s Binding Operational Directive 26-04 requires federal agencies to prioritize KEV-listed bugs for rapid remediation. It doesn’t bind private companies, but the reasoning behind it applies just as well outside government: a bug this class of severe, already confirmed exploited, sitting in software installed on nearly every employee’s machine, isn’t one to schedule into next month’s patch cycle.

The short version

Get every managed Chrome, Edge, Brave, and Chromium-embed instance to 152.0.7977.82 or later, and make sure “downloaded the update” actually turns into “restarted the browser.” Neither step is exotic. Confirming both actually happened, across every machine your organization is responsible for, is where this kind of bug usually slips through.