Google has patched CVE-2026-125350, a high-severity use-after-free in Chrome’s XML handling that attackers are already exploiting. The fix landed in the Stable channel on November 9, 2026, three days after an anonymous researcher reported the bug.
Google says it is aware that an exploit for CVE-2026-125350 exists in the wild. It is the eighth exploited Chrome zero-day of 2026, and CISA added it to its Known Exploited Vulnerabilities catalog on November 10.
What Is CVE-2026-125350?
Google’s advisory describes CVE-2026-125350 (CVSS 8.8) only as a “use after free in XML” and has not published a technical write-up. A use-after-free happens when code keeps using a memory location after it has been released, which lets an attacker who controls what fills that memory corrupt the browser’s state.
The public Chromium fix traces the bug to Chrome’s bundled copy of libxslt, the library that applies XSLT stylesheets to XML documents. It points to a cache used during pattern matching: a nested evaluation could free and replace a cached object while an earlier operation still held its old address. Google has not confirmed this reading.

Google has also not explained how the exploit is delivered. Crafted web content is the most likely route for a browser rendering bug, but that remains an inference. Renderer memory corruption typically gives code execution inside Chrome’s sandbox, and full device compromise usually needs a second bug to escape it. Google has not said whether the observed attacks used such a chain.
Is the Bug Limited to Chrome?
Google keeps bug details restricted until most users have updated, and its policy extends that restriction when a flaw sits in a third-party library that has not been fixed upstream. No upstream libxslt fix has been released as of November 11, 2026.
Whether other software that embeds libxslt carries the same flaw has not been confirmed. Linux distributions have begun tracking the CVE, so administrators should watch their distribution’s advisories for libxslt packages as well as browser updates.
Which Chrome Builds Contain the Fix?
| Channel | Platform | Fixed Version |
|---|---|---|
| Stable | Windows, macOS | 157.0.8103.50/.51 |
| Stable | Linux | 157.0.8103.50 |
| Stable | Android | 157.0.8103.50 |
| Extended Stable | Windows, macOS | 156.0.8078.96 |
Chrome 157 reached the Stable channel on November 3 as 157.0.8103.38/.39, with 213 security fixes, seven of them Critical. Browsers still on those builds are vulnerable to CVE-2026-125350. Chrome downloads updates in the background, but the fix only takes effect after a relaunch.
What Else Did the November 9 Update Fix?
The update carries nine security fixes, seven rated High and two Medium. One of them, CVE-2026-125346, is a second use-after-free in XML, reported on October 12 by Arni Hardarson of Neonix Security. Google has not flagged it as exploited.
| CVE | Severity | Component | Bug Type |
|---|---|---|---|
| CVE-2026-125350 | High | XML | Use after free (exploited) |
| CVE-2026-125346 | High | XML | Use after free |
| CVE-2026-125344 | High | V8 | Type confusion |
| CVE-2026-125348 | High | GPU | Out-of-bounds write |
| CVE-2026-125343 | High | Compositing | Buffer overflow |
| CVE-2026-125347 | High | FileSystem | Incorrect authorization |
| CVE-2026-125345 | High | WebGL | Uninitialized resource |
| CVE-2026-125349 | Medium | GPU | Uninitialized resource |
| CVE-2026-125342 | Medium | GPU | Uninitialized resource |
How Does This Compare With Chrome’s Earlier 2026 Zero-Days?
Google has now patched eight Chrome flaws exploited in the wild this year. The seven before it are as follows: CVE-2026-2441, CVE-2026-3909, CVE-2026-3910, CVE-2026-5281, CVE-2026-11645, CVE-2026-85046 and CVE-2026-87491.
As with most Chrome zero-days, Google has not named the attackers, their targets or the scale of the campaign. Chrome zero-days have often surfaced in targeted operations, but nothing published so far ties CVE-2026-125350 to a specific actor.
Are Edge, Brave, Opera and Vivaldi Exposed?
Every browser built on Chromium inherits the vulnerable code until its vendor ships a build with the fix. Vivaldi shipped desktop and Android updates dated November 10. At the time of writing, Microsoft, Brave and Opera had not publicly tied a release to CVE-2026-125350, so organizations should check each vendor’s release notes rather than assume a recent build includes the fix.
CISA has set November 24, 2026, as the remediation deadline for covered U.S. federal civilian agencies. For other organizations, the KEV entry is a clear signal that this update should not wait for the next maintenance window.
Following a Browser Zero-Day From Patch to Weaponization
Google rarely publishes details for a browser zero-day, so the first useful signals tend to appear outside the vendor advisory: a working exploit claim, a KEV change or a related campaign report. SOCRadar’s Cyber Threat Intelligence module tracks CVE-2026-125350 and its follow-on activity in one place, including KEV status and new exploitation reports. Dark Web Monitoring adds visibility into underground forums where browser exploits and exploit kits are offered for sale. Confirming whether any of your own endpoints were targeted still depends on browser version inventory and endpoint telemetry.

Steps for Teams Managing Browser Fleets
- Force the relaunch: Use the RelaunchNotification and RelaunchNotificationPeriod policies so users cannot postpone the restart that activates the fix
- Verify versions: Flag any Chrome install below 157.0.8103.50, or below 156.0.8078.96 on Extended Stable, through your MDM or EDR inventory
- Cover every Chromium browser: Track Edge, Brave, Opera and Vivaldi separately and confirm each vendor’s fixed build before closing the ticket
- Reduce exposure where patching lags: Some analysts suggest disabling XSLT processing through Chrome’s XSLTEnabled enterprise policy until updates land; this is not Google’s guidance, so test it against internal applications first
- Hunt for follow-on activity: Google has published no indicators, so look for repeated renderer crashes, unexpected child processes spawned by the browser and new persistence created shortly after web browsing; a clean result does not prove the absence of compromise

Source: SOCRadar · 2026-11-11