CVE-2026-86140 is a high severity stack based buffer overflow in libxml2 before 2.15.4. In xmlSnprintfElements (valid.c), two strcat calls write into a buffer without checking the remaining space. Upgrade to libxml2 2.15.4 or a distribution package that carries the fix.
What's affected
Affected: libxml2 before 2.15.4. The vulnerable code is xmlSnprintfElements in valid.c, used when libxml2 formats element content for validation error messages.
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 commit says the earlier CVE-2025-24928 fixed unchecked strcat writes in xmlSnprintfElementContent, but the sibling function xmlSnprintfElements had the identical unfixed pattern. The strcat that adds an opening parenthesis before the loop, and the one that adds a closing parenthesis after it, had no bounds checks. The fix adds remaining space checks before both and returns early with an ellipsis if there is not enough room.
The class is CWE-121, stack based buffer overflow. The record scores it 8.0, the highest of this libxml2 group. The code path is in DTD validation message formatting, so documents that are validated against a DTD are the ones to think about. If your application never validates, the exposure is smaller, though you cannot always see how a library inside another product is configured.
This is where reachability analysis earns its keep. Knowing whether validation is actually used by the code that calls libxml2 tells you whether to patch tonight or this sprint.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Which libxml2 feature is involved?
The code is in valid.c, which handles validation. The commit concerns formatting of element content in validation messages.
Is it related to CVE-2025-24928?
The commit message calls it the sibling of that earlier fix: same pattern, different function.
Sources
Last reviewed: 18 October 2026.
