CVE-2026-125350 (CVSS 8.8): Chrome’s 8th Zero-Day of 2026 Actively Exploited — Patch Before CISA’s November 24 Deadline
Your browser is likely running a version of Chrome that Google is actively urging you to close and relaunch right now. On November 9, 2026, Google shipped an emergency security update for Chrome to fix CVE-2026-125350 — a use-after-free vulnerability in the browser’s XML/XSLT engine that is already being exploited in the wild. CISA has added it to its Known Exploited Vulnerabilities (KEV) Catalog with a mandatory remediation deadline of November 24, 2026 for all U.S. federal agencies — and an urgent wake-up call for every enterprise globally. This is Chrome’s eighth actively exploited zero-day of 2026. At this pace, attackers aren’t waiting for lag between disclosure and patching. Neither should you.
- CVE-2026-125350 is a High-severity (CVSS 8.8) use-after-free in Chrome’s bundled libxslt library — triggerable via a crafted web page, no download required.
- Google confirmed active exploitation in the wild; the fix shipped in Chrome 157.0.8103.50 on November 9, 2026.
- CISA has set a November 24, 2026 deadline for federal agencies; enterprise IT teams should treat this with the same urgency.
- The same update also closes CVE-2026-125346, another XML use-after-free reported in October 2026.
- Enterprise mitigation options include forced relaunch via Chrome Browser Cloud Management, Intune, or GPO, or disabling XSLT processing altogether on Chrome 146+.
- Microsoft Edge, which also embeds Chromium, had not mapped a specific fixed build as of November 11, 2026 — monitor Microsoft’s Security Response Center for updates.
A Year of Browser Zero-Days: Why CVE-2026-125350 Matters
When a critical browser vulnerability receives a CISA KEV designation, it signals that threat actors are actively weaponising it — not just testing proof-of-concept code in a lab. For security leaders in India and globally, Chrome’s eighth zero-day of 2026 carries a stark message: browser attack surfaces are relentless, and patch cadence must match attacker speed.
Chrome holds approximately 65% of global desktop browser market share. In Indian enterprises and government organisations — where Google Workspace, cloud-based ERPs, and SaaS platforms dominate the daily workflow — Chrome is the universal gateway to business-critical data. A use-after-free that executes arbitrary code inside the browser sandbox via nothing more than a crafted HTML page represents an extraordinary risk to any workforce that browses the web, which is to say: every workforce.
The 2026 Chrome zero-day record is now sobering: CVE-2026-125350 is the eighth actively exploited Chrome flaw patched this calendar year, following earlier flaws in V8, PDFium, and other components. For comparison, 2024 saw nine Chrome zero-days for the entire year. We are not yet at year-end 2026.
Technical Breakdown: The libxslt Use-After-Free
CVE-2026-125350 lives in libxslt, the open-source XSLT (Extensible Stylesheet Language Transformations) library that Chrome bundles internally for processing XML documents and their stylesheets. The root cause, confirmed in public Chromium patch notes, is a use-after-free (CWE-416) arising during nested XML evaluation.
In plain terms: when a stylesheet triggers a recursive or nested transformation, the libxslt engine can free and replace a cached object in memory before an earlier evaluation is fully completed. The earlier operation still holds a stale pointer to that freed memory location. An attacker who can craft the right XML/XSLT payload can influence what occupies that freed region, then trigger the stale pointer read — a classic heap spray setup that can redirect execution to attacker-controlled code.
The practical exploitation path is alarming in its simplicity:
- Attacker hosts a web page containing a crafted
<xsl:stylesheet>payload. - Victim visits the page in an unpatched Chrome browser — no additional click or download is required.
- The XSLT engine processes the malicious stylesheet, triggering the use-after-free.
- Arbitrary code executes inside the Chrome renderer process (sandbox context).
- A second-stage exploit can then chain a sandbox-escape to gain broader OS access.
An anonymous researcher reported the flaw on November 6, 2026. Google’s response time — patch in production on November 9, three days later — reflects the severity of active exploitation. The same fix closes a second XML use-after-free, CVE-2026-125346, reported in October.
Important note: The upstream libxslt project had not, as of November 11, 2026, adopted Chromium’s specific patch. Any application that embeds libxslt independently (not via Chrome) needs to track its own vendor’s upstream changelog.
Scope and Affected Versions
| Channel | Vulnerable Below | Fixed Version |
|---|---|---|
| Stable (Windows/Mac) | 157.0.8103.49 | 157.0.8103.50 / .51 |
| Extended Stable | 156.0.8078.95 | 156.0.8078.96 |
| Early Stable (158) | 158.0.8127.29 | 158.0.8127.30+ |
| Microsoft Edge | TBD (Chromium-based) | Monitor Microsoft MSRC |
Note: Enterprise scanner teams should compare against the correct fixed build per channel; a simple “below 157.0.8103.50” check will miss Early Stable 158 builds released before the patch.
What You Should Do: Enterprise Defense Playbook
As a cybersecurity consultant who has helped Indian enterprises and government bodies harden endpoint security and browser policies, I want to be direct: this is not a “wait for the next scheduled update” situation. Active exploitation means attackers are using this right now. Here is the action sequence every IT and security team should execute immediately:
1. Verify Current Chrome Version Across All Endpoints
Open Chrome → Help → About Google Chrome. The version must be 157.0.8103.50 or later. If Chrome shows an update pending, click Relaunch — the update is not effective until the browser restarts. Many users inadvertently leave Chrome open with an update pending for days.
2. Force Enterprise Deployment
Use Chrome Browser Cloud Management, Microsoft Intune, or Group Policy to push the minimum version requirement. Set a forced relaunch deadline of 24–48 hours. Chrome supports the RelaunchNotification policy to show users a countdown banner before mandatory restart.
3. Apply the XSLTEnabled Workaround for Slower Fleets
For endpoints where immediate upgrade is blocked (legacy hardware, approval queues, remote field sites), Chrome 146+ supports the XSLTEnabled policy, which disables all XSLT processing. While this may break a small number of legacy web applications that rely on client-side XSLT, the risk tradeoff strongly favours disabling the feature until patching is complete.
4. Scan Web Proxies and Logs for Suspicious XSLT Requests
Review proxy logs for Content-Type: application/xslt+xml or text/xml responses containing <xsl:stylesheet> that originate from unfamiliar or external hosts. Legitimate enterprise web applications rarely serve XSLT over the open internet. Anomalous patterns may indicate watering-hole or phishing delivery of the exploit.
5. Brief the SOC and Threat Intelligence Teams
Share this advisory — including CISA’s KEV entry and the November 24 remediation deadline — with your NOC/SOC team. Threat hunting queries for use-after-free exploit patterns in browser telemetry and EDR logs should be activated. Platforms like Qualys, Tenable, and CrowdStrike Falcon have published detection guidance specific to CVE-2026-125350.
6. Extend Checks to Edge and Electron Applications
Microsoft Edge is Chromium-based. Any Electron-based internal application (Slack, Teams clients, internal dashboards) may also bundle a vulnerable Chromium version. These will need separate review and updates through their respective vendor channels.
The November 2026 threat landscape has been exceptionally dense — from the Microsoft Patch Tuesday record haul to Outlook zero-days and beyond. Browser vulnerabilities like CVE-2026-125350 are particularly dangerous because the browser is the most common attack surface in any enterprise: it is always open, always trusted, and directly touches the most sensitive SaaS applications your organisation runs.
India-Specific Considerations
Indian organisations face some compounding factors that make prompt patching more urgent:
- High Chrome penetration in SME and enterprise environments: Chrome dominates browser usage in Indian workplaces, often as the default browser for GST portals, banking, MCA21, and state e-governance platforms — all accessed daily by finance and compliance teams whose workstations may not auto-update.
- CERT-In alignment: India’s Computer Emergency Response Team (CERT-In) tracks CISA’s KEV advisories closely. Expect a CERT-In advisory (CIAD-2026-xxxx) for CVE-2026-125350 within the next 24–48 hours if not already issued. Organisations under CERT-In’s reporting obligations should prepare incident documentation procedures.
- IT/ITeS and BPO sector exposure: Large IT services and BPO firms operating hundreds of thousands of endpoints across India are prime targets for browser-delivered malware — particularly credential harvesting from web applications running in Chrome tabs.
- MeitY and NIC systems: Government portals often lag commercial entities on browser versioning. IT administrators managing NIC endpoints should treat the CISA deadline as a minimum; a faster timeline is strongly advisable.
Frequently Asked Questions
Does Chrome auto-update fix this automatically?
Chrome’s auto-update will download the patch, but the fix does not apply until the browser is relaunched. Many users keep Chrome open for days without restarting. You can check: in the top-right menu (⋮), if you see a coloured update icon (green, orange, or red), click it and select Update Google Chrome then Relaunch. Green means the update has been waiting under 2 days; orange, 4 days; red, 7+ days.
Am I safe if I use Google Chrome on Android or iOS?
The CVE-2026-125350 flaw is in the desktop (Linux-based) Chromium rendering engine. Chrome on Android and iOS uses different rendering configurations and is typically updated through the respective app stores. Google has not indicated that mobile Chrome versions are affected by this specific flaw, though users should ensure their mobile Chrome is up to date as a general practice.
What about other browsers that use Chromium?
Brave, Opera, Vivaldi, and other Chromium-based browsers all bundle libxslt. Each vendor applies Chromium patches on its own schedule — typically within days of a major Chromium security release. Users of these browsers should update immediately and check their browser’s release notes for the CVE-2026-125350 patch confirmation. Microsoft Edge users should monitor Microsoft’s Security Response Center for a specific fixed Edge build announcement.
How serious is this compared to the other Chrome zero-days in 2026?
All eight Chrome zero-days patched in 2026 have been High or Critical severity with confirmed in-the-wild exploitation. What distinguishes CVE-2026-125350 is its trigger mechanism — no user interaction beyond page load is required, and the vector is XML/XSLT, a component that is active on a wider range of web applications than, say, the V8 JavaScript engine bugs. CISA’s prompt KEV designation and the tight 15-day remediation deadline signal that the threat intelligence community considers this particularly time-sensitive.
Is your organisation still running unpatched browsers across a fleet of hundreds or thousands of endpoints? Browser patch compliance is one of the fastest-improving and highest-ROI security hygiene activities any CISO can prioritise — but it requires visibility, enforcement policy, and integration with your endpoint management platform. If your team needs help building a browser security policy, assessing your exposure to CVE-2026-125350, or hardening your enterprise Chrome deployment, reach out to Sanjay Seth for a security assessment. With three decades of experience securing enterprise networks across India — from zero-trust architectures to NOC/SOC operations — PJ Networks is equipped to help you close the gap before the next exploit lands.
Sources: The Hacker News · Qualys ThreatPROTECT · SOC Prime · CISA KEV Catalog · Chrome Geek