Google Chrome’s engineering team has begun phasing out inline XSLT processing in SVG files, starting with Chrome M147, eliminating a decades-old XML transformation pathway that security researchers have long flagged as a latent attack surface and a critical blocker to migrating Chrome’s XML engine to memory-safe Rust.
A specially crafted XML file can embed an XSL stylesheet via a processing instruction (<?xml-stylesheet type="text/xsl" ...?>) that transforms generic XML data into an SVG image entirely on the client side.
This XSLT-in-SVG technique allows a single XML document to behave like a chameleon, rendering as a static image when embedded via an <img> < img> tag, but expanding into a full, script-capable HTML document when navigated to directly.
Security researchers said at Black Hat that this dual-behavior characteristic can be weaponized for Active Image Injection (AII) attacks, enabling cross-site scripting filter bypasses on browsers that support inline XSLT within SVG.
XSLT injection is a class of vulnerability in which attackers inject malicious content into XSL stylesheets, potentially resulting in file disclosure, server-side request forgery (SSRF), or remote code execution via XSLT extension functions.
When combined with SVG’s rich feature set, including scripting, external resource loading, and DOM access, inline XSLT in SVG creates a compound threat surface that is disproportionate to its actual utility on the modern web.
Use Counters Confirm Near-Zero Real-World Usage
Chrome’s engineering team introduced two new use counters specifically to measure the real-world footprint of this feature before committing to removal:
- XSLPIInSVGImage (UseCounter ID 5777) tracks XSLT processing instructions referenced as external image resources
- XSLPIInSVGStandaloneDoc (UseCounter ID 5778) tracks XSLT processing instructions in standalone navigated SVG documents
Data collected across Canary and Dev channels returned a value of 0%, confirming that this functionality is virtually non-existent on the live web.
The negligible usage rate eliminates any meaningful backward-compatibility concerns and strengthens the case for immediate removal rather than a prolonged deprecation period.
Chrome engineer Dominik Röttsches (drott@chromium.org), owner of the Blink>SVG component, proposed removing this functionality immediately in M147 without requiring a separate Intent to Deprecate or Intent to Remove (I2D/I2R) process.
The libxml2 Problem: A C Library with a Security Debt
The removal is not only a standalone hardening measure, but also a prerequisite for Chrome’s broader transition away from libxml2. This C-based XML parsing library has accumulated a significant backlog of CVEs.
Recent vulnerabilities include CVE-2025-49794 and CVE-2025-49796 (CVSS 9.1), both use-after-free conditions triggered during XPath parsing, and CVE-2025-24928 (CVSS 7.8 High), a critical flaw affecting multiple downstream products, including Red Hat and NetApp.
In late 2025, libxml2 was officially declared unmaintained, raising serious long-term concerns about its suitability for processing untrusted input in a browser context.
To address this systemic risk, Chrome is replacing libxml2 with a memory-safe XML parser written in Rust. Rust’s ownership model eliminates entire categories of memory corruption bugs, use-after-free, buffer overflows, and double-free vulnerabilities that have historically plagued C-based parsers.
However, the Rust XML parser cannot be safely deployed to scenarios that may trigger XSLT processing, because the XSLT pipeline still depends on the legacy C-based code path. Removing inline XSLT in SVG directly unblocks the Rust parser’s rollout to SVG processing scenarios.
Browser Compatibility Landscape
The behavior of inline XSLT in SVG has always been inconsistent across major browsers, which further undermines any argument for preserving it:
| Browser | Inline XSLT in Standalone SVG | Inline XSLT in <img>-Referenced SVG |
|---|---|---|
| Chrome (pre-M147) | Supported | Not supported |
| Firefox | Supported | Not supported |
| Safari / WebKit | Supported | Supported |
| Chrome M147+ | Removed | Already removed |
WebKit has issued a Positive signal on the deprecation proposal, and both Mozilla and Apple have separately expressed support for deprecating XSLT in general at the WHATWG level (Issue #11523).
The broader XSLT deprecation in Chrome follows a staged timeline: deprecated in M143 (December 2025), with enterprise policy controls active since M146 (March 2026), full removal targeted for M155 by November 17, 2026, and final discontinuation of the Origin Trial in M164.
Rollout Strategy for M147
The M147 removal is being rolled out in synchronization with experimental testing of the Rust XML parser and will not immediately reach 100% of stable users.
This phased approach allows Chrome’s engineering team to gather performance and compatibility telemetry from the Rust parser under real-world SVG processing conditions before full commitment.
A prior step disallowing XSLT as an external resource loaded from an image was already enforced in Chromium review chromium-review.googlesource.com/c/chromium/src/+/6943450. The M147 removal represents the logical next step, closing the inline SVG standalone document pathway.
For web developers, the migration path is straightforward: XSLT transformations should be moved to the server, where the output is a static, pre-rendered SVG file delivered to the client.
The <?xml-stylesheet?> The processing instruction remains supported when used with type="text/css" for styling purposes.
Frequently Asked Questions
Q1: What exactly is being removed in Chrome M147?
Chrome M147 removes the ability to use an XSL stylesheet processing instruction inside an SVG file to perform client-side XSLT transformations, a feature tracked by UseCounters XSLPIInSVGImage and XSLPIInSVGStandaloneDoc.
Q2: Is this a security vulnerability being patched?
It is a proactive security hardening measure, not a CVE patch, that eliminates a latent XSLT injection vulnerability and a related SVG-based attack surface while enabling Chrome’s migration to a memory-safe Rust XML parser.
Q3: Will websites break when Chrome M147 is deployed?
No significant breakage is expected, as Chrome’s usage counters show 0% adoption of this feature in the Canary and Dev channels, confirming virtually no active usage on the live web.
Q4: When will XSLT be completely removed from Chrome?
Full XSLT removal across all users is scheduled for Chrome M155, targeted for November 17, 2026, with enterprise policy and Origin Trial extensions available until M164.
Site: thecybrdef.com
About the Author
