Chrome’s Eighth Zero-Day Is Being Exploited. CISA Has Not Given Anyone a Deadline.

Read the advisory and the story narrows fast. Google says it is aware an exploit exists in the wild. Everything past that sentence is inference or silence.

Two use-after-frees in one parser is a signal

A use-after-free frees an object while a reference to it survives. Whoever controls the freed memory plants something else there, and the stale pointer hands it back to code that still trusts it. In a renderer, a crafted page gets a foothold inside the sandbox.

Chrome shipped two of them, both in XML. CVE-2026-125350 was reported anonymously on November 6 and patched three days later. CVE-2026-125346 was reported on October 12 by Arni Hardarson of Neonix Security. Same defect class, same component, three weeks apart. Someone is pushing hard on that parser.

Google does not say which path reaches the bug. The XML stack handles XML documents and XSLT transforms inside the renderer, so the reachable surface looks like ordinary page content. Treat that as inference, not a published detail.

Confirmed is thin. The CVE exists, the component is XML, the severity is High, and Google states the exploit is real. Unknown is everything a responder wants. No actor, no targeting, no indicators, no CVSS score. Any claim about who is using this belongs to whoever makes it, not to us.

The version in the advisory is a target, not a state

Google’s wording is that the update rolls out over the coming days and weeks. Help, About Google Chrome can report you current while you sit below 157.0.8103.50.

Downstream is the bigger gap. Edge, Brave, Opera and Vivaldi each ship their own Chromium build on their own schedule, so a Google fix is a starting gun for them. Headless Chromium pinned in a build image, a CI runner or a screenshot service never meets the desktop updater. Electron bundles its own copy. Virtual desktop goldens reset to a frozen base.

The inventory that says Chrome is covered counts browser installs. Your exposure is counted in Chromium builds, and nobody on most estates holds that list. The Chromium security process assumes a vendor in the middle. You are the vendor in the middle.

You cannot triage a bug the vendor will not describe

Google’s own threat intelligence group made this argument six weeks ago. Its September 30 study measured zero-day exploitation rising from 8 a month in 2025 to 11 a month across January to August 2026, with 22 in August alone, and 141 exploited vulnerabilities in eight months against 127 for all of 2025. Its recommendation was to move off unprioritized mass-patching toward triage driven by threat intelligence.

That recommendation needs inputs. Here there are none. So the only defensible instruction this week is to patch every Chromium build you can find, which is the behavior the same company just told you to stop.

Plan around the Known Exploited Vulnerabilities catalog. Seven Chrome zero-days this year, seven entries, six on a 14-day clock. The eighth is a question of when. Write the change ticket before the catalog flips.

For a platform team the risk is not the renderer. It is what the browser holds. The dashboard tab with a cluster admin token, the Argo CD login, the Grafana panel, the cloud console. An exploit there lands beside live production credentials.

Running the patch is the easy half. Finding every Chromium in the estate decides whether it means anything.

Three questions to answer before CISA acts. Do you know how many Chromium builds run inside your images and CI runners? Does a named team own their update path? And when this CVE joins the catalog, whose queue does the ticket land in?

Related reading. We covered how a web page dropped a file in Downloads and an agent ran it nine times out of ten, why record patch volumes keep breaking the thing beside them, and how container images keep trusting what the host already stopped trusting.