CVE-2026-86138

What it actually does

libxml2 versions before 2.15.4 contain an integer overflow in xmlDictAddQString (dict.c). A wrapping length calculation yields an undersized heap allocation for a qualified-name string, and the subsequent copy overflows the buffer. Adjacent heap metadata and objects can be corrupted, enabling confidentiality and integrity compromise of the parsing process (arbitrary read/write or control-flow hijack under favorable layout) and a lesser availability impact (crash). The vector is local with high attack complexity and no privileges or user interaction required.

Why it matters to the business

Any product that parses XML with a vulnerable libxml2—including Red Hat cert-manager, cert-manager-istio, and jetstack-cert—can have its process memory corrupted. Compromise of certificate-management components can undermine TLS issuance, workload identity, and cluster trust. The issue is not in CISA KEV, is not associated with ransomware, and has no known public exploit (~31 days since publication), so urgency is moderate; still treat it as a current-cycle patch because of cert-manager’s role in trust infrastructure.

How an attack unfolds

An attacker who already has local access to a host or container running a libxml2-linked parser supplies XML (or QName data) that reaches xmlDictAddQString. Crafted dictionary keys cause the length arithmetic to overflow, the heap buffer to be allocated too small, and adjacent heap state to be overwritten. High complexity comes from needing a reliable heap layout and a reachable parse path. With no named threat actors, no KEV listing, and exploit maturity of none, observed use in the wild is not established; the realistic outcome ranges from process crash to in-process code execution and subsequent abuse of the host application (for example, minting or stealing certificates).

How to fix it

Upgrade libxml2 to 2.15.4 or later. On Red Hat apply RHSA-2026:72470: libxml2 el10 2.12.5-10.el10_2.4, el8 2.9.7-21.el8_10.9, el9 2.9.13-14.el9_8.5; libxml2-main 2.15.4-0.1.hum1. For cert-manager on RHEL9: 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. Restart XML-parsing services after the package update. Where untrusted XML is not required locally, restrict who can submit parse jobs as a temporary compensating control.

How to confirm the fix worked

Confirm installed versions with the platform package manager (rpm/dnf/yum) against the RHSA-2026:72470 fixed NEVRAs and 2.15.4 for upstream/libxml2-main. For containers, inspect image layers and running pods for the patched cert-manager operator/csr/manager builds. Verify the running process has loaded the new libxml2 (package query, image digest, or mapped shared library path) and that services were restarted. Regression-test normal XML parse and certificate-issuance flows; absence of parser crashes on previously failing large or namespaced documents is a sanity check, not a proof of exploitability.

Typical attack path

1. Obtain local access to a system or container that runs a vulnerable libxml2 consumer (standalone libxml2 or Red Hat cert-manager-family packages).
2. Locate an input path that feeds attacker-influenced XML or qualified names into libxml2 dictionary insertion.
3. Trigger xmlDictAddQString with input that overflows the size calculation and the heap buffer.
4. Turn the resulting heap corruption into in-process integrity or confidentiality compromise (or cause a crash).
5. Abuse the compromised parser process—especially cert-manager—to tamper with certificates, secrets, or further local access.

How to detect it

There is no public exploit, KEV listing, or named actor activity, so look for crash evidence rather than a known campaign. Collect coredumps and fatal-signal logs (journald, audit, container runtime, Kubernetes events) from libxml2-linked processes—especially cert-manager operator, CSR, and related controllers—around XML parse time. In stack traces, xmlDictAddQString / dict.c frames plus heap allocator aborts (double-free, corrupted size, invalid next) are the primary artifacts. Compare process start time and mapped libxml2 build-id against the unpatched versions. Review local file or API inputs that fed XML into those processes. Network IOCs are not expected (local vector).

• xmlDictAddQString
• dict.c
• libxml2.so

What your security team should do

• Patch libxml2 and Red Hat cert-manager-family packages to the RHSA-2026:72470 / 2.15.4 versions in the current maintenance window; prioritize clusters where cert-manager issues identities.
• Inventory all images and hosts for libxml2 < 2.15.4 and for the listed unfixed cert-manager operator, CSR, and manager builds, including statically linked copies.
• Restart or roll workloads after upgrade so processes unload the old library.
• Until patched, limit local users and admission of untrusted XML to cert-manager and other libxml2 parsers.
• Hunt for historical parser crashes (see detection_guidance); there is no KEV or known-exploit pressure, so treat confirmed crashes as investigation items rather than assumed mass exploitation.