CVE-2024-55549

Executive Summary

CVE-2024-55549 is a use-after-free vulnerability in the xsltGetInheritedNsList function of libxslt, a widely used C library for XSLT transformations. The flaw arises from improper handling of namespace inheritance when exclusion of result prefixes is applied. An attacker can craft a malicious XSLT stylesheet that, when processed by an application using libxslt (e.g., web browsers, document converters, or XML processing pipelines), triggers a use-after-free condition. This can lead to arbitrary code execution, denial of service, or information disclosure. The vulnerability affects all versions of libxslt prior to 1.1.43. No public exploit code or proof-of-concept is currently available, but the risk is elevated due to the library's widespread use in server-side and client-side software.

Supply Chain & Package Security

libxslt is a critical dependency in many Linux distributions, web servers, and software packages. It is often statically or dynamically linked into applications. The vulnerability can be introduced via:

• Linux package managers: apt, yum, dnf (e.g., libxslt1.1 on Debian/Ubuntu, libxslt on RHEL/CentOS).
• Build systems: Projects using CMake, Autotools, or Meson that fetch libxslt from source or via package managers.
• Container images: Docker images based on vulnerable base images (e.g., ubuntu:20.04, debian:11).
• Language-specific packages: Python’s lxml (which bundles libxslt), PHP’s xsl extension, or Ruby’s nokogiri.

Organizations must audit their software supply chain for any dependency on libxslt < 1.1.43 and update immediately.

CVSS Breakdown & Threat Level

• CVSS Score: 7.8 (High)
• Vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
• Attack Vector (AV): Local – The attacker must provide a malicious XSLT file to the victim application.
• Attack Complexity (AC): Low – No special conditions required beyond processing the malicious file.
• Privileges Required (PR): None – No authentication needed.
• User Interaction (UI): Required – The victim must open or process the malicious XSLT file.
• Scope (S): Unchanged – The vulnerability does not cross trust boundaries.
• Confidentiality (C): High – Potential memory disclosure.
• Integrity (I): High – Potential code execution.
• Availability (A): High – Potential crash or denial of service.

Threat Level: High. While no public exploit exists, the vulnerability is in a core library, and the attack surface is broad (any application processing untrusted XSLT). The use-after-free pattern is well-understood and exploitable.

Deep Dive & Mechanics

The vulnerability resides in xsltGetInheritedNsList within libxslt/namespaces.c. This function is responsible for building a list of inherited namespace nodes for a given XSLT element. When the exclude-result-prefixes attribute is used on an <xsl:stylesheet> or <xsl:transform> element, the library attempts to exclude certain namespace prefixes from the result tree.

Root Cause: During the namespace inheritance calculation, the function incorrectly handles the case where a namespace node is freed (due to exclusion) but a pointer to it is still retained in the inherited list. Specifically, when iterating over ancestor namespaces, the code may free a namespace node that is still referenced by a list entry, leading to a use-after-free when that entry is later dereferenced.

Trigger: An attacker crafts an XSLT stylesheet with a deeply nested structure and carefully placed exclude-result-prefixes attributes. The malicious stylesheet causes the function to free a namespace node while a dangling pointer remains in the inherited list. Subsequent access to that pointer (e.g., to copy the namespace URI) results in a read or write to freed memory.

Impact: Successful exploitation can allow an attacker to:

• Execute arbitrary code in the context of the application processing the XSLT.
• Read sensitive memory (e.g., credentials, encryption keys).
• Cause a denial of service via crash.

Vulnerable vs. Patched Code

Vulnerable Code (libxslt < 1.1.43): In libxslt/namespaces.c, the xsltGetInheritedNsList function contains a logic error where a namespace node is freed but the pointer is not removed from the list.

// Simplified vulnerable snippet
xmlNsPtr *ret = NULL;
int retsize = 0;
// ... iteration over ancestor namespaces ...
if (should_exclude(ns)) {
    xmlFreeNs(ns);  // Free the namespace node
    // BUG: ret still contains a pointer to ns
}
// Later, ret[i] is used, causing use-after-free

Patched Code (libxslt 1.1.43): The fix ensures that after freeing a namespace node, the corresponding entry in the inherited list is set to NULL or removed.

// Simplified patched snippet
xmlNsPtr *ret = NULL;
int retsize = 0;
// ... iteration over ancestor namespaces ...
if (should_exclude(ns)) {
    xmlFreeNs(ns);
    // Fix: Remove the dangling pointer from the list
    for (int j = 0; j < retsize; j++) {
        if (ret[j] == ns) {
            ret[j] = NULL;
            break;
        }
    }
}
// Later, NULL entries are skipped

The patch also includes additional checks to prevent similar issues in other namespace-related functions.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• A target application using libxslt < 1.1.43 (e.g., a web server with XSLT processing, a document converter).
• Ability to supply a malicious XSLT file (e.g., via file upload, URL parameter, or email attachment).

Exploitation Steps:

1. Craft Malicious XSLT: Create an XSLT stylesheet that triggers the use-after-free. The stylesheet must include exclude-result-prefixes and a specific namespace structure.
2. Deliver Payload: Send the malicious XSLT to the target application (e.g., via HTTP POST, file upload, or as an email attachment).
3. Trigger Vulnerability: The application processes the XSLT, causing the use-after-free.
4. Achieve Code Execution: Use heap spraying or other techniques to control the freed memory and redirect execution to shellcode.

Example Malicious XSLT (Conceptual):

<?xml version="1.0"?>
<xsl:stylesheet version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:mal="http://malicious.com/ns"
    exclude-result-prefixes="mal">
    <xsl:template match="/">
        <xsl:copy-of select="."/>
    </xsl:template>
</xsl:stylesheet>

Note: Actual exploitation requires precise heap manipulation and may vary by platform.

Blue Team (Defense & Detection)

Detection:

• Monitor for unusual XSLT files being processed, especially those with exclude-result-prefixes attributes.
• Use the YARA and Sigma rules below to detect malicious XSLT files.
• Enable memory protection features (ASLR, DEP, CFG) to mitigate exploitation.

Mitigation:

• Immediately upgrade libxslt to version 1.1.43 or later.
• If upgrading is not possible, apply the vendor patch or use a WAF to block XSLT files with suspicious namespace patterns.
• Restrict the ability to upload or process untrusted XSLT files.

Indicators of Compromise (IOCs)

• File Hashes: (None available yet, but monitor for new samples)
• Network Signatures: XSLT files containing exclude-result-prefixes with unusual namespace URIs.
• Process Behavior: Applications using libxslt crashing with segmentation faults or heap corruption errors.
• Memory Artifacts: Dangling pointers to freed xmlNs structures in heap dumps.

Detection Engineering

YARA Rule

rule CVE_2024_55549_XSLT_Exploit {
    meta:
        description = "Detects malicious XSLT files targeting CVE-2024-55549"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-55549"
    strings:
        $xsl_stylesheet = /<xsl:stylesheet[^>]*>/
        $exclude_prefixes = /exclude-result-prefixes\s*=\s*["'][^"']*["']/
        $namespace = /xmlns:[a-zA-Z_][a-zA-Z0-9._-]*\s*=\s*["'][^"']*["']/
    condition:
        $xsl_stylesheet and $exclude_prefixes and #namespace > 2
}

Sigma Rule

title: CVE-2024-55549 - Malicious XSLT File Detection
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects XSLT files with suspicious exclude-result-prefixes usage
author: Valters IT
date: 2025-04-10
logsource:
    category: file_event
    product: windows
detection:
    selection:
        EventID: 11  # FileCreate
        TargetFilename|endswith: '.xsl' or '.xslt'
        TargetFilename|contains: 'upload' or 'temp'
    condition: selection
falsepositives:
    - Legitimate XSLT files with exclude-result-prefixes
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-55549 - Malicious XSLT Upload"; flow:to_server; content:"Content-Type|3a| application/xslt+xml"; nocase; content:"exclude-result-prefixes"; nocase; pcre:"/<xsl:stylesheet[^>]*exclude-result-prefixes[^>]*>/i"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade libxslt: Update to version 1.1.43 or later. For Linux distributions, use the package manager:
   • Debian/Ubuntu: sudo apt update && sudo apt install libxslt1.1
   • RHEL/CentOS: sudo yum update libxslt
   • Alpine: apk add --upgrade libxslt
2. Rebuild Applications: If libxslt is statically linked, rebuild the application with the updated library.
3. Container Images: Rebuild Docker images with updated base images.

Compensating Controls:

• Web Application Firewall (WAF): Block uploads of XSLT files or inspect them for suspicious patterns.
• Input Validation: Reject XSLT files containing exclude-result-prefixes unless absolutely necessary.
• Sandboxing: Process untrusted XSLT files in a sandboxed environment (e.g., using seccomp, AppArmor, or a container with limited privileges).

Long-Term:

• Implement a Software Bill of Materials (SBOM) to track dependencies.
• Regularly scan for known vulnerabilities using tools like Trivy, Grype, or Snyk.
• Subscribe to security advisories for libxslt and other critical libraries.

Valters IT
Securing Digital Frontiers