PSA: Libxslt is unmaintained and has 5 unpatched security bugs

https://vuxml.freebsd.org/freebsd/b0a3466f-5efc-11f0-ae84-99047d0a6bcc.html

by burnt-resistor • 11 months ago

136 75 11 months ago

vuxml.freebsd.org

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.

bawolff2• 11 months ago

Major browsers responded by deprecating/removing XSLT support

Its probably wrong to think the browser stuff is solely due to lack of maintainer.

ZiiS• 11 months ago

Not directly, but if the most used implementation is unmaintained how popular is the language?

bkor• 11 months ago

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.

mjw1007• 11 months ago

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.

chrismorgan• 11 months ago

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.

acdha2• 11 months ago

Apparently, GNOME bureaucracy is holding up the processing the application of a new maintainer for over a month now.

This wording seems unjustly negative. You’re talking about software which is shipped in every browser, all Linux distributions, and bundled in a ton of languages. A short delay doesn’t seem unwarranted for key bits of infrastructure.

imp0cat• 11 months ago

Does this affect https://lxml.de/ ?

_zagj• 11 months ago

Yes, as it's a front-end to both LibXML2 and LibXSLT.

throwaway290• 11 months ago

There's A LOT downstream then

Svip• 11 months ago

"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

camgunz• 11 months ago

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?

bryanrasmussen3• 11 months ago

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.

simonw• 11 months ago

Firefox uses TransforMiiX.

Historically, MSIE used MSXML and Opera used their own custom engine until they both moved to Blink which uses libxslt.

foul• 11 months ago

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

tannhaeuser• 11 months ago

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.

praseodym• 11 months ago

Someone is working on a Rust XPath 3.1 and XSLT 3.0 library: https://github.com/Paligo/xee

rjsw• 11 months ago

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.

Not my experience, they all have different ideas of what the current node is at any one point in the execution of a script.

mardifoufs• 11 months ago

Wait, so what's the reason for the W3C going against its own policy? Is it okay since it's just a recommendation?

rleigh• 11 months ago

And also in QtXmlPatterns (now also retired).

Just for the record, Xalan-C is even less maintained than libxslt. It had no releases for over a decade, and I made a final 1.12 release in 2020 adding CMake support, since the existing builds had bitrotted significantly, along with a number of outstanding bugfixes.

I initiated its removal to the Apache attic in 2022 in https://marc.info/?l=xalan-c-users&m=165593638018553&w=2 and the vote to do this was in https://marc.info/?t=166514497300001&r=1&w=2&n=20. It has now gone nearly four years without any commits being made.

It's a great shame we are now in a situation where there is only a single proprietary implementation of the very latest version of the standard, but even the open-source 1.x implementations are fading fast. These technologies have fallen out of favour, and the the size and complexity of the standards is such that it's a non-trivial undertaking to keep them maintained or create a modern reimplementation.

ptx• 11 months ago

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.

gwd• 11 months ago

we can't have SQLite because there's only 1 implementation

Well now there are [1] at least [2] three [3] implementations, right?

[1] sqlite.org

[2] https://github.com/tursodatabase/libsql

[3] https://github.com/tursodatabase/turso

jmull• 11 months ago

We actually have three distinct one-of-one libraries.

There's no standard, so there's no way to really evaluate how standards-compliant they are.

It seems like the idea is for the turoso projects to be compatible with sqlite, but it's not clear exactly what means.

As a fork, libsql could be kept reasonably backward compatible with recent versions of sqlite by keeping up with merging changes, and avoiding extending sql in conflicting ways. That seems doable if they keep up with the merges, though mainly because they share very large parts of the implementation, so it's not clear it counts as a separate implementation from a web standards perspective.

Turso seems like a reimplementation and has a while to go before it achieves some level of compatibility. It probably needs to be much further along before we can really even evaluate it.

acdha2• 11 months ago

As others have pointed out there are multiple implementations of XSLT, but I’d also argue that this situation seems like a decent argument in favor of that policy. If everyone is using a single implementation then in practice that implementation is the standard and things like Hyrum’s law become serious considerations.

XSLT is grandfathered in from the early days of the web, and while it’s turned out better than Microsoft exposing random COM interfaces which even Windows developers hated it’s still something of a cautionary example of a feature which never really caught on but browser developers have to support decades later or be willing to break a modest number of sites, some relatively important in particular niches like government information. I think of what happened with WebSQL as a reaction to the maintenance costs of a decade earlier.

joshkel• 11 months ago

I assume you're referring to Web SQL? As I understand it, the argument against isn't just "there's only 1 implementation," it's "there's no standard and there's only 1 implementation," so the standard would have to devolve to "whatever that 1 implementation does."

https://hacks.mozilla.org/2010/06/beyond-html5-database-apis...

x0x02• 11 months ago

Ignoring, obviously, all parallels to chrome itself...

rasz• 11 months ago

From what I remember main argument was 'developer aesthetics', and then we got unusable without wrappers nonsensical IndexedDB.

JimDabell• 11 months ago

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

nwellnhof3• 11 months ago

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.

Wowfunhappy3• 11 months ago

Google refused to pay bounties for valid reports because I was a contributor to libxslt

Huh?

Cyykratahk• 11 months ago

I'm guessing Google is avoiding the scenario where a contributor "accidentally" commits code with a bug, then later reports the bug they "found".

bryanrasmussen3• 11 months ago

it seems reasonable, if you report bugs in things you contribute to and this was allowed there would be a perverse incentive to inject bugs to have something to report on, furthermore if you are a contributor to a project that is the source of the bugs you have potentially an unfair advantage compared to every other potential reporter of bugs.

on edit: because obviously you probably become aware of bugs in your own projects before other people do.

jimbokun• 11 months ago

https://devhumor.com/media/dilbert-s-team-writes-a-minivan

securesaml• 11 months ago

Google has a program where you can submit patches to OSS projects (including libxslt) https://bughunters.google.com/about/rules/open-source/492808...

The patches need to fix a systemtic design flaw (which seems like you are trying to do).

You are eligible even if you are a contributor:

Q: I'm a core developer working on one of the in-scope projects. Do my own patches qualify?
A: They most certainly do.

Additionally, github has: https://resources.github.com/github-secure-open-source-fund/

Companies have changed after seeing the log4j incident and are open to funding open source security (but we still need more)

nwellnhof3• 11 months ago

I'm aware of the Patch Rewards program. The problem is that you have to complete the work first and then hope that you'll be rewarded. They also had a Security Subsidies program with upfront payments but this was discontinued in December 2024.

Github's program is restricted to Github repos, making it useless for many projects.

dwaite• 11 months ago

Infrastructure-wise, XML digital signature implementations have to do transforms to convert the XML to the signed octet stream, and commonly use XSLT engines to do so. There was a fun early bug where one of the transforms that Xerces had was that you could include base64 encoded data, and it would load that as a java class against the transformer interface and execute it.

grandinj2• 11 months ago

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?

tempfile• 11 months ago

That's interesting, I thought the Linux Foundation just existed to give corporations somewhere to put their money without it actually making an effective difference.

arccy• 11 months ago

While the Linux Foundation can provide some support, it's still up to each project to find their own maintainers (and pay for them).

grandinj2• 11 months ago

That is a pity. Clearly we need some kind of

   Home For Abandoned Code

:-)

the_biot• 11 months ago

They had a project called the Core Infrastructure Initiative that had similar goals, but it was abandoned long ago.

firesteelrain• 11 months ago

Relevant: https://opensourcesecurity.io/2025/08-oss-one-person/

SigmundA• 11 months ago

Looks like there is a WASM polyfill for XSLT based on libxslt:

https://github.com/mfreed7/xslt_polyfill

To me this is the best way forward, I used to like XSLT quite a bit but the world has moved on and I get browser maintainers not wanting to try and maintain that extra native code surface area.

It seems like the browser should be incorporating many libraries as WASM to mitigate exploits and surface area such as XSLT and rarely used image formats etc. Then only do the native versions for widely used features where it's worth the effort to maintain and vet them.

notherhack• 11 months ago

On my system I see that libxslt is a dependency for glib, gtk+, samba, systemd, pam, and a bunch of others. That's pretty foundational. What could possibly go wrong?

nwellnhof3• 11 months ago

It's only a build dependency to generate documentation with DocBook stylesheets.

PSA: Libxslt is unmaintained and has 5 unpatched security bugs

Related Stories