A newly disclosed use-after-free vulnerability in the libxslt library — tracked as CVE-2025-10911 — can be triggered while parsing XSL nodes and may dereference expired pointers, crashing applications that process untrusted XSL or XML transformations and producing a
total loss of availability for affected services.
Background
libxslt is the GNOME project’s widely used XSLT processor and is embedded across many Linux distributions, server tools, and software stacks that perform XML-to-text or XML-to-HTML transformations. The library implements XSLT 1.0/2.0 features and maintains internal data structures such as
Result Value Trees (RVTs), which are used to hold temporary output fragments during transformation. When internal bookkeeping around these RVTs and associated key/index data goes wrong, freed memory can be referenced later — a classic use-after-free condition. The vulnerability was publicly recorded on September 25, 2025, and quickly propagated into vendor advisories and distribution security trackers. Multiple package maintainers have released or prepared patches; some distributions have already rolled fixes while others deferred updates pending upstream merges. The consensus across CVE trackers is that the flaw results in a denial-of-service (DoS) condition rather than confidentiality or integrity violations, but the availability impact can be severe in production-facing transformation services.
What the vulnerability actually is
The root cause in plain terms
At a technical level, CVE-2025-10911 is caused by
incorrect handling of key-related data across result value trees (RVTs) during XSLT processing. When XSLT functions that operate on keys or that produce temporary result tree fragments interact, key metadata may be associated with RVTs in a way that outlives the fragment’s lifetime. If the RVT is freed but code later assumes the key data remains valid, the program dereferences freed memory and crashes (or worse, enters undefined behavior territory). This is not a trivial string-processing bug — it springs from complicated lifecycle interactions between the transformation context, garbage-collected fragments, and index tables used to implement XSLT’s key function and related features. The presence of
cross-RVT in vendor advisories points specifically to data that is stored for keys but spans the boundaries of multiple RVTs, creating a dangling pointer scenario when one RVT is reclaimed.
Consequence: availability impact
Because the predictable outcome of dereferencing freed memory in user-space C code is a crash or corruption, the most immediate impact is
denial of service. Multiple vendors categorize the confidentiality and integrity impact as
none while rating availability impact as
high — meaning an attacker who can provide crafted XSL or XML inputs to a program using libxslt can repeatedly crash that program or service. This produces either sustained disruption (while the attacker keeps sending payloads) or persistent disruption if the crashing application leaves services in an unrecoverable state.
Who is affected
- Any software that links against libxslt and performs XSLT transformations on attacker-controlled or otherwise untrusted input is potentially vulnerable.
- Common server-side tools, web applications, and system utilities that accept or transform XML/XSL input can be impacted if they use system libraries rather than bundling hardened or patched copies.
- Several major Linux distributions listed libxslt versions in their trackers as vulnerable, with fixes appearing in different release streams at different times — unstable branches often received patches earlier while stable LTS releases in some ecosystems deferred fixes pending backporting.
Distribution guidance shows the problem surfaced across multiple package versions (1.1.34 through 1.1.43 in some trackers) and that maintainers issued upgraded packages or security patches; however, the precise affected version ranges depend on the downstream package (packaging may have backported fixes or left versions unmodified in a particular release). System administrators must consult their distribution security advisories and package versions to determine exposure.
Confirming technical details and discrepancies
Vendor trackers and vulnerability databases largely agree on the vulnerability’s existence and primary effect, but CVSS vectors and exploitability statements show small but important differences.
- Several trackers (including Red Hat and Debian summaries) list the CVSS v3.1 vector as AV:L (Local), AC:L, PR:N, UI:R, with a base score around 5.5, indicating the vulnerability requires local access and user interaction to trigger.
- Some sources and advisories interpret the attack vector more broadly and describe exploitability via network-facing applications where remote users can submit crafted files to do transformations (for example, document import endpoints or web services that accept XSL). Those sources emphasize that remote exploitation is possible if the vulnerable libxslt instance is reachable through a network service that accepts malicious input. This leads to variant CVSS reporting (e.g., higher scores in some distro notes). Administrators should treat the effective attack surface as “wherever untrusted XSL/XML is consumed,” which can be local or remote depending on deployment.
Because downstream packaging, service exposure, and configuration determine whether the vulnerability is exploitable remotely, the difference between “local” and “remote” in databases reflects deployment context rather than contradiction in the underlying bug. Where XSL processing is invoked as part of a remote service (document processors, web-based converters, mail filters, CI pipelines), the practical risk is remote.
Patches, vendor responses, and timeline
Multiple Linux distributors and package maintainers published advisories and patches:
- Debian’s tracker shows fixes landed in unstable and later versions, with fixed package versions identified for the trixie/sid branch and notes that fixes for older releases were postponed in some channels pending upstream merges. Administrators running Debian-based systems should check their repo and upgrade libxslt to the fixed package.
- SUSE published multiple advisories and patches across Leap, SLES, and Micro variants, explicitly calling out “use-after-free with key data stored cross-RVT” and shipping patched package versions such as libxslt 1.1.43 in later updates.
- Amazon Linux (ALAS) entries show fixes for Amazon Linux 2023 and pending fixes for Amazon Linux 2, with CVSS assessments oriented to local attack vectors.
- Upstream GNOME merge requests and issue pages were referenced by vendors as the canonical bug and patch workflow, although direct access to some upstream pages could be rate-limited or protected in some browsing contexts.
Administrators should assume a patch exists upstream and that maintainers have produced distribution-specific packages; the correct action is to apply vendor-supplied patches for your platform rather than trying ad-hoc fixes.
Mitigation and remediation: practical steps
- Prioritize patching:
- Upgrade the libxslt package to the vendor-published fixed version for your distribution. Use your distribution’s official security channels (apt, yum/dnf, zypper) and apply the specific security update packages when available. Check unstable branches only if you have a validated patch process.
- Identify and isolate transformation points:
- Inventory applications and services that perform XSLT transformations. Focus on document converters, web upload handlers, and any components that accept XSL or XML from untrusted sources.
- If patching will be delayed, consider temporarily disabling XSLT processing for untrusted inputs or adding strict filtering to reject XSL files unless they come from known good sources.
- Apply compensating controls:
- Run transformation services as unprivileged accounts and isolate them in containers or sandboxes to limit blast radius.
- Use process supervisors and crash recovery that don’t expose whole-system outages when a single transformation worker crashes.
- Rate-limit and validate file types to reduce the chance of automated mass-exploitation attempts.
- For services exposed to remote inputs:
- Add input sanitation to ensure files conform to expected schemas before invoking an XSLT engine.
- Prefer server-side whitelisting of allowed transformation operations and disable features (like dynamic includes) that are not required by the application.
- Monitor for crashes:
- Add logging and alerting for repeated crashes of processes linked against libxslt. A sudden increase in segfaults or aborts in transformation workers is a strong indicator of exploitation attempts.
- Correlate logs with network activity and file uploads to find the malicious payloads.
- Consider temporarily removing or replacing libxslt:
- If libxslt is not essential, remove or replace it with a safer, sandboxed transformation pipeline until patches are applied.
These steps prioritize safety: installing official patches is the only true remediation, but containment and compensations can prevent immediate exploitation.
Detection and incident response guidance
- Hunt for crashes: Look for core dumps, repeated process restarts, or OOM-style crashes in services that perform transformations. The crash signature will often be an abort, segmentation fault, or other crash report originating from the libxslt-linked process.
- File-based detection: Preserve suspicious XSL/XML samples that caused crashes for offline analysis. If you can reproduce the crash in a non-production sandbox, capture stack traces and libc backtraces for triage.
- Use tooling: Intrusion detection systems and EDR solutions that monitor abnormal process terminations and unusual file upload patterns can help detect exploitation attempts before broad impact.
- Containment steps: If a production service is repeatedly crashed, stop the service, apply the patch, rotate any credentials that may have been exposed by other means, and restore from a safe state. Reboot or service restart alone does not eliminate the underlying vulnerability.
Why this matters: risk analysis and practical impact
- Breadth of use: libxslt is a foundational piece of XML tooling and remains widely deployed in server-side utilities, document transformation services, and developer tools. A vulnerability that allows consistent crashing of those processes can be weaponized by attackers as a high-impact availability attack against web applications or services that process user-submitted XML/XSL.
- Exploit complexity: Multiple trackers rate the attack complexity as low and require little to no privileges beyond the ability to supply crafted input; this lowers the bar for attackers, especially where untrusted uploads are accepted without careful validation.
- Distinction between harvest and harm: Unlike heap-corruption bugs that sometimes lead to code execution, CVE-2025-10911 has been assessed primarily as a DoS vector in distribution advisories. While code execution cannot be completely ruled out in all contexts, current advisories and CVSS impact breakdowns emphasize availability loss as the principal risk. Administrators should therefore prioritize service continuity measures in addition to patching.
Practical checklist for WindowsForum readers (system administrators and dev teams)
- Update:
- Check your distribution security page or package manager for patched libxslt packages and apply them in a tested maintenance window.
- Inventory:
- List every service that may call into libxslt (web apps, document servers, mail handlers, CI artifacts). Document whether they accept untrusted XML/XSL input.
- Isolate:
- Run XSLT processors in containers or dedicated hosts. Use resource limits and restart policies that prevent total platform instability from repeated crashes.
- Harden:
- Apply file type validation and user quotas on uploads. Remove any transformation features not critical to business logic.
- Monitor:
- Configure alerts for repeated process crashes, core dumps, or service restarts. Keep saved copies of the offending files for forensic triage.
- Communicate:
- Inform development teams that rely on XSLT transforms to test their workflows after upgrades — library ABI changes or security hardening can affect custom transformation code.
Known unknowns and things to watch
- Exploit code: At the time of disclosure there was no widely reported public proof-of-concept exploit in the wild, and EPSS/Exploitability scores remain low. That said, lack of public PoC does not imply safety; tools for crafting malicious XSL payloads are accessible enough for motivated attackers to develop private proofs.
- Variability in CVSS and attack-vector reporting: Different vendors’ advisories place the attack vector as local or treat certain hosted scenarios as remote. The secure stance is to treat any service that accepts XSL/XML from untrusted parties as exposed — whether the CVSS vector lists AV:L or AV:N depends on deployment, not on the bug itself.
- Upstream merges and backports: Some distributions may choose to backport a targeted fix into older stable packages, whereas others will only publish fixes for current releases. Confirm the exact patched package version that applies to your OS release channel before rolling out updates.
Final analysis: strengths, weaknesses, and recommended posture
- Strengths of the patch response:
- Rapid identification and cross-vendor collaboration helped get patches into multiple distributions relatively quickly.
- Vendor advisories emphasize availability impact clearly, which helps administrators triage remediation priorities accurately.
- Weaknesses and risks:
- The bug surfaces in a complex lifecycle area (RVTs and key metadata), meaning there is a non-zero chance of similar regressions unless upstream changes include careful unit tests and sanitizers.
- Variation in how vendors score exploitability and in which release channels are patched can create an inconsistent security posture across heterogeneous fleets.
- Because many applications rely on system libraries, patching libxslt without coordinating application-side testing can cause breaking changes in edge cases; however, this risk is outweighed by the imperative to prevent service-disrupting crashes.
- Recommended security posture:
- Apply vendor patches promptly after testing.
- Harden input surfaces and isolate transformation services.
- Add operational detection for crash patterns and suspicious file uploads.
- Treat libraries that handle untrusted input as first-class attack surfaces; maintain a documented upgrade and rollback plan for such components.
CVE-2025-10911 is a textbook example of how subtle lifecycle bugs in memory-managed C libraries translate into real-world availability risks for modern services. The path forward is straightforward — remediate with vendor patches, reduce attack surface by limiting untrusted XSL/XSLT processing, and harden transformation services with sandboxing and monitoring so that a single crashed worker does not become a full-system outage.
Source: MSRC
Security Update Guide - Microsoft Security Response Center