from Hacker News

PSA: Libxslt is unmaintained and has 5 unpatched security bugs

by burnt-resistor on 8/29/25, 3:57 AM with 86 comments

  • by nwellnhof on 8/29/25, 9:02 AM

    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.

  • by Svip on 8/29/25, 6:21 AM

    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

  • by JimDabell on 8/29/25, 8:10 AM

    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

  • by camgunz on 8/29/25, 7:53 AM

    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?

  • by grandinj on 8/29/25, 9:19 AM

    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?

  • by SigmundA on 8/29/25, 2:32 PM

    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.

  • by imp0cat on 8/29/25, 5:41 AM

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

  • by firesteelrain on 8/29/25, 1:01 PM

  • by notherhack on 8/29/25, 3:38 PM

    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?

  • by burnt-resistor on 8/29/25, 4:00 AM

    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.