Chromium has decided to remove support for XSLT and discontinue the use of libxslt and libxml2.

Google has decided to remove the components for supporting the XML transformation language XSLT from the Chromium browser engine. The reason cited is the desire to reduce the attack surface by discontinuing the use of the libxslt library. According to Google, supporting XSLT 1.0 poses unnecessary security risks since vulnerabilities are periodically discovered in the libxslt library (for example, CVE-2025-7425 and CVE-2022-22834), and there are maintenance issues (the library was unmaintained and without vulnerability fixes from June to September). Projects like Firefox and WebKit are also considering removing support for XSLT.

Vulnerabilities in XSLT become a tool for executing attacks on browsers, especially since client support for XSLT is currently unnecessary and used extremely rarely. The tasks of transforming data into HTML can be performed more securely using JavaScript APIs like DOMParser and Fetch. According to Google statistics, the share of loaded web pages that use XSLT is 0.02%, while the share of pages using XSLT processing instructions is estimated at 0.001%.

Similarly, it has been decided to discontinue the use of the libxml2 library in Chromium, which also regularly finds vulnerabilities and has maintenance issues. The libxml2 library is used in Chromium for parsing, serializing, and validating XML data, while the XSLTProcessor class and XSLT processing instructions (‘’) are based on libxslt.

Support for libxslt-based features, such as the XSLTProcessor API and XML style sheet parsing instructions, will be discontinued in Chrome version 155, scheduled for November 17, 2026. In Chrome 143, planned for December 2, 2025, a warning will be added in the web console about the deprecation of the XSLTProcessor API. In Chrome 148 (spring 2026), support for XSLT will be disabled by default in the Canary, Dev, and Beta branches. The functionality for parsing XML will remain but will be switched to a new library written in Rust with a focus on security.

As a replacement for the built-in browser support for XSLT, it is proposed to move XSLT processing to the server side server and send pre-formed HTML content to clients. Handlers using XML APIs for client-server interaction will proxy server, it is proposed to replace it with the use of the JSON format and rendering through transforming JSON into HTML/CSS using JavaScript. Among the possible alternatives, the use of the Saxonica JavaScript libraries implementing XSLT and a polyfill layer to ensure compatibility with legacy code is also noted, offering a replacement for XSLTProcessor based on WASM, and a browser extension that automatically injects the polyfill layer into XML documents.

Source: opennet.ru

Buy reliable website hosting with DDoS protection, VPS VDS servers 🔥 Buy reliable website hosting with DDoS protection, VPS VDS servers | ProHoster