CVE-2026-86139 is a medium severity integer overflow in libxml2 before 2.15.4. The function xmlURIEscapeStr in uri.c mishandles strings longer than INT_MAX, where the length helper returns zero and an output counter later wraps. Upgrade to 2.15.4 or a distribution backport.
What's affected
Affected: libxml2 before 2.15.4. The flaw is in xmlURIEscapeStr in uri.c, the function that percent-escapes URI text.
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 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 commit message links this to an earlier fix. An earlier change handled the case in xmlBuildRelativeURISafe where xmlStrlen returns 0 for strings longer than INT_MAX. xmlURIEscapeStr had the same pattern and was missed. With a zero length, the function sized its work as 0 plus 20, and the write loop eventually overflowed because the output counter wrapped as an int.
The weakness is CWE-190. The fix is small: return NULL when xmlStrlen returns 0 for a non-empty string. The exposure condition is a string of more than two gigabytes reaching the function, so practical risk depends on whether your application lets untrusted data of that size into URI handling. Many do not, but some batch processors and document pipelines do.
Treat this as a hygiene upgrade bundled with the rest of the 2.15.4 fixes rather than a stop everything event, unless your service accepts very large attacker supplied strings.
Quick check
Can a normal sized URI trigger this?
The commit describes strings longer than INT_MAX, so ordinary URIs are not the trigger. Exposure depends on whether untrusted data of that size can arrive.
Why patch if the input must be huge?
Because the fix ships together with other libxml2 2.15.4 corrections, and a patched library removes the question entirely.
Sources
Last reviewed: 18 October 2026.
