Google says attackers are already exploiting CVE-2026-125350, a memory bug in Chrome's XML code. The public Chromium fix points to libxslt, the old C library behind XSLT. Google has called that code too risky to keep and plans to switch it off in Chrome 158 on November 17. Chrome users need to update and restart now. Microsoft Edge users are still waiting for a fix.
As of 12:05 a.m. New York time (EST), November 11, 2026.
On November 9, Google pushed Chrome 157.0.8103.50 for Linux and 157.0.8103.50/.51 for Windows and Mac. The update has nine security fixes. Google flagged one of them in its release notes: CVE-2026-125350, a high-severity "use after free in XML," reported anonymously on November 6. "Google is aware that an exploit for CVE-2026-125350 exists in the wild," the company wrote. SecurityWeek counts it as the eighth Chrome zero-day exploited this year.
Most coverage stops at "update now," and that is the right first step. But the bug's location is the bigger story. It appears to sit in the one part of Chrome's XML handling that Google never moved to memory-safe code. Google had already scheduled that code for shutdown before attackers found this hole.
What is confirmed, and what is not
Google has not said who is exploiting the flaw, who has been targeted or how the attack is delivered. It is holding back bug details until most users have updated. The US Cybersecurity and Infrastructure Security Agency added the flaw to its Known Exploited Vulnerabilities catalog on November 10 and gave federal agencies until November 24 to patch. CISA says the bug could let a remote attacker "execute arbitrary code inside the sandbox via a specially crafted webpage."
"Inside the sandbox" is an important limit. Chrome runs web pages in a restricted process, so code running there cannot take over the whole computer on its own. Attackers usually need a second bug to break out. Nobody has said publicly whether these attackers have one.
Google's notes do not name the library involved. The link to libxslt comes from Chromium's public source code. A patch titled "Fix use-after-free in direct pattern match cache" was added to Chromium's copy of libxslt. It is dated November 6, the same day the exploited bug was reported. CyberInsider reports that the patch is linked to the vulnerability's bug ID. We checked the public repository ourselves. The patch file is in the fixed builds, 157.0.8103.50 and Extended Stable 156.0.8078.96. It is not in the builds just before them, 157.0.8103.39 and 156.0.8078.93. The same release fixes a second XML use-after-free, CVE-2026-125346, reported in October. Until Google publishes the bug, the libxslt link is strong circumstantial evidence, not an official statement.
How the bug works
XSLT is a 1999-era language for turning XML data into something else, such as a styled web page. Browsers still support it through two routes: the XSLTProcessor JavaScript API, and a stylesheet instruction at the top of an XML file. Chrome hands that work to libxslt, a C library that runs on top of libxml2.
According to the patch's description, the bug sits in a cache libxslt uses to speed up pattern matching. A function reads a cached result, then runs an XPath query. That query can call back into the same function for the same cache slot. One example is a filter that refers to a global variable, whose value is computed only when first needed. The nested call frees the cached object and replaces it. When the outer call resumes, it frees its old, now stale pointer a second time. The fix is nine lines: read the cache again after the query returns.
Bugs like this are routine in C, which leaves memory management to the programmer. Memory-safe languages such as Rust rule them out by design.
The XML path Google never rewrote
Google saw this risk coming. In October 2025 it announced plans to remove XSLT. It argued that libxslt is one of several "complex, aging C/C++ codebases" and a "direct, potent attack surface" for little benefit. It said only about 0.02% of page loads use XSLT. Chrome's feature entry adds that libxslt "was unmaintained for ~6 months of 2025."
Google also began moving XML work away from C. In Chrome 153, it switched XML parsing to a Rust implementation for common cases that don't need XSLT: the DOMParser API, XMLHttpRequest's responseXML, and SVG images. XSLT stayed on the old C path while its removal went ahead.
That makes this flaw notable. XSLT was one of the XML paths left on C code, and that path is where the exploited bug appears to sit. Chromium carries the fix as its own local patch on top of libxslt 1.1.45, according to the library's Chromium README. Google's notes also warn that it keeps details restricted when a bug sits in a third-party library "that other projects similarly depend on, but haven't yet fixed." Other software that uses libxslt should watch for an upstream fix. WebKit, the engine behind Safari, also uses libxslt. Apple has not said whether Safari is affected by this specific bug.
Does Chrome 158 close the door?
Mostly, but not completely or right away. Chrome 158 is due on the Stable channel on November 17, per Google's release schedule. In that version XSLT stops working for ordinary users. Two exceptions run until Chrome 176 on August 17, 2027:
- an Origin Trial, which lets a registered site keep XSLT working on its own pages;
- an enterprise policy, which lets IT departments keep XSLT on for managed browsers.
libxslt is still in the Chromium source tagged for early Chrome 158 and 159 builds. So the code is not being deleted next week, only switched off by default. For most home users that should take this path off the table. Companies that use the policy to keep old XSLT-based internal tools running will keep the exposure for up to nine more months.
The timing is awkward. The fix ships just over a week before the code is turned off by default. Even so, patching cannot wait for Chrome 158. Updates roll out over "days/weeks," and the exploit is in use now.
Edge is the gap
Every Chromium-based browser shares the bug, and each vendor ships the fix on its own schedule:
- Chrome: fixed in 157.0.8103.50/.51 on desktop and 157.0.8103.50 on Android (rolling out through Google Play), and in Extended Stable 156.0.8078.96.
- Brave: version 1.99.56, published early on November 10 UTC, moves to Chromium 157.0.8103.50.
- Opera: Opera 140, released November 10, lists a fix for CVE-2026-125350. It is based on Chromium 157.0.8103.39, so the version number alone is not a reliable check.
- Vivaldi: its November 10 desktop update moves to Chromium 156.0.8078.99 and says it includes the fix.
- Microsoft Edge: not yet fixed. On November 9 Microsoft's Edge security notes said it is "aware of the recent exploits existing in the wild" and "actively working on releasing a security fix." The newest Edge Stable build listed, 157.0.4341.42, is dated November 5, before Google's fix.
Edge comes preinstalled on Windows, and many people browse with it without ever choosing it. So the people least likely to follow browser security news are also the ones waiting longest for this fix.
What to do now
- Chrome on a computer: open Menu → Help → About Google Chrome, let it download, then click Relaunch. A downloaded update does nothing until the browser restarts. Check that the version reads 157.0.8103.50 or later.
- Chrome on Android: update Chrome in Google Play. The rollout may take a few days to reach you.
- Brave, Opera, Vivaldi: install the November 10 updates and restart.
- Edge: check Settings → About Microsoft Edge each day and restart when an update appears. Until then, consider using a patched browser for unfamiliar sites.
- IT teams: force relaunches on managed fleets. Chrome's XSLTEnabled policy can turn XSLT off before Chrome 158 arrives. Test it first, because some older internal web apps depend on XSLT. Don't use the same policy to keep XSLT running after November 17 unless you have to.
The larger lesson
Big rewrites into memory-safe code take years. Attackers look for the parts that haven't been moved yet. Google's XSLT plan was sound: it measured usage, moved the common XML paths to Rust and set a removal date. This exploit landed in the gap between that decision and the shutdown date.
What to watch next: whether Google confirms the libxslt link when it opens the bug, when Microsoft ships the Edge fix, whether a sandbox escape turns up alongside this flaw, and whether Chrome 158 turns XSLT off on schedule next Tuesday.