Chrome CVE-2026-125350: 8th Exploited Zero-Day of 2026 Patched

Google shipped an emergency Chrome update on November 9 for nine security bugs, one of which attackers are already using. CVE-2026-125350 is a use-after-free in Chrome's XML component, and in Google's own words an exploit for it "exists in the wild." It is the eighth Chrome zero-day confirmed exploited this year — the browser on nearly every corporate desktop is, again, the thing being attacked.

Developing story — first published 11:12 CET (10:12 UTC), November 10, 2026. Updated as Google and other vendors publish more.

At a glance

CVE	CVE-2026-125350
Product / affected versions	Google Chrome (Desktop) before 157.0.8103.50 · Chromium-based browsers on the same engine
Fixed in	Chrome Stable 157.0.8103.50/.51 (Windows, Mac); 157.0.8103.50 (Linux) — released November 9, 2026
CVSS	Not yet scored by NVD; Google rates it High severity
Exploited in the wild	Yes — "Google is aware that an exploit for CVE-2026-125350 exists in the wild"
CISA KEV	Not listed (catalog version 2026.11.09)
Public PoC	None public; Google is restricting bug details until most users update
Official advisory	Chrome Releases — Stable Channel Update for Desktop

What CVE-2026-125350 is

A use-after-free is a memory-safety bug: code frees a block of memory and then keeps using the stale pointer. An attacker who can control what lands in that freed slot can steer execution — in a browser, that means a crafted web page turning a rendering bug into code running inside the sandbox. The rest of a real attack is a sandbox escape to reach the host, but the first click is just visiting a page.

The flaw sits in Chrome's XML component — the code that parses and transforms XML, which is reachable from ordinary web content. Per the Chrome Releases advisory, CVE-2026-125350 was reported anonymously on November 6, 2026, and Google acknowledged in-the-wild exploitation three days later. Google has not attributed the attacks or said whether they are targeted, and it is withholding technical details — standard practice until a majority of users have updated. The same release also fixed a second, separate use-after-free in the XML component (CVE-2026-125346, reported by a Neonix Security researcher) that is not known to be exploited.

"We're patched, our scanner shows Chrome 157." Shipping the binary is not the same as running it. Chrome stages an update in the background and only swaps it in on the next full relaunch — a laptop that has not been closed in two weeks is still on the vulnerable build no matter what the installer reports.

The eighth Chrome zero-day of 2026 — and a break in the pattern

This is the eighth Chrome zero-day Google has flagged as exploited in 2026, following a run that started in February with CVE-2026-2441, a use-after-free in CSS, and most recently CVE-2026-87491 in September, the seventh. Five of the seven before it lived in V8, Chrome's JavaScript engine. CVE-2026-125350 breaks that streak: it is the first exploited Chrome zero-day since February's CSS bug to land outside V8. Attackers who had been mining the JavaScript engine have moved to a quieter corner of the rendering stack — a reminder that "harden V8" is not a strategy, the whole content-parsing surface is in scope.

The cadence is the real story. A browser zero-day exploited before disclosure, patched with details withheld and no attribution, fits spyware vendors and state-aligned operators who burn client-side chains on specific targets. For everyone else the exposure window is not the day of the exploit — it is the days and weeks it takes a fleet to actually relaunch onto the fixed build, which Google itself says "will roll out over the coming days/weeks."

Remediation

1. Am I affected? Open chrome://version (or chrome://settings/help, which also triggers a check). Any Desktop build before 157.0.8103.50 is vulnerable. For a managed fleet, inventory the reported Chrome version per endpoint and — critically — whether the browser has been relaunched since the update downloaded.
2. Patch — exact fixed versions. Update to 157.0.8103.50/.51 (Windows, Mac) or 157.0.8103.50 (Linux). The update is already rolling out; do not wait for it to arrive on its own.
3. Force the relaunch. The fix applies only after every Chrome process exits and the browser restarts. Click Relaunch when the update banner offers it, or push a forced relaunch through policy (RelaunchNotification / RelaunchNotificationPeriod via Chrome Browser Cloud Management or your MDM). Don't forget the Extended Stable channel and every Chromium-based browser — Edge, Brave, Opera, Vivaldi — which inherit the same bug and ship the fix on their own schedule.
4. Can't patch instantly? Shrink the window. There is no clean configuration toggle that disables XML parsing without breaking the web, so the holding action is exposure reduction: make sure Site Isolation and Enhanced Safe Browsing are enforced by policy, and prioritize high-value users (admins, finance, executives) for the forced relaunch first.
5. Hunt for compromise. Google has published no indicators, so hunt behaviorally rather than by IOC. Look for anomalous child processes spawned by chrome.exe/renderer processes, new persistence (scheduled tasks, run keys, login items) appearing shortly after browsing, renderer crash dumps clustered on specific hosts, and outbound connections to never-seen destinations from an endpoint right after a browser session. Map it to MITRE ATT&CK T1189 (drive-by compromise), T1203 (exploitation for client execution), and T1071 (C2 over web protocols).
6. Eradicate and verify. On any host that trips those signals: isolate it, rotate the credentials and session cookies that lived in that browser profile (a renderer-level compromise can read them), and reimage if you confirm an implant. Confirm the endpoint is on 157.0.8103.50+ and has relaunched before you call it clean.

What is not known yet

• No CVSS from NVD. The record was not yet published at the time of writing; Google rates the bug High. The At a glance table will be updated when NVD scores it.
• No KEV listing. CVE-2026-125350 is not in the CISA KEV catalog (version 2026.11.09) as of publication; given confirmed exploitation, an addition would not be surprising.
• No attribution, no IOCs, no PoC. Google has not named the actor, the targeting, or the exploit chain, and no public proof-of-concept exists. Treat any "IOC list" circulating in the next 24 hours with suspicion.
• Exact trigger within the XML component is undisclosed until most users update.

Why the fix doesn't close the gap, and what does

The honest problem with every exploited browser zero-day is time. The patch existed on November 9; your fleet will be fully relaunched onto it sometime next week. During that window the exploit is live and a version scan tells you who is behind, not who has been hit. What catches a successful exploitation is not the endpoint — it is what the delivered payload does next on the network: the beacon to a command-and-control host, the quiet staging of data for exfiltration. Zero Hunt's AI Traffic Analysis runs a proprietary deep-learning model with four parallel inference heads — suspicious traffic, malware classification, attack-type identification, application fingerprinting — on the appliance GPU, trained on billions of PCAP sequences, flagging that C2 or exfil behavior while it is happening instead of in the next morning's SIEM digest, and regardless of which Chrome build the laptop is running.

The second question a browser RCE forces is blast radius: if one endpoint is popped, what can it reach? Zero Hunt's autonomous AI red team — ten coordinated agents running on-premise on the appliance's own private models, with a human in the loop for anything intrusive — validates that from the inside, testing whether a foothold on a user workstation can pivot to the internal apps and identity systems that matter, so a drive-by doesn't become domain compromise. Pairing continuous, automated validation with wire-speed detection covers the days a patch takes to land. See also our breakdown of an AI agent building a full Chrome exploit chain in six days and how an on-premise AI red team keeps that testing inside your walls. Talk to us.