On September 3, Google released an out-of-cycle stable-channel update for Chrome — 152.0.7977.82/.83 for Windows and macOS and 152.0.7977.82 for Linux. In the bulletin, one line stands out above all others: “High CVE-2026-85046: Type confusion in V8,” found by Salvatore Guglisi (nickname Serotav) on August 4, reward — one thousand dollars. And a note, which is why the update was released as a separate release: “Google is aware that an exploit for CVE-2026-85046 exists in the wild.”
Type confusion in V8 is when the engine accesses an object in memory as if it were another type. A classic for JIT compilers and one of the most convenient classes of errors for an attacker: from it, reading and writing to another’s memory on a page from JavaScript on the page can usually be exploited.
On Hacker News the topic spread with the headline “Actively exploited sandbox RCE in all Chromium versions.” The Google bulletin mentions no sandbox escape or RCE — there is only a High-rated type confusion. Exploitation is confirmed; Google doesn’t disclose details; CVSS 8.8 is listed in third-party databases, not in the bulletin itself. The distinction between “exploitable” and “breaking the sandbox in all builds” is fundamental here.
Why “I updated Chrome” doesn’t cover everything
Chrome updates itself and fixes first. The problem is that the same V8 is pulled into several other places, and none of them know about the September release.
The most troublesome case for this audience is a headless browser in a Docker stack. A scraper, a parser of results, an OSINT conveyor, or a screenshot renderer traverses untrusted pages and executes other people’s JavaScript in batches — i.e., it does exactly what the exploit is designed to do. The image is tagged and will be updated only when you rebuild it.
Electron apps are less risky: they render their interface from local files. But as soon as external content appears in the window — built-in link viewer, widget, login page through a third-party service — again untrusted JavaScript runs in an old engine. A separate story are anti-detection browsers: these are Chromium forks, and you have no control over how quickly the vendor pulls upsteam patches.
What to check manually
# ordinary browser
google-chrome --version
chromium --version
# in the scraper container
docker exec <container> sh -c 'chromium --version || google-chrome --version'
# Electron: DevTools in the app window
navigator.userAgent // look for the substring Chrome/152.0.7977.xx
You should compare the major version and the last group of digits: anything below 152.0.7977.82 does not contain fixes. For Electron a version-to-Chromium mapping table in the project’s official documentation is useful — it shows which application release you need.
Minimal set of actions for today: update browsers on workstations → go through docker-compose and find images with Chromium, Playwright, Puppeteer, or Selenium → rebuild them with the latest base layer → check the version inside the container, not in the Dockerfile → ensure anti-detection profiles are updated by the vendor, and if not, do not open unfamiliar domains in them until updated.
Clearly: this is not a worm or a hole that lets someone break into a server from the outside. For the exploit to work, the engine must execute prepared JavaScript — someone has to open a page. For a person at the browser, it means “update and don’t panic,” for automation that goes to thousands of pages a day, it means “rebuild the images today.”
And for context: according to The Hacker News, this is the sixth actively exploited zero-day in Chrome this year, and CISA has added the vulnerability to the KEV catalog with a deadline for federal agencies of September 18. Regardless of this rating, the class of vulnerability is the same as discussed in the analysis of the memory layout hardware: memory corruption in native code is still a vulnerability, and it is still caught post facto.
Sources
- Chrome Releases: Stable Channel Update for Desktop, September 3, 2026
- The Hacker News: Google Releases Chrome Update to Patch Actively Exploited V8 Zero-Day
- Help Net Security: Google patches actively exploited Chrome zero-day
How is Chromium updated in your containers — is the image rebuilt on a schedule, or does it live with what it had at build time until another news like this? And does anyone treat the headless browser in the stack as a separate inventory item that needs patching, rather than just a dependency?