#15 xmlto depends on unmaintained walking security hole libxslt, needs other XSLT provider
Closed by anezbeda. Opened by mandree.

libxslt currently has no maintainer and four security incidents open, two of which disclosed, two embargoed, with a track record of more use-after-free bugs, so unless someone steps up and starts maintaining libxslt, xmlto will need to move to a different XML/XSLT library.

See
- last paragraph before signature: https://www.openwall.com/lists/oss-security/2025/06/16/6
- https://www.openwall.com/lists/oss-security/2025/07/11/2
- https://gitlab.gnome.org/Teams/Releng/security/-/wikis/2025#libxml2-and-libxslt where I screenshot the latter at 2025-07-12T08:20Z.

See
https://gitlab.gnome.org/GNOME/libxslt/-/issues/139 CVE-2025-7424
https://gitlab.gnome.org/GNOME/libxslt/-/issues/140 CVE-2025-7425
and once they will be made public these will also appear:
https://gitlab.gnome.org/GNOME/libxslt/-/issues/144
https://gitlab.gnome.org/GNOME/libxslt/-/issues/148

screenshot-libxml2-libxslt-wiki-security.png


Hi, since as far as I looked into this there isn't an easy drop-in replacement for libxslt, it's currently not easily possible to get rid of that dependency.

Since all the security issues come from the dependency and not this project, I'm afraid there is no easy fix for this. Of course contributions are welcome if anyone would want to take on such task and get rid of the dependency, but I feel like someone will have to step up and maintain the libxslt anyway as this is not the only dependency of it and it also is used by many very large applications.

Metadata Update from @anezbeda:
- Issue status updated to: Closed (was: Open)

Metadata