CVE-2026-86143 is a medium severity integer handling flaw in the xmlIO code of libxml2 before 2.15.4. A mismatch between xmlOutputWriteCallback and xmlBufUse can pass negative lengths to write callbacks. Upgrade to 2.15.4, and review any custom output callbacks you have written.
What's affected
Affected: libxml2 before 2.15.4. The flaw is in xmlOutputBufferWrite in xmlIO.c, which hands data to an output write callback.
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 upstream fix, tracked as GitLab work item 1111, adds a check that the number of bytes to write is below INT_MAX before calling the callback. If it is not, the output buffer records an internal error and the write returns minus one. Without that check, a length that overflows an int arrives at the callback as a negative number.
The record's wording is careful: the issue "has security relevance for many types of uses of that length value within a callback". In other words, the impact depends on what your callback does. A callback that passes the length to memcpy or fwrite could be harmed by a negative value, while one that validates its input is not.
The weakness class is CWE-192, integer coercion error. If you embed libxml2 and supply your own write callbacks, review them for sign assumptions in addition to upgrading.
Quick check
Does this affect me if I only call xmllint?
The record frames the risk around write callbacks. Command line use with default output is less likely to be affected, but upgrade anyway.
What should custom callback authors do?
Treat the length argument as untrusted and reject negative values. Upgrade libxml2 so such values do not arrive in the first place.
Sources
- libxml2 fix commit
- libxml2 comparison v2.15.3 to v2.15.4
- libxml2 GitLab work item 1111
- Safeguard Gold entry for CVE-2026-86143
Last reviewed: 18 October 2026.
