Chrome fixed an exploited V8 flaw. Your forgotten browser runtimes still need attention

Google released a Chrome 152 security update on September 3 for Windows, macOS, and Linux. Among its 12 security fixes is CVE-2026-85046, a high-severity V8 type confusion flaw. Google says an exploit already exists in the wild.

The update moves Chrome to 152.0.7977.82 or .83 on Windows and macOS, and 152.0.7977.82 on Linux. Google describes the deployment as a rollout over the coming days or weeks, so relying on automatic updates does not establish that every installation has received the fix.

CISA added CVE-2026-85046 to its Known Exploited Vulnerabilities catalog on September 4. The entry assigns a September 18 due date under BOD 26-04. CISA-ADP enrichment displayed by NVD assigns a CVSS 3.1 score of 8.8; NVD has not supplied its own assessment. The vector's S:U value means the scored impact stays within the vulnerable component's security authority. Confirmed exploitation and the KEV entry are stronger reasons to prioritize the update than the score alone.

Chrome on employee laptops is only the visible part

An individual user can open chrome://settings/help to check the installed version. Engineering teams usually have a wider browser estate than the icons on employee desktops suggest.

Headless Chrome may be running inside end-to-end test jobs, screenshot services, PDF generators, crawlers, monitoring systems, or CI containers. Kiosk and embedded applications can carry their own browser runtime. Long-lived build images may also keep an older binary even after laptops update normally.

Those installations have their own update paths. A pinned container image or downloaded test binary stays pinned until the owning project changes it. Rebuilding an image without checking the resolved browser version can reproduce the same vulnerable runtime.

Check workstation deployments, then look through CI definitions, container bases, browser-test caches, kiosk images, and services that launch Chrome or Chromium without a visible window. The browser managers can expose downloads that are easy to miss:

npx playwright install --list
npx @puppeteer/browsers list --path ~/.cache/puppeteer

The first command lists browsers from all Playwright installations on the machine. The second inspects Puppeteer's usual Linux cache; use the cache path configured for the environment on macOS, Windows, or a custom setup. For a container, invoke its actual Chrome or Chromium executable with --version inside the built image instead of trusting the image tag or Dockerfile.

CISA says the vulnerability could affect Chromium-based browsers including Chrome, Edge, and Opera. Each needs a check against its own vendor release. Google's version numbers establish the fixed Chrome builds; they do not prove that another browser shipped the Chromium fix on the same date.

Active exploitation does not prove a full system takeover

The mechanism is public even though Google's Chromium tracker entry remains restricted. The NVD record says a remote attacker can execute arbitrary code inside the sandbox through a crafted HTML page. Salvatore Gulizia, the researcher credited by Google, published a technical writeup on August 28, six days before Google released the fixed Chrome builds.

Gulizia traced the flaw to an optimized Array.prototype.sort path. A comparator could change an array's internal representation during the sort and pass a guard that checked against previously seen representations rather than requiring the original one. His proof demonstrates an addrof primitive and uses unshift to skip a write barrier. He says arbitrary reads and writes on the V8 JavaScript heap should be trivial from there, referring to a technique in an earlier post. He found the bug in both Maglev and TurboFan.

That is only the first boundary. Gulizia says he combined the flaw with an n-day sandbox escape to complete a v8CTF challenge. Chrome renderer processes then sit inside Chromium's further process sandbox, which restricts access to files and other operating-system resources. A full machine compromise cannot be inferred from the disclosed V8 primitive alone.

That distinction got lost in circulation: the Hacker News submission ran under the title “Actively exploited sandbox RCE in all Chromium versions” and drew nearly 500 comments. Several commenters distinguished the V8 JavaScript-heap primitive from an escape of Chromium's renderer-process sandbox, while another posted Gulizia's writeup to argue the opposite, that the chaining is what makes it serious.

Google has not described the targets, campaign, indicators of compromise, or any additional stages used in the attacks it observed. Chrome versions older than the fixed builds still need updating, and the exploitation status makes delayed or overlooked installations more important than usual.

The immediate test for engineering teams is not whether Chrome says it updates automatically. It is whether every Chrome or Chromium runtime they operate can be located, assigned to an update mechanism, and verified on a build containing the fix.