CVE-2026-86144 in libxml2
Summary
by MITRE • 09/05/2026
In xinclude in libxml2 before 2.15.4, xmlXIncludeProcess and xmlXIncludeProcessTree do not propagate parseFlags. This has security relevance for, for example, the XML_PARSE_NONET flag, if (without it) a custom resource loader accesses the internet and triggers XML external entity injection, SSRF, or a denial of service (e.g., for an attacker-controlled internet resource that is intentionally slow).
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/05/2026
The vulnerability in libxml2 versions prior to 2.15.4 centers on a critical oversight in how parse flags are handled during the processing of XML documents containing XInclude directives. Specifically, when functions such as xmlXIncludeProcess and xmlXIncludeProcessTree are invoked to resolve include references within an XML document, they fail to propagate the original parsing context's configuration flags to the newly created parser instances used for fetching and parsing external resources. This architectural flaw means that security-critical settings defined by the application developer at the initial parse stage are effectively discarded during the recursive inclusion process, leaving the subsequent resource loading operations with default or unsafe configurations unless explicitly overridden in a manner not guaranteed by this specific code path.
The most significant consequence of this flag propagation failure involves the XML_PARSE_NONET flag, which is designed to restrict network access for parsed documents. When an application relies on this flag to enforce local-only processing and prevent external resource fetching, the lack of propagation allows xmlXIncludeProcess to bypass these restrictions. Consequently, if a custom resource loader is in place or default loaders are used, the library may initiate outbound HTTP requests to fetch included resources from arbitrary URLs provided by the attacker-controlled XML input. This behavior directly undermines security controls intended to isolate processing environments and prevents applications from safely handling untrusted XML data that includes external references.
This technical flaw enables several severe attack vectors, primarily XML External Entity (XXE) injection and Server-Side Request Forgery (SSRF). An attacker can craft a malicious XML document containing an XInclude directive pointing to an internal or sensitive network resource. Because the NONET flag is not enforced during the inclusion process, the server will fetch this external entity, potentially exposing internal data structures, credentials, or other confidential information through error messages or response bodies in XXE scenarios. In SSRF contexts, the vulnerability allows attackers to force the vulnerable application to make requests to arbitrary destinations within its own network perimeter or cloud infrastructure, facilitating reconnaissance of internal services, exploitation of backend APIs that lack authentication for local traffic, or access to metadata endpoints on cloud instances.
Furthermore, the absence of proper flag handling can lead to denial of service conditions through resource exhaustion. Attackers can supply XInclude references pointing to intentionally slow-responding internet resources or large files hosted on unresponsive servers. Since the parsing process continues without strict timeout controls that might have been configured via other flags in the original context, the application threads involved in processing these includes may hang indefinitely waiting for responses. This behavior consumes server memory and CPU cycles, potentially leading to a complete service outage if multiple such requests are processed concurrently, effectively creating a reflection-based denial of service attack against the hosting infrastructure.
To mitigate this vulnerability, organizations must immediately upgrade libxml2 to version 2.15.4 or later, where the developers have corrected the logic to ensure that parse flags, including XML_PARSE_NONET and others related to security constraints, are correctly passed down during XInclude processing. For applications unable to update promptly due to dependency conflicts, implementing a custom resource loader is essential. This loader should explicitly validate all URIs requested by XInclude directives against an allowlist of permitted domains or enforce strict local-only access policies regardless of the library's internal flag state. Additionally, integrating input validation frameworks that detect and reject XML documents containing external entity references before they reach the parsing stage can provide a robust defense-in-depth layer.
From a classification perspective, this issue aligns with CWE-918, which addresses Server-Side Request Forgery (SSRF) flaws where server-side code makes requests to user-supplied URLs without proper validation of access controls or network restrictions. It also relates to CWE-611, Improper Restriction of XML External Entity Reference, as the failure to enforce non-network parsing flags allows external entities to be resolved and processed by the application. In terms of adversary tactics, this vulnerability supports techniques associated with ATT&CK T1504, specifically the use of XInclude for data exfiltration or lateral movement within a network environment by leveraging trusted applications to fetch malicious payloads from attacker-controlled infrastructure.