From my experience, these issues are only relevant if you allow the execution of untrusted stylesheets which nobody would ever do. The only exception are browser vendors.
A couple of years ago, I had the idea of funding libxslt development with Google Chrome bug bounties. This was cut short after reporting two or three issues. Google refused to pay bounties for valid reports because I was a contributor to libxslt, regardless of whether these bugs were 20 years old. I must admit that I feel a bit of schadenfreude. On the other hand, it still makes me sad that these companies care so little about upstream projects and OSS in general.
> Finding and exploiting 20-year-old bugs in web browsers
> Although XSLT in web browsers has been a known attack surface for some time, there are still plenty of bugs to be found in it, when viewing it through the lens of modern vulnerability discovery techniques. In this presentation, we will talk about how we found multiple vulnerabilities in XSLT implementations across all major web browsers. We will showcase vulnerabilities that remained undiscovered for 20+ years, difficult to fix bug classes with many variants as well as instances of less well-known bug classes that break memory safety in unexpected ways. We will show a working exploit against at least one web browser using these bugs.
Am I right that, while we can't have SQLite because there's only 1 implementation, we can have XSLT even though there's only 1--unmaintained--implementation?
Isn't the situation essentially the opposite? We apparently can't have it in the standard just because Google don't want to maintain the specific implementation they have chosen for their browser.
Nah, libxslt is a spinoff of Expat, at the very least (and mozilla mantains its own xslt library) there's a full implementation by the standard writer called Saxon[0]
That's at least not something you can accuse XLST 1.0 of. Like most parts of the old "XML stack", XLST 1.0 has ample implementations in Xalan/C, Xalan/J, Saxon, libxslt2, MS XML, to name only mainstream ones. And the portability for XLST 1.0 is almost perfect/gives identical results (up to DOM equivalency eg. attribute ordering, and even beyond) in my experience.
XSLT 2.x/3.y however, while still a "W3C recommendation", violates (or had violated for the longest time) W3C's own policy of at least two interworking implementations to reach "recommendation" stage, and is authored by the vendor of the single XSLT 2.0/3.0 product, which used to be a problem I pointed out several times. Of course, nobody cares about W3C, Inc. anymore, precisely because of those pay-as-you-go and other self-serving policies among other things.
What are you talking about? There are many maintained implementations of XSLT at various levels compliance and versions.
The problem is libxslt is built on top of libxml, and libxml is being used for a bunch of stuff through browsers etc. And that it is a C implementation which most others aren't, actually I say most but not sure if there is a C implementation other than libxslt.
Update 0: Fixed title, it's 5 rather than 4, and possibly another that's undisclosed.
Update 1: Apparently, GNOME bureaucracy is holding up the processing the application of a new maintainer for over a month now. Major browsers responded by deprecating/removing XSLT support. XSLT is/was mainly used for rendering and transforming SGML, HTML, and XML to other forms, I didn't even realize browsers supported it directly. https://gitlab.gnome.org/GNOME/libxslt/-/issues/150
> Please be aware: nobody will merge your fix because there are no active maintainers remaining. (If anybody is interested in maintaining libxslt, please let me know.) Having patches here will help a lot anyway, though, since downstream vendors will be able to use them.
I guess, technically, if libxslt isn't statically or dynamically linked in like browsers and some other programs do and only used as a build dep such as through xsltproc, there's not really a security issue after a build. For all runtime use / direct linking of libxslt, it's still a problem.
> Update 1: Apparently, GNOME bureaucracy is holding up the processing the application of a new maintainer for over a month now.
Could you explain this? You link to a closed bugreport where a new maintainer stepped up. A previously experienced developer said it'll take several months at least to get up to speed.
That a new person needs to be vouched for a critical library is pretty critical. There's been several examples where a malicious developer took over a critical project.
> Major browsers responded by deprecating/removing XSLT support.
This is not true. They’re investigating doing that. There is no actual deprecation yet, and even if they do decide to deprecate and then remove, I imagine the process would take at least a couple of years. The first actual major feature removal from the web would be a big deal.
Blink declared intent to deprecate and remove XSLT in both 2013 and 2015, but gave up on them each time. My feeling is that both sides may actually be stronger this time—browser makers more intent on removing it, and objections louder too.
A decade ago, Google tried to kill MathML in not entirely dissimilar circumstances—though in that case they didn’t even have a shipping implementation themselves. When the dust settled, MathML Core was a thing, and Igalia had implemented it in Chromium. It wouldn’t surprise me if they do end up removing XSLT, but it also wouldn’t surprise me if we actually ended up with a new commitment to XSLT and XSLT 3.0 support out of this commotion. That’s what I’m hoping for.
These days? Not very. However a lot of systems created in the 2000s, particularly enterprise software because XML was seen as the thing for enterprises, depends on it.
It’s not (and never was outside of corporate webapps) very common on the web, but there are still legacy things that need it.
From my experience, these issues are only relevant if you allow the execution of untrusted stylesheets which nobody would ever do. The only exception are browser vendors.
A couple of years ago, I had the idea of funding libxslt development with Google Chrome bug bounties. This was cut short after reporting two or three issues. Google refused to pay bounties for valid reports because I was a contributor to libxslt, regardless of whether these bugs were 20 years old. I must admit that I feel a bit of schadenfreude. On the other hand, it still makes me sad that these companies care so little about upstream projects and OSS in general.
Related:
"Remove mentions of XSLT from the html spec" (9 days ago, 388p, 534c) https://news.ycombinator.com/item?id=44952185
"XSLT removal will break multiple government and regulatory sites" (6 days ago, 157p, 142c) https://news.ycombinator.com/item?id=44987346
"Should the web platform adopt XSLT 3.0?" (6 days ago, 133p, 107c) https://news.ycombinator.com/item?id=44987552
"Google did not unilaterally decide to kill XSLT" (6 days ago, 102p, 130c) https://news.ycombinator.com/item?id=44987239
Also see:
> Finding and exploiting 20-year-old bugs in web browsers
> Although XSLT in web browsers has been a known attack surface for some time, there are still plenty of bugs to be found in it, when viewing it through the lens of modern vulnerability discovery techniques. In this presentation, we will talk about how we found multiple vulnerabilities in XSLT implementations across all major web browsers. We will showcase vulnerabilities that remained undiscovered for 20+ years, difficult to fix bug classes with many variants as well as instances of less well-known bug classes that break memory safety in unexpected ways. We will show a working exploit against at least one web browser using these bugs.
— https://www.offensivecon.org/speakers/2025/ivan-fratric.html
— https://www.youtube.com/watch?v=U1kc7fcF5Ao
Is this not what the Linux Foundation was about at one stage?
Taking ownership of unmaintained projects so that at least they have the bare minimum of patches being applied, CI/CD running, releases being created?
Am I right that, while we can't have SQLite because there's only 1 implementation, we can have XSLT even though there's only 1--unmaintained--implementation?
Isn't the situation essentially the opposite? We apparently can't have it in the standard just because Google don't want to maintain the specific implementation they have chosen for their browser.
Nah, libxslt is a spinoff of Expat, at the very least (and mozilla mantains its own xslt library) there's a full implementation by the standard writer called Saxon[0]
[0] https://www.saxonica.com/saxon-c/index.xml
Firefox uses TransforMiiX.
Historically, MSIE used MSXML and Opera used their own custom engine until they both moved to Blink which uses libxslt.
That's at least not something you can accuse XLST 1.0 of. Like most parts of the old "XML stack", XLST 1.0 has ample implementations in Xalan/C, Xalan/J, Saxon, libxslt2, MS XML, to name only mainstream ones. And the portability for XLST 1.0 is almost perfect/gives identical results (up to DOM equivalency eg. attribute ordering, and even beyond) in my experience.
XSLT 2.x/3.y however, while still a "W3C recommendation", violates (or had violated for the longest time) W3C's own policy of at least two interworking implementations to reach "recommendation" stage, and is authored by the vendor of the single XSLT 2.0/3.0 product, which used to be a problem I pointed out several times. Of course, nobody cares about W3C, Inc. anymore, precisely because of those pay-as-you-go and other self-serving policies among other things.
What are you talking about? There are many maintained implementations of XSLT at various levels compliance and versions.
The problem is libxslt is built on top of libxml, and libxml is being used for a bunch of stuff through browsers etc. And that it is a C implementation which most others aren't, actually I say most but not sure if there is a C implementation other than libxslt.
Update 0: Fixed title, it's 5 rather than 4, and possibly another that's undisclosed.
Update 1: Apparently, GNOME bureaucracy is holding up the processing the application of a new maintainer for over a month now. Major browsers responded by deprecating/removing XSLT support. XSLT is/was mainly used for rendering and transforming SGML, HTML, and XML to other forms, I didn't even realize browsers supported it directly. https://gitlab.gnome.org/GNOME/libxslt/-/issues/150
--- List
0: https://gitlab.gnome.org/GNOME/libxslt/-/issues/139
1: https://gitlab.gnome.org/GNOME/libxslt/-/issues/140
2: https://gitlab.gnome.org/GNOME/libxslt/-/issues/144
3: https://gitlab.gnome.org/GNOME/libxslt/-/issues/148
4: BIGSLEEP-433713988 https://issuetracker.google.com/issues/433713988
> Please be aware: nobody will merge your fix because there are no active maintainers remaining. (If anybody is interested in maintaining libxslt, please let me know.) Having patches here will help a lot anyway, though, since downstream vendors will be able to use them.
https://gitlab.gnome.org/GNOME/libxslt/-/issues/144#note_245...
List of FreeBSD ports that are unlikely to build without `make DISABLE_VULNERABILITIES=yes`:
https://pastebin.com/raw/5dQ2U46f
I guess, technically, if libxslt isn't statically or dynamically linked in like browsers and some other programs do and only used as a build dep such as through xsltproc, there's not really a security issue after a build. For all runtime use / direct linking of libxslt, it's still a problem.
> Update 1: Apparently, GNOME bureaucracy is holding up the processing the application of a new maintainer for over a month now.
Could you explain this? You link to a closed bugreport where a new maintainer stepped up. A previously experienced developer said it'll take several months at least to get up to speed.
That a new person needs to be vouched for a critical library is pretty critical. There's been several examples where a malicious developer took over a critical project.
> Major browsers responded by deprecating/removing XSLT support.
This is not true. They’re investigating doing that. There is no actual deprecation yet, and even if they do decide to deprecate and then remove, I imagine the process would take at least a couple of years. The first actual major feature removal from the web would be a big deal.
Blink declared intent to deprecate and remove XSLT in both 2013 and 2015, but gave up on them each time. My feeling is that both sides may actually be stronger this time—browser makers more intent on removing it, and objections louder too.
A decade ago, Google tried to kill MathML in not entirely dissimilar circumstances—though in that case they didn’t even have a shipping implementation themselves. When the dust settled, MathML Core was a thing, and Igalia had implemented it in Chromium. It wouldn’t surprise me if they do end up removing XSLT, but it also wouldn’t surprise me if we actually ended up with a new commitment to XSLT and XSLT 3.0 support out of this commotion. That’s what I’m hoping for.
It's clear from that bug tracker that you shouldn't let libxlst see untrusted stylesheets or xpath expressions.
I haven't yet seen a problem with running your own transformations against untrusted XML.
Maybe a new maintainer could aim to make the second case fully supported but not the first.
> Major browsers responded by deprecating/removing XSLT support
Its probably wrong to think the browser stuff is solely due to lack of maintainer.
Not directly, but if the most used implementation is unmaintained how popular is the language?
These days? Not very. However a lot of systems created in the 2000s, particularly enterprise software because XML was seen as the thing for enterprises, depends on it.
It’s not (and never was outside of corporate webapps) very common on the web, but there are still legacy things that need it.
Does this affect https://lxml.de/ ?
Yes, as it's a front-end to both LibXML2 and LibXSLT.