by DonHopkins | 2025-11-10 20:08:53+00:00
But as you obviously know, HTML documents do support JavaScript, and there's no reason to link to a raw XML RSS or Atom document directly, so problem solved. If you're so cautious you refuse to enable JavaScript, then you have absolutely no justification for enabling XSLT.

Handwaving that vulnerabilities are "highly unlikely" is dangerous security theater. It doesn't matter how unlikely you guess and wish they are, they just have to be possible. And the fact that the XSLT 1.0 implementations built into browsers are antique un-sandboxed memory-unsafe C++ code make vulnerabilities "highly likely", not "highly unlikely", which the record clearly proves.

Browsers only natively support the ancient version of XSLT 1.0, so if you need a less antiquated version, you should use a modern memory safe sandboxed polyfill, or process it on the server side, or more safely not use XSLT at all and simply use JavaScript instead (simply transforming RSS to HTML directly with JavaScript is a MUCH smaller and harder attack surface than the massive overkill of including an entire sandboxed general purpose Turing complete XSLT processor), instead of foolishly relying on non-sandboxed old untrustworthy poorly maintained C++ code built into the browser.

Of course all versions of XSLT are Turing complete, as you can easily confirm on Wikipedia, and which is quite obvious if you have ever read the manual and used it. It has recursive template calls, conditionals, variables and parameters, pattern matching and selection, text and node construction, unbounded input and recursion depth, etc. So how could it possibly not be Turing complete, since it has the same expressive power of functional programming languages? And that should be quite obvious to anyone who knows XSLT and basic CS101, at a glance, without a formal proof.

https://en.wikipedia.org/wiki/XSLT

>While XSLT was originally designed as a special-purpose language for XML transformation, the language is Turing-complete, making it theoretically capable of arbitrary computations.

Do you recall the title of Chrome's web page explaining why they're removing XSLT? "Removing XSLT for a more secure browser" (aka "Bin Ladin Determined To Strike in XSLT" ;). Didn't you read that article, and the recent HN discussion about it? You can't just claim nobody warned you, like GW Bush tried to do.

https://news.ycombinator.com/item?id=45823059

https://developer.chrome.com/docs/web-platform/deprecating-x...

>Why does XSLT need to be removed?

>The continued inclusion of XSLT 1.0 in web browsers presents a significant and unnecessary security risk. The underlying libraries that process these transformations, such as libxslt (used by Chromium browsers), are complex, aging C/C++ codebases. This type of code is notoriously susceptible to memory safety vulnerabilities like buffer overflows, which can lead to arbitrary code execution. For example, security audits and bug trackers have repeatedly identified high-severity vulnerabilities in these parsers (e.g., CVE-2025-7425 and CVE-2022-22834, both in libxslt). Because client-side XSLT is now a niche, rarely-used feature, these libraries receive far less maintenance and security scrutiny than core JavaScript engines, yet they represent a direct, potent attack surface for processing untrusted web content. Indeed, XSLT is the source of several recent high-profile security exploits that continue to put browser users at risk. The security risks of maintaining this brittle, legacy functionality far outweighs its limited modern utility. [...]

Your overconfidence in XSLT's security in browsers is unjustified and unsupported by its track record and reputation, its complexity is extremely high, it's written in unsafe un-sandboxed C/C++, it gets vastly less attention and hardening and use than JavaScript, and its vulnerabilities are numerous and well documented.

Examples:

CVE‑2025‑7425: A heap use-after-free in libxslt caused by corruption of the attribute type (atype) flags during key() processing and tree-fragment generation. This corruption prevents proper cleanup of ID attributes, enabling memory corruption and possibly arbitrary code execution.

CVE‑2024‑55549: Another use-after-free in libxslt (specifically xsltGetInheritedNsList) disclosed via a Red Hat advisory.

CVE‑2022‑22834: An XSLT injection vulnerability in a commercial application (OverIT Geocall) allowing remote code execution from a “Test Trasformazione XSL” feature. Shows how XSLT engines/processors can be attack surfaces in practice.

CVE­-2019-18197: (libxslt 1.1.33) In the function xsltCopyText (file transform.c) a pointer variable isn’t reset in certain flows; if the memory area was freed and reused, a bounds check could fail and either write outside a buffer or disclose uninitialised memory.

CVE-2008-2935: buffer overflows in crypto.c for libexslt.

CVE-2019-5815: type confusion in xsltNumberFormatGetMultipleLevel, repeated memory safety flaws (heap/stack corruption, improper bounds checks, pointer reuse) in the library over many years.