In June 2024, a new vulnerability tracked as CVE-2024-55549 was identified in the popular XML stylesheet library libxslt. This bug, lurking since before version 1.1.43, affects the way libxslt manages namespace lists during XSLT transformations. This post will walk you through what happened, show some code snippets that demonstrate the problem, and explain how attackers could potentially exploit this issue.

What is libxslt?

libxslt is an open source library widely used for transforming XML documents using XSLT (eXtensible Stylesheet Language Transformations). System utilities, web frameworks, and even browsers link against libxslt to render or process XML data.

The Problem: Use-After-Free In xsltGetInheritedNsList

In simple words, a use-after-free occurs when a program keeps using a pointer to memory that has already been freed (returned to the memory allocator), meaning it now points to invalid data. Attackers can sometimes take advantage of this to trick a program into running malicious code.

The function xsltGetInheritedNsList, which assembles the namespaces to inherit while resolving exclusions in exclude-result-prefixes, has a bug that can make it access memory it already freed if certain conditions are met.

Let’s Look at the Code

This is a simplified and illustrative example. The original code is a bit more complex, but here’s a key snippet showing where things go wrong:

xmlNsPtr *
xsltGetInheritedNsList(xsltTransformContextPtr ctxt, xmlNodePtr node) {
    xmlNsPtr *list, *tmp;
    // ... logic for allocating 'list'
    if (exclude_ns) {
        for (i = ; i < list_len; i++) {
            if (list[i] == exclude_ns) {
                // Remove the excluded ns
                memmove(&list[i], &list[i+1], (list_len - i - 1) * sizeof(list[]));
                list_len--;
                // Here's the bug: If exclude_ns is freed, but 'list'
                // still has pointer(s) to that memory, a use-after-free occurs.
            }
        }
    }
    // ... further code
    return list;
}

In older libxslt, if a result prefix is excluded, the namespace may be freed, but the returned namespace list (list) isn’t fully updated. This leaves pointers to freed memory, and later code can access these—potentially giving an attacker a foothold.

Any program using libxslt < 1.1.43

- Especially if it processes untrusted XML/XSLT input, like in web services, XML APIs, etc.

Possible Exploit Scenarios

An attacker crafts a malicious XSLT document that uses exclude-result-prefixes in a tricky way to trigger the bug. After triggering use-after-free, the attacker might:

Possibly (though less likely, but serious!) execute arbitrary code

This depends on what code is running, memory layout, system protections (like ASLR, DEP), etc.

Here’s a Minimal Example of a Trigger

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
                xmlns:evil="http://attacker.com/evil";
                exclude-result-prefixes="evil"
                version="1.">
  <xsl:template match="/">
    <evil:attack>Hello</evil:attack>
  </xsl:template>
</xsl:stylesheet>

If a vulnerable version of libxslt (and dependent application) processes this file, the flow inside xsltGetInheritedNsList attempts to exclude the evil prefix—but mishandles the corresponding namespace pointer.

# Fix

libxslt 1.1.43 fixes this by thoroughly managing memory when updating the inherited namespace list, ensuring that:

No returned pointers reference freed memory

Upgrade instructions:

sudo apt-get update && sudo apt-get install libxslt1.1
# Or pull the latest from https://gitlab.gnome.org/GNOME/libxslt

References

- Debian Security Tracker CVE-2024-55549
- libxslt Gitlab Repository
- Upstream Patch *(replace with real commit when available)*
- OSS-Security Mailing List Discussion

What Should You Do?

If you maintain or use any software that uses libxslt, update it right away! Even if you don’t directly use XML/XSLT, other components of your stack may do so.

Audit your applications for direct use of exclude-result-prefixes

- Consider sandboxing or restricting XML/XSLT processing if you handle untrusted data

Final Thoughts

Memory safety bugs like this are a reminder that libraries we take for granted can sometimes hide serious issues. CVE-2024-55549 shows how careful attackers might abuse seemingly harmless features like result prefix exclusions in XML transforms.

Patch. Audit. Stay safe!

*If you found this useful, please share or comment. For technical deep dives and practical security tips, subscribe!*

Timeline

Published on: 03/14/2025 02:15:15 UTC