CVE-2026-113351 in libexpat
Summary
by MITRE • 10/20/2026
libexpat 2.7.2 through 2.9.0 contains a denial of service vulnerability because XML_ParserReset zeroes the direct byte count but never offsets tracked heap allocations. Attackers can submit a large XML document so later documents on the same reset parser fail with XML_ERROR_NO_MEMORY until it is recreated.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/20/2026
The libexpat library, specifically versions ranging from 2.7.2 through 2.9.0, contains a critical memory management flaw that leads to denial of service conditions during repeated parsing operations on the same parser instance. This vulnerability stems from an implementation error in how the XML_ParserReset function handles internal state tracking for heap-allocated buffers used during XML processing. When a parser is reset via this function, it correctly zeroes out metrics related to direct byte counts but fails to properly adjust or release references to previously tracked heap allocations. Consequently, the library retains stale pointers and incorrect memory accounting data that do not reflect the actual current usage of resources after the reset operation completes.
This technical flaw manifests when an attacker submits a large XML document followed by subsequent smaller documents on the same parser instance without recreating it. The initial parsing of the large document causes libexpat to allocate significant heap memory for buffer expansion and internal data structures. Upon invoking XML_ParserReset, while some counters are reset, the underlying tracking mechanism for allocated blocks remains inconsistent with reality. As a result, subsequent parsing operations encounter false positive out-of-memory errors because the library believes it has exhausted its available memory based on corrupted accounting data rather than actual physical constraints. This results in the parser returning an XML_ERROR_NO_MEMORY status code even when sufficient system resources are available to process the new input.
From a security perspective, this vulnerability is classified under CWE-401, which describes missing release of memory after effective lifetime, and more specifically aligns with improper resource management leading to denial of service scenarios. In terms of attack vectors, this flaw can be exploited in environments where XML parsers are reused for performance optimization, such as high-throughput web services or API gateways that process multiple sequential requests using a single parser instance. An attacker does not need complex exploitation techniques; they simply need to trigger the reset cycle after processing large payloads repeatedly. This aligns with MITRE ATT&CK technique T1496, Resource Hijacking, where an adversary consumes resources to degrade service availability for legitimate users.
The operational impact of this vulnerability is primarily a denial of service against applications relying on libexpat for XML parsing. Services that utilize persistent parser objects may experience intermittent failures after processing large inputs followed by resets, leading to dropped requests and potential cascading failures in dependent systems. While the issue does not directly allow remote code execution or arbitrary memory read/write operations due to the nature of the accounting error rather than a buffer overflow, it effectively renders the parsing functionality unusable for subsequent tasks until the parser object is destroyed and recreated. This degradation can be triggered remotely if the application exposes XML processing capabilities over network interfaces without adequate input size limits or proper state isolation between requests.
Mitigation strategies should focus on both immediate patching and architectural adjustments to prevent recurrence in legacy systems. The most effective remediation is upgrading libexpat to version 2.9.1 or later, where this memory accounting logic has been corrected to properly handle heap allocation tracking during parser resets. For applications that cannot immediately upgrade the library dependency, developers should modify their codebase to avoid reusing XML_Parser instances across requests involving large payloads. Instead of calling XML_ParserReset after processing a document, it is safer to destroy the current parser using XML_ParserFree and allocate a fresh instance for each new parsing task. This approach ensures that all internal state and memory allocations are completely cleared without relying on the potentially flawed reset mechanism. Additionally implementing strict input size limits before passing data to the parser can reduce the likelihood of triggering the condition, although this is only a partial mitigation as even moderately sized documents could eventually exhaust the corrupted accounting if repeated sufficiently.