CVE-2026-86144

What it actually does

In libxml2 before 2.15.4, xmlXIncludeProcess and xmlXIncludeProcessTree fail to propagate parseFlags (notably XML_PARSE_NONET) into XInclude processing. Network-disable and other parser restrictions the caller applied to the parent document therefore do not bind to included resources. A custom resource loader can then perform unexpected network fetches during XInclude resolution, enabling XML external entity injection, server-side request forgery against attacker-chosen URLs, or denial of service from a slow or unbounded remote include. Impact is confidentiality, integrity, and availability at low severity with changed scope (CVSS 5.6, AV:L/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:L).

Why it matters to the business

Organizations running Red Hat libxml2 or cert-manager stacks that parse XML with XInclude can face limited data leakage, internal-network probing, or service slowdowns if untrusted or attacker-influenced XML is processed. The issue is 31 days old, is not in CISA KEV, has no known exploit maturity, and requires local access plus high attack complexity, so mass opportunistic compromise is unlikely. Residual risk is highest where cert-manager or other libxml2 consumers sit on Kubernetes control planes or process XML from less-trusted sources, because even a local, constrained bypass of XML_PARSE_NONET can reach internal APIs or stall certificate/issuance workflows. Apply RHSA-2026:72470 on a normal-to-elevated patch cycle rather than emergency KEV timelines.

How an attack unfolds

An attacker who can place or influence XML that a vulnerable libxml2 consumer processes with XInclude (for example via a local file, config, or pipeline that eventually calls xmlXIncludeProcess or xmlXIncludeProcessTree) relies on parseFlags not being copied onto the include path. If the application intended XML_PARSE_NONET or equivalent isolation, that intent is not enforced for included documents. A custom loader then retrieves the href over the network, which can pull attacker-controlled content (XXE-style disclosure), hit internal HTTP/HTTPS endpoints (SSRF), or stall on a deliberately slow remote resource (DoS). No named threat actors or ransomware campaigns are associated; exploitation is situational and depends on a local XML supply path plus a loader that performs network I/O when flags are missing.

How to fix it

Upgrade libxml2 to 2.15.4 or later (upstream). On Red Hat, apply RHSA-2026:72470: libxml2 el8 2.9.7-21.el8_10.9; libxml2 el9 2.9.13-14.el9_8.5; libxml2 el10 2.12.5-10.el10_2.4; libxml2-main 2.15.4-0.1.hum1; cert-manager/cert-manager operator-rhel9:1790589855; cert-manager/cert-manager-istio csr-rhel9:1790589914; cert-manager/jetstack-cert manager-rhel9:1790589912. Until patched, avoid XInclude on untrusted XML, do not register network-capable custom loaders for XInclude, and restrict egress from XML-processing hosts so failed NONET enforcement cannot reach the internet or sensitive internal endpoints.

How to confirm the fix worked

Confirm installed packages meet the RHSA-2026:72470 NEVRAs or that libxml2 reports 2.15.4+. Re-scan images and hosts for older libxml2/cert-manager builds. In application tests, process a benign XInclude with XML_PARSE_NONET set and verify no network fetch occurs (packet capture or an instrumented loader). Inventory callers of xmlXIncludeProcess and xmlXIncludeProcessTree and confirm they no longer depend on flags that were silently dropped.

Typical attack path

1. Gain a local or otherwise in-process ability to supply XML that a libxml2-based component will process with XInclude (xmlXIncludeProcess or xmlXIncludeProcessTree).
2. Ensure the victim path uses a custom resource loader and that the caller’s parseFlags—especially XML_PARSE_NONET—are the only intended network/entity controls.
3. Cause XInclude resolution so flags are not propagated and the loader fetches a remote or attacker-chosen resource.
4. Use the unconstrained fetch for limited file/entity disclosure, SSRF against reachable internal URLs, or a slow-resource hang that degrades the XML-processing service.
5. Observe leaked content, internal responses, or service impact; no privilege escalation beyond the parser process is implied by this flaw alone.

How to detect it

There is no public exploit activity, KEV listing, or named actor tradecraft for this issue. Hunt for unexpected outbound HTTP/HTTPS or DNS from processes that parse XML (libxml2, cert-manager controllers/operators) around the time untrusted XML or XInclude was processed. Review application and container logs for XInclude resolution, custom loader errors, long-running include fetches, or sudden parser hangs. On hosts, inspect XML inputs and configs for xi:include / XInclude namespaces that point at http(s) URLs. Correlate with egress firewall or service-mesh logs showing parser identities contacting unusual destinations. Absence of these artifacts does not prove non-exploitation; it only indicates no noisy network side effects were recorded.

• xi:include
• xmlns:xi="http://www.w3.org/2001/XInclude"
• xmlXIncludeProcess
• xmlXIncludeProcessTree
• XInclude
• libxml2
• cert-manager

What your security team should do

• Patch Red Hat libxml2 and cert-manager packages in RHSA-2026:72470 on all el8/el9/el10 and operator images; treat as a scheduled high-priority library update, not a KEV emergency.
• Inventory binaries and containers linking libxml2 that enable XInclude or custom resource loaders, especially cert-manager on Kubernetes.
• Block or tightly allowlist egress from XML-parsing workloads until upgrades complete.
• Disable XInclude or reject untrusted XML in any remaining unpatched consumers.
• After patching, verify package versions and that XML_PARSE_NONET is honored for includes; add regression tests around XInclude plus NONET.