CVE-2026-0989: libxml2 RelaxNG Parser DoS Vulnerability

CVE-2026-0989 Overview

A flaw was identified in the RelaxNG parser of libxml2 related to how external schema inclusions are handled. The parser does not enforce a limit on inclusion depth when resolving nested <include> directives. Specially crafted or overly complex schemas can cause excessive recursion during parsing. This may lead to stack exhaustion and application crashes, creating a denial-of-service risk.

Critical Impact

Uncontrolled recursion in the libxml2 RelaxNG parser can lead to stack exhaustion and application crashes when processing maliciously crafted XML schemas with deeply nested include directives.

Affected Products

• libxml2 (versions with RelaxNG parser support)

Discovery Timeline

• 2026-01-15 - CVE CVE-2026-0989 published to NVD
• 2026-01-16 - Last updated in NVD database

Technical Details for CVE-2026-0989

Vulnerability Analysis

This vulnerability (CWE-674: Uncontrolled Recursion) exists in the RelaxNG schema validation component of libxml2. The root issue stems from the parser's handling of external schema inclusions through <include> directives. When the RelaxNG parser encounters an <include> element, it recursively processes the referenced schema file. However, there is no mechanism to limit or track the depth of these recursive inclusions.

An attacker can exploit this by crafting a RelaxNG schema file that contains nested include directives, either through circular references (schema A includes schema B which includes schema A) or through deeply nested chains of schema files. When the parser attempts to resolve these inclusions, it will continue recursing until the call stack is exhausted.

The attack can be carried out over the network against any application that processes user-supplied RelaxNG schemas or validates XML documents against untrusted schemas. The impact is limited to denial of service through application crashes, with no direct path to code execution or data compromise.

Root Cause

The RelaxNG parser implementation in libxml2 lacks a recursion depth counter or cycle detection mechanism when processing <include> directives. This allows schema files to reference other schemas indefinitely without any bounds checking, ultimately consuming all available stack space and causing the application to crash with a stack overflow exception.

Attack Vector

The vulnerability can be exploited remotely by providing a maliciously crafted RelaxNG schema to an application that uses libxml2 for XML validation. The attacker would need to supply a schema file (or set of schema files) containing recursive or deeply nested include directives. When the target application attempts to parse or validate against these schemas, the uncontrolled recursion occurs. While the attack complexity is considered high due to the specific conditions required, no authentication or user interaction is needed to trigger the vulnerability.

The vulnerability mechanism can be understood through the following scenario: a RelaxNG schema file references an external schema via an <include> directive, which in turn includes another schema, creating either a circular reference loop or an excessively deep chain of inclusions. The parser follows each include without maintaining a depth counter, eventually exhausting the call stack. For detailed technical analysis, refer to the Red Hat CVE-2026-0989 Advisory and Red Hat Bug Report #2429933.

Detection Methods for CVE-2026-0989

Indicators of Compromise

• Application crashes or unexpected terminations during XML schema validation operations
• Stack overflow errors in logs associated with libxml2 or RelaxNG parsing functions
• Abnormally high CPU utilization during XML processing followed by sudden process termination
• Repeated segmentation faults in applications using libxml2 for schema validation

Detection Strategies

• Monitor application logs for stack overflow exceptions or segmentation faults related to XML parsing routines
• Implement application-level monitoring for unusually long processing times during schema validation
• Deploy SentinelOne Singularity Platform to detect and respond to process crashes and anomalous behavior patterns
• Review incoming XML schemas for suspicious include directive patterns before processing

Monitoring Recommendations

• Enable verbose logging for XML parsing operations to capture details about include directive resolution
• Set up alerts for repeated application crashes in services that process XML with RelaxNG validation
• Monitor resource consumption (stack memory, CPU) during XML validation operations
• Implement watchdog processes to detect and recover from parser hangs or crashes

How to Mitigate CVE-2026-0989

Immediate Actions Required

• Audit applications using libxml2 to identify those that process untrusted RelaxNG schemas
• Implement schema validation in sandboxed environments with resource limits to contain potential crashes
• Consider disabling RelaxNG schema support if not required by your application
• Apply vendor patches as they become available from your operating system or libxml2 distribution

Patch Information

No official patch information is available at this time. Organizations should monitor the Red Hat CVE-2026-0989 Advisory for updates on patch availability. Subscribe to security mailing lists from your Linux distribution vendor for notification when patches are released.

Workarounds

• Restrict the source of RelaxNG schemas to trusted, pre-validated schema files only
• Implement process-level resource limits using ulimit or container cgroups to restrict stack size and prevent runaway recursion
• Run XML validation processes in isolated sandboxes with automatic restart capabilities
• Consider using alternative XML validation libraries or disabling external schema references where possible

# Configuration example - Set stack size limits for processes using libxml2
# Add to application startup script or systemd service file

# Limit stack size to 8MB to prevent runaway recursion from consuming all memory
ulimit -s 8192

# For systemd services, add to the [Service] section:
# LimitSTACK=8388608

# For containerized applications, set resource limits in your container configuration
# Example Docker run command with stack limit:
# docker run --ulimit stack=8388608:8388608 your-xml-processing-app