CVE-2026-86143

What it actually does

libxml2 xmlIO (before 2.15.4) fails to reject integer overflow when reconciling xmlBufUse with xmlOutputWriteCallback, so a wrapped/negative length can be passed into write callbacks. Callers that treat that length as a buffer size can then perform out-of-bounds writes or other memory corruption in the process using the library. Confidentiality and integrity impact is high (arbitrary memory write / potential code execution in the victim process); availability impact is lower (crash or partial corruption). Attack vector is local with high complexity and no privileges or user interaction required.

Why it matters to the business

Any product that serializes or writes XML through vulnerable libxml2 can have its process memory corrupted, including Red Hat libxml2 packages and cert-manager images used for Kubernetes certificate issuance and rotation. Compromise of those workloads can expose or alter keys, certificates, and cluster identity, disrupting TLS, admission, and workload identity. libxml2 is a foundational dependency, so blast radius extends beyond a single app. The issue is not in CISA KEV and is not associated with ransomware, but public exploit code exists and the advisory has been out for about a month—treat unpatched local XML-writing services as elevated risk.

How an attack unfolds

An attacker who already has local access to a host or container running a process linked to vulnerable libxml2 drives an XML output/save path so buffer-length accounting in xmlBufUse overflows. The resulting negative length is handed to xmlOutputWriteCallback; the callback then writes with an attacker-influenced size, corrupting heap or adjacent structures. With sufficient control of heap state (high complexity), that corruption can become an arbitrary write or code execution inside the XML-handling process—for example a cert-manager controller—allowing theft or substitution of certificate material. No named threat actors are tied to this CVE; published exploit material raises the chance of opportunistic local abuse rather than a unique remote worm.

How to fix it

Upgrade libxml2 to 2.15.4 or later (or the distro backport). On Red Hat apply RHSA-2026:72470: libxml2 el10 2.12.5-10.el10_2.4; el9 2.9.13-14.el9_8.5; el8 2.9.7-21.el8_10.9; libxml2-main 2.15.4-0.1.hum1. Refresh cert-manager images from the same advisory: cert-manager operator-rhel9:1790589855, cert-manager-istio csr-rhel9:1790589914, jetstack-cert manager-rhel9:1790589912. Rebuild and redeploy any statically linked or vendored libxml2. Until patched, reduce local untrusted code execution on XML-writing hosts and avoid exposing debug/write callback surfaces to untrusted local users.

How to confirm the fix worked

Inventory RPM/DEB/container SBOM for libxml2 < 2.15.4 and the Red Hat NVR/image tags above; confirm running processes map a patched libxml2.so. Verify cert-manager operator/istio/jetstack images match RHSA-2026:72470 tags. After upgrade, exercise XML save/serialize paths (including large documents) and confirm no crashes in xmlIO write callbacks. Re-scan images and nodes until no vulnerable NVRs remain.

Typical attack path

1. Obtain local access to a host or container where a process is linked against vulnerable libxml2 (including cert-manager or other XML-serializing services).
2. Reach a libxml2 output/save path that uses xmlOutputWriteCallback and xmlBufUse length accounting.
3. Cause length accounting to wrap so a negative length reaches the write callback.
4. Trigger memory corruption in the victim process via the callback’s use of that length.
5. Abuse the corrupted process to read or alter secrets, certificates, or application state, then persist or move laterally with stolen identity material.

How to detect it

This is a local memory-corruption bug, not a network worm: look for evidence of past crashes rather than a unique packet. Collect core dumps and journal/dmesg/Kubernetes events for processes linked to libxml2 (cert-manager controller, webhook, cainjector, and other XML writers) around and after 2026-09-05. Search stack traces for xmlBufUse, xmlOutputWriteCallback, xmlOutputBufferWrite, xmlSaveFile, xmlSaveDoc, or xmlSaveTo*. Unexplained segfaults, abort traps, or tight restart loops in those processes, followed by certificate or secret changes, are the primary post-exploitation clues. Compare package NVRs and container tags against RHSA-2026:72470; a still-vulnerable library plus a matching crash is stronger evidence than version alone. No APT-specific tooling is documented for this CVE.

• xmlOutputWriteCallback
• xmlBufUse
• xmlOutputBufferWrite
• xmlSaveFile
• xmlSaveDoc
• xmlSaveToBuffer
• libxml2.so.2
• SIGSEGV
• cert-manager
• cainjector
• RHSA-2026:72470

What your security team should do

• Patch libxml2 and cert-manager to the RHSA-2026:72470 / 2.15.4 versions immediately—public exploit code exists.
• Inventory every host, image, and language binding that ships libxml2, including statically linked binaries.
• Prioritize Kubernetes certificate-management nodes and other high-privilege XML writers for upgrade and restart.
• Restrict local untrusted execution and debug interfaces on those hosts until patched.
• Hunt historical crashes and core dumps for libxml2 write-callback frames; treat unexplained cert-manager restarts as suspicious until triaged.
• Add SBOM/package gates so pre-2.15.4 (or pre-backport) libxml2 cannot re-enter production.