Chrome CVE-2026-125350 Zero-Day: Patching and Hunting

Google fixed CVE-2026-125350, a use-after-free in Chrome’s XML component, on November 9, 2026, and says “an exploit for CVE-2026-125350 exists in the wild”. A crafted web page can use it to run code inside Chrome’s renderer sandbox. Chromium rates it High, and the CVSS 3.1 score in the NVD record is 8.8 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H). CISA added it to its Known Exploited Vulnerabilities catalog on November 10, with a federal deadline of November 24.

An anonymous researcher reported the flaw on November 6. Google has not said who is exploiting it, who was targeted, or whether attackers paired it with a second bug to escape the sandbox.

Affected and fixed versions

Two details are easy to miss:

• Early Stable Chrome 158. On November 4 Google pushed 158.0.8127.18/.19 to a small share of Windows users. Its version number is higher than 157.0.8103.50, but it was built before the fix. In the Chromium source, the first 158 build that carries the fix is 158.0.8127.30. A scanner that only checks “below 157.0.8103.50” will mark those PCs safe.
• Chrome for iOS uses Apple’s WebKit engine, not Chrome’s own, and Google lists no iOS fix.

How the attack works

Google’s release note says only “Use after free in XML”. The fix in the Chromium source shows where the bug is:

• The bug is in libxslt, the XSLT library Chrome bundles to transform XML documents with stylesheets. The function xsltTestCompMatchDirect in pattern.c cached a node-set, called the XPath evaluator, then freed the cached pointer. The evaluation can re-enter the same function for the same cache slot, for example through a global variable whose value runs xsl:number. The nested call frees and replaces the cached object, and the outer call then frees it again.
• The vulnerable code runs only when a page uses XSLT. A page reaches it through an <?xml-stylesheet?> processing instruction in an XML document, or through the XSLTProcessor JavaScript API.
• The same fix also closes CVE-2026-125346, another XML use-after-free in this release, reported by Arni Hardarson (Neonix Security) on October 12.
• Delivery is a web page. The victim only has to load a malicious or compromised page, or a page that loads attacker content in a frame or advert. No download or click on a file is needed.

Code that runs through this bug runs inside the renderer sandbox. To install malware or reach the rest of the PC, an attacker needs a second bug that escapes the sandbox. Exploits used in the wild against Chrome usually come as such chains, so treat an exploited renderer as a possible full compromise until you have checked.

Chromium’s public fix includes a test case that crashes an unpatched browser. No working exploit has been published.

Is libxslt outside Chrome affected?

Chromium fixed this with a patch to its own copy of libxslt. The upstream GNOME libxslt project has the same code in xsltTestCompMatchDirect, and as of November 11 it has no matching fix or release. Its last release is 1.1.45, from November 2025. Software that applies attacker-supplied XSLT stylesheets with the system libxslt, such as PHP’s XSL extension, Python’s lxml and xsltproc, may share the bug. Google, the GNOME project and the Linux distributions have not said so. Few applications accept stylesheets from untrusted users, so check whether yours do before treating this as urgent.

Who is exposed, in priority order

1. PCs where Chrome downloaded the update but was never relaunched. Chrome stages the new version and only switches to it when the browser restarts. Users who keep Chrome open for weeks stay on the old build.
2. PCs in Google’s Early Stable group on 158.0.8127.18/.19, which version checks may report as fixed.
3. Microsoft Edge and other Chromium browsers such as Opera, Brave and Vivaldi, until each vendor confirms a release with the fix. CISA names Edge and Opera in its KEV entry.
4. Servers that run headless Chrome on untrusted content, such as HTML-to-PDF converters, link preview services, web scrapers and automated test farms. Puppeteer and Playwright pin their own Chromium builds, and these hosts are rarely in the browser patching process.
5. Chromebooks, until a ChromeOS release with the fix ships.
6. Electron desktop apps, which embed Chromium and only get the fix when their maker ships a new build. Most load only their own content, so they come last.

How to check your devices

• In the browser, open chrome://version (or edge://version) and read the version, then open chrome://policy to confirm any XSLT policy you set.
• On Windows, run this in PowerShell. It reads the version of both machine-wide and per-user installs:

Get-ChildItem "C:\Program Files\Google\Chrome\Application\chrome.exe", "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe", "C:\Users\*\AppData\Local\Google\Chrome\Application\chrome.exe" -ErrorAction SilentlyContinue |
    Select-Object FullName, @{n='Version';e={$_.VersionInfo.ProductVersion}}

• On macOS, run defaults read "/Applications/Google Chrome.app/Contents/Info" CFBundleShortVersionString.
• On Linux, run google-chrome --version.
• Across the fleet, use Defender Vulnerability Management, Intune or your inventory tool, filter by CVE-2026-125350, and check the 158 Early Stable builds separately. Hunts 1 and 2 below do this in Defender.

The version on disk is not the version running. Hunt 2 shows PCs where an old Chrome is still running after the update was installed.

Mitigation and remediation

1. Update Chrome to 157.0.8103.50 or later (156.0.8078.96 on Extended Stable, 158.0.8127.30 or later on Early Stable). On a single PC, open Settings, then About Chrome, and select Relaunch.
2. Force the relaunch. Set the Chrome policy RelaunchNotification to 2 (required) and RelaunchNotificationPeriod to a short window, such as 4 hours (14400000 milliseconds). Edge has the same policies.
3. Disable XSLT where you cannot update straight away. Chrome 146 and later and Edge 147 and later support the XSLTEnabled policy. Set to false, it turns off the XSLTProcessor API and XSL processing instructions, which is the only way into the vulnerable code. This is our recommendation, not a Google workaround. The commands are below.
4. Update Edge to 157.0.4341.46 or later and keep XSLT disabled there until Microsoft confirms which build fixes CVE-2026-125350. On November 9 Microsoft said it was aware of the exploits and working on a fix.
5. Update other Chromium browsers and headless Chromium as vendors ship fixes. For Puppeteer and Playwright, upgrade the package so it downloads a fixed browser build, then rebuild the container images.

Disable XSLT by policy

XSLTEnabled is a per-profile policy that takes effect without a browser restart.

# Windows, Chrome and Edge: disable XSLT by policy (machine-wide)
New-Item -Path "HKLM:\SOFTWARE\Policies\Google\Chrome" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Google\Chrome" -Name XSLTEnabled -Type DWord -Value 0
New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Edge" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Edge" -Name XSLTEnabled -Type DWord -Value 0

# Linux, Chrome: managed policy file
sudo mkdir -p /etc/opt/chrome/policies/managed
echo '{ "XSLTEnabled": false }' | sudo tee /etc/opt/chrome/policies/managed/xslt.json

On macOS, deliver XSLTEnabled set to false in a configuration profile for com.google.Chrome and com.microsoft.Edge. On Chromebooks, set it in the Google Admin console. The cost is small: XSL-styled RSS feeds and XML sitemaps show as plain XML, and a few older business applications that render reports with XSLT may stop working. Test those first.

Threat hunting

Google has published no indicators, so these hunts look for vulnerable browsers and for what an exploited browser does: crash, load XSLT from the internet, start programs and write files.

Example KQL for Microsoft Sentinel and Defender

The KQL below is example code for Microsoft Sentinel and Microsoft Defender for Endpoint. Adapt table and field names to your environment and test each query before relying on it.

Hunt 1: Chrome and Edge below the fixed builds

// Example: Defender XDR, Chrome installs that are not fixed for CVE-2026-125350
DeviceTvmSoftwareInventory
| where SoftwareVendor =~ "google" and SoftwareName has "chrome"
| extend V = parse_version(SoftwareVersion), Major = toint(split(SoftwareVersion, ".")[0])
| extend Fixed = case(
    Major >= 159, true,
    Major == 158, V >= parse_version("158.0.8127.30"),
    Major == 157, V >= parse_version("157.0.8103.50"),
    Major == 156, V >= parse_version("156.0.8078.96"),
    false)
| where not(Fixed)
| summarize Devices = dcount(DeviceId), Sample = make_set(DeviceName, 20) by SoftwareName, SoftwareVersion, OSPlatform
| order by Devices desc

Defender also maps the CVE directly once its data catches up:

// Example: Defender XDR, devices Defender flags for CVE-2026-125350
DeviceTvmSoftwareVulnerabilities
| where CveId == "CVE-2026-125350"
| summarize Devices = dcount(DeviceId), Sample = make_set(DeviceName, 20) by SoftwareVendor, SoftwareName, SoftwareVersion

Hunt 2: old Chrome still running after the update

This finds PCs where the browser process running in the last day is older than the fix, whatever is on disk.

// Example: Defender XDR, the Chrome and Edge versions actually running
DeviceProcessEvents
| where Timestamp > ago(1d)
| where FileName in~ ("chrome.exe", "msedge.exe") and isnotempty(ProcessVersionInfoProductVersion)
| summarize LastSeen = max(Timestamp) by DeviceName, FileName, Version = ProcessVersionInfoProductVersion
| extend V = parse_version(Version), Major = toint(split(Version, ".")[0])
| where (FileName =~ "chrome.exe" and not(
        Major >= 159
        or (Major == 158 and V >= parse_version("158.0.8127.30"))
        or (Major == 157 and V >= parse_version("157.0.8103.50"))
        or (Major == 156 and V >= parse_version("156.0.8078.96"))))
     or (FileName =~ "msedge.exe" and V < parse_version("157.0.4341.46"))
| order by FileName asc, Version asc

Hunt 3: browser renderer crashes

Failed exploit attempts against a use-after-free usually crash the renderer, and Chrome writes a crash report each time. A burst of reports on one PC, or a report right after the user visited an unfamiliar site, is a lead.

// Example: Defender XDR, Chrome and Edge crash dumps written by Crashpad
DeviceFileEvents
| where Timestamp > ago(30d)
| where FolderPath has @"\User Data\Crashpad\reports\" and FileName endswith ".dmp"
| extend Browser = iff(FolderPath has @"\Microsoft\Edge\", "Edge", iff(FolderPath has @"\Google\Chrome\", "Chrome", "Other"))
| summarize Crashes = count(), FirstSeen = min(Timestamp), LastSeen = max(Timestamp) by DeviceName, Browser
| order by Crashes desc

Hunt 4: XSLT stylesheets loaded from the internet

XSLT is rare on today’s web, so browsers fetching stylesheets from unfamiliar sites are worth a look. Expect noise from styled RSS feeds and XML sitemaps (sitemap.xsl, main-sitemap.xsl). This needs web proxy or secure web gateway logs with full URLs.

// Example: Sentinel, XSL stylesheets fetched through a web proxy (CEF)
CommonSecurityLog
| where TimeGenerated > ago(14d)
| where RequestURL matches regex @"(?i)\.(xsl|xslt)(\?|$)"
| where RequestURL !has "sitemap"
| extend Host = tostring(parse_url(RequestURL).Host)
| summarize Requests = count(), Clients = make_set(SourceIP, 20), Urls = make_set(RequestURL, 10),
            FirstSeen = min(TimeGenerated) by Host
| order by FirstSeen desc

If you use the ASIM web session parser, the same filter works on _Im_WebSession with the Url field.

Hunt 5: browsers starting shells and script hosts

A sandbox escape usually ends with the browser starting a shell, a script host or a download tool. Chrome and Edge normally start only their own processes.

// Example: Defender XDR, unusual child processes of Chrome and Edge
DeviceProcessEvents
| where Timestamp > ago(30d)
| where InitiatingProcessFileName in~ ("chrome.exe", "msedge.exe")
| where FileName in~ ("cmd.exe", "powershell.exe", "pwsh.exe", "rundll32.exe", "regsvr32.exe", "mshta.exe",
    "wscript.exe", "cscript.exe", "curl.exe", "bitsadmin.exe", "certutil.exe", "schtasks.exe", "msiexec.exe")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessCommandLine
| order by Timestamp desc

Some enterprise tools and protocol handlers start cmd.exe from the browser for legitimate reasons. Baseline those, then treat anything new as urgent, especially if it follows a crash from Hunt 3.

Hunt 6: browsers writing programs or persistence outside Downloads

Browsers save files to Downloads. Executables, scripts or autorun keys written anywhere else by the browser process are a strong signal.

// Example: Defender XDR, executables and Run keys written by Chrome or Edge outside Downloads
let BrowserFiles = DeviceFileEvents
    | where Timestamp > ago(30d)
    | where InitiatingProcessFileName in~ ("chrome.exe", "msedge.exe")
    | where FileName matches regex @"(?i)\.(exe|dll|scr|ps1|bat|cmd|vbs|js|hta|lnk)$"
    | where FolderPath !has @"\Downloads\" and FolderPath !has @"\Google\Chrome\Application\"
        and FolderPath !has @"\Microsoft\Edge\Application\" and FolderPath !has @"\User Data\"
    | project Timestamp, DeviceName, Activity = "file", Detail = strcat(FolderPath, " ", SHA256);
let BrowserRegistry = DeviceRegistryEvents
    | where Timestamp > ago(30d)
    | where InitiatingProcessFileName in~ ("chrome.exe", "msedge.exe")
    | where RegistryKey has_any (@"\CurrentVersion\Run", @"\CurrentVersion\RunOnce", @"\Winlogon", @"\Services\")
    | project Timestamp, DeviceName, Activity = "registry", Detail = strcat(RegistryKey, " ", RegistryValueName, "=", RegistryValueData);
union BrowserFiles, BrowserRegistry
| order by Timestamp desc

How to tell if a PC was compromised

Code running only inside the renderer sandbox leaves little behind and ends when the tab closes. What you can find depends on how far the attacker got.

• Crash reports from Hunt 3 show failed attempts. Note the time of each one.
• Browsing history around the crash. On the PC, copy the Chrome History file from %LOCALAPPDATA%\Google\Chrome\User Data\<profile>\ and query it with SQLite. Pages that use an XML stylesheet often appear as .xml or .xsl addresses. Subresources loaded by a page are not in History, so also check the proxy logs for the same minutes.

-- Chrome History: visits to XML and XSL addresses, newest first
SELECT datetime(v.visit_time / 1000000 - 11644473600, 'unixepoch') AS visited_utc, u.url
FROM visits v JOIN urls u ON u.id = v.url
WHERE u.url LIKE '%.xsl%' OR u.url LIKE '%.xml%'
ORDER BY v.visit_time DESC LIMIT 200;

• Signs of a sandbox escape are child processes (Hunt 5), files and autorun keys written by the browser (Hunt 6), and new services or scheduled tasks created in the minutes after a crash.
• Session theft. Code in the renderer can read data from the site that was open in that tab. Check sign-ins to Microsoft 365 and other web apps from new IP addresses or devices for the user in the following hours, and new browser extensions in chrome://extensions.

Responding to a suspected compromise

1. Isolate the PC in Defender, and keep the Crashpad reports, the browser profile folder and the timeline from Hunts 3 to 6.
2. Revoke the user’s sessions and refresh tokens, and reset the password. Re-register MFA methods if anything was added in the same window.
3. Update the browser to the fixed build, or disable XSLT by policy, before reconnecting the PC.
4. Block the site that served the XML or stylesheet, and search proxy logs for other users who visited it.
5. Rebuild the PC if the browser started a shell, wrote an executable or created persistence.

Indicators of compromise

None have been published. Google keeps bug details restricted until most users have updated and has not described the attacks. The hunts above look for behavior rather than indicators for that reason.

Timeline

• October 12, 2026: Arni Hardarson (Neonix Security) reports CVE-2026-125346, a use-after-free in XML that the same fix later closes.
• November 4, 2026: Google starts Chrome 158 Early Stable, 158.0.8127.18/.19 for Windows, for a small share of users.
• November 6, 2026: An anonymous researcher reports CVE-2026-125350. ChromeOS Stable ships browser 156.0.8078.93, without the fix.
• November 7, 2026: The libxslt fix lands in Chromium and is merged to the 156, 157 and 158 branches.
• November 8, 2026: Chrome 158.0.8127.30, the first 158 build with the fix, is tagged.
• November 9, 2026: Google releases Chrome 157.0.8103.50/.51, Extended Stable 156.0.8078.96 and Android 157.0.8103.50, and says an exploit exists in the wild. Microsoft says it is aware of the exploits and working on an Edge fix.
• November 10, 2026: The CVE is published with a CVSS score of 8.8. CISA adds it to KEV with a November 24 deadline. Microsoft publishes Edge 157.0.4341.46.
• November 11, 2026: Upstream libxslt has no fix. Microsoft has not yet listed the CVE against an Edge build.

Frequently Asked Questions

Does Chrome update itself? It downloads updates on its own, but the new version only runs after the browser is relaunched. Check the running version, not just the installed one, and force relaunches by policy.

Which version is safe? 157.0.8103.50 or later on Windows, Mac, Linux and Android, 156.0.8078.96 or later on Extended Stable, and 158.0.8127.30 or later for PCs in the Chrome 158 Early Stable group.

Is Microsoft Edge affected? Yes. Edge is built on Chromium, and CISA names it in the KEV entry. Microsoft published Edge 157.0.4341.46 on November 10 but had not linked it to this CVE when we checked on November 11. Update Edge and set XSLTEnabled to false until Microsoft confirms.

Will disabling XSLT break anything? Very little on the public web. Styled RSS feeds and XML sitemaps show as plain XML, and some older business applications that build reports with XSLT may fail. Test those and allow them by policy where needed.

Can this bug alone take over a PC? No. It runs code inside Chrome’s renderer sandbox. Taking over the PC needs a second bug that escapes the sandbox. Google has not said whether the attackers had one, so assume they might.

Are Firefox and Safari affected? Google and CISA name only Chromium browsers. Firefox uses its own XSLT engine, not libxslt. WebKit, Safari’s engine, uses libxslt, but Apple has not said whether Safari is affected.

Who is exploiting it? Google has not said. The researcher who reported it is anonymous, and Google keeps bug details restricted until most users have updated.

What about servers running headless Chrome? Treat them as exposed if they render pages or HTML from outside your organization. Upgrade the browser build that Puppeteer, Playwright or your PDF service uses, then rebuild the images.

How ThreatDefence is responding

ThreatDefence has added CVE-2026-125350 and the fixed Chrome, Extended Stable and Early Stable builds to our vulnerability intelligence. Across all monitored environments, our SOC is:

• identifying PCs running Chrome or Edge below the fixed builds, including browsers that were updated but not relaunched
• watching for browser crash bursts, shells and script hosts started by browsers, and files or autorun keys they write
• helping customers roll out the XSLTEnabled and relaunch policies where updates lag

If you want help checking your fleet or investigating a suspicious browser crash, contact us. Read more about our managed detection and response.

Sources

• Google Chrome Releases, Stable Channel Update for Desktop (November 9, 2026)
• Google Chrome Releases, Extended Stable Update for Desktop (November 9, 2026)
• Google Chrome Releases, Chrome for Android Update, 157.0.8103.50 (November 9, 2026)
• Google Chrome Releases, Early Stable Update for Desktop (November 4, 2026)
• Google Chrome Releases, Stable Channel Update for ChromeOS (November 6, 2026)
• Chromium source, Fix use-after-free in libxslt direct pattern match cache (commit 61cab3f)
• NVD, CVE-2026-125350
• CISA, Known Exploited Vulnerabilities catalog (CVE-2026-125350 added November 10, 2026)
• Google Chrome Enterprise, XSLTEnabled policy
• Google Chrome Enterprise, RelaunchNotification policy
• Microsoft Learn, Microsoft Edge XSLTEnabled policy
• Microsoft Learn, Release notes for Microsoft Edge security updates (checked November 11, 2026)
• GNOME, libxslt source repository (checked November 11, 2026)
• Microsoft Learn, DeviceTvmSoftwareInventory table (Defender XDR advanced hunting)
• Microsoft Learn, DeviceProcessEvents table (Defender XDR advanced hunting)