CVE-2026-86144 is a medium severity flaw in libxml2 before 2.15.4. XInclude processing did not propagate parse flags, so restrictions such as XML_PARSE_NONET could be ignored. With a custom resource loader, that can enable server side request forgery or external entity injection. Fixed in 2.15.4.
What's affected
Affected: libxml2 before 2.15.4, specifically applications that use XInclude processing and rely on parse flags to restrict what the parser may load.
Upstream's fixed release is libxml2 2.15.4. The record says "before 2.15.4", and the comparison between v2.15.3 and v2.15.4 spans 39 commits. The record scores this one 5.6, the lowest in the group. The record does not list this CVE in CISA KEV, and I found no statement of exploitation in the pages I reviewed.
How to check if you're exposed
libxml2 reaches you in three ways: as a system package, as a library bundled inside another product, and as a copy statically linked into a language binding.
For the system library and command line tool:
xmllint --version
dpkg -l libxml2 # Debian and Ubuntu
rpm -q libxml2 # RHEL, Fedora, SUSE
For Python's lxml, which can bundle its own libxml2:
python -c "from lxml import etree; print(etree.LIBXML_VERSION)"
Anything reporting a version below 2.15.4 is in range upstream. Linux distributions often backport fixes without changing the version number, so also check your distribution's security tracker for this CVE. Container images and vendored copies need an SBOM or image scan, since the version is not visible from the host.
What to do now
- Inventory where libxml2 runs: host packages, container images, and language packages that bundle it.
- Upgrade to libxml2 2.15.4 or later, or install your distribution package that lists this CVE as fixed.
- Rebuild and redeploy container images and statically linked binaries, since upgrading the host package does not touch them.
- Until patched, avoid feeding untrusted XML, URIs or XPointer expressions of unusual size to services that use libxml2.
- Run a dependency scan to catch copies you did not know about. Safeguard offers a free in-browser dependency scan at gold.safeguard.sh/scan that lists the package versions a project pulls in, which is a quick way to see whether an affected release is in your tree. Reachability analysis can then help you judge whether the vulnerable code path is actually used.
Why it matters
The cause is that xmlXIncludeProcess and xmlXIncludeProcessTree did not pass parseFlags along to the documents they pull in. So a caller who set a restriction, for example the flag that forbids network access, believed it applied to the whole operation. For included content it did not.
The record says this matters "if (without it) a custom resource loader accesses the internet", leading to XML external entity injection, server side request forgery, or a denial of service from a deliberately slow remote resource. The practical condition is therefore specific: XInclude must be on, and a loader must exist that will fetch remote resources.
This is classified as CWE-669, incorrect resource transfer between spheres, where a control that should travel with the data does not. The fix commit adds tests and propagates the flags. Medium at 5.6 reflects those preconditions.
Quick check
What do I check in my own code?
Whether you enable XInclude processing, and whether any custom resource loader can reach the network.
Does the fix change behavior?
Yes, by design: flags you set now apply to included content, so previously permitted loads can be refused.
Sources
Last reviewed: 18 October 2026.
