CVE-2026-86142

What it actually does

A heap-based buffer overflow in libxml2 before 2.15.4 occurs in xmlXPtrEvalXPtrPart when xmlXPtrEval saturates the computed XPointer length. A crafted XPointer expression can corrupt adjacent heap memory in the parsing process, which may allow arbitrary code execution, integrity violation of in-process data, limited information disclosure, or a process crash. The CVSS vector (AV:L/AC:H/PR:N/UI:N) indicates a local, high-complexity condition with no privileges or user interaction required, and high impact to confidentiality and integrity with low availability impact.

Why it matters to the business

Any product that evaluates untrusted or attacker-influenced XML XPointer expressions through libxml2 can suffer memory corruption in a core XML stack. On Red Hat, this includes standalone libxml2 packages and cert-manager images that pull in the library, so certificate issuance, rotation, and mesh identity workloads can be disrupted or subverted if a local actor reaches an XML processing path. The issue is not listed in CISA KEV, is not associated with ransomware, and has no reported in-the-wild exploitation about 31 days after publication, which lowers immediate mass-exploitation urgency relative to remotely wormable bugs. Residual risk remains material because libxml2 is a foundational dependency and cert-manager sits on the Kubernetes trust path for TLS.

How an attack unfolds

An attacker who already has local code execution or another local input channel to a process linked against vulnerable libxml2 supplies a malicious XPointer expression. During evaluation, xmlXPtrEval saturates the XPointer length, xmlXPtrEvalXPtrPart writes past a heap buffer, and the resulting corruption is leveraged for in-process control of confidentiality and integrity (and possibly a crash). Attack complexity is high: the attacker must reach an XPointer evaluation path, win heap layout, and convert the overflow without a known public exploit. No named threat actors, KEV activity, or exploit-maturity signals are associated with this CVE.

How to fix it

Upgrade to vendor-fixed builds and restart consuming services so the patched libxml2 is loaded. Red Hat: apply RHSA-2026:72470. libxml2 on RHEL 10: 2.12.5-10.el10_2.4; libxml2 on RHEL 9: 2.9.13-14.el9_8.5; libxml2-main: 2.15.4-0.1.hum1 (upstream fixed in libxml2 2.15.4). cert-manager (Red Hat): operator-rhel9:1790589855; cert-manager-istio: csr-rhel9:1790589914; jetstack-cert: manager-rhel9:1790589912. Prefer replacing the shared library rather than application-level XML filters as the primary fix. If immediate patching is delayed, restrict local untrusted XML/XPointer evaluation, drop unnecessary XML features in applications that can disable XPointer, and limit which local users and workloads can feed XML into privileged parsers. Rebuild and redeploy images that statically vendor libxml2.

How to confirm the fix worked

Inventory hosts and images for libxml2 older than 2.15.4 (or the RHSA package NVRs above) and for cert-manager images predating the listed operator/csr/manager digests. Confirm rpm -q libxml2 (or equivalent image SBOM/layer inspection) shows the fixed NVR, then restart processes and verify ldd/maps no longer reference the old .so. Regression-test XML and XPointer-using features after upgrade. Do not use proof-of-concept overflow payloads to validate; treat presence of the unfixed library as exposure.

Typical attack path

1. Obtain local access to a host or container whose processes load vulnerable libxml2 (including Red Hat libxml2 and cert-manager images).
2. Locate an application path that evaluates XPointer expressions on attacker-influenced XML (APIs, config, documents, or sidecar tooling).
3. Submit a crafted XPointer that triggers length saturation in xmlXPtrEval.
4. Cause xmlXPtrEvalXPtrPart to overflow a heap buffer and corrupt adjacent allocator metadata or objects.
5. Use the memory corruption to read or alter process memory, attempt code execution in the XML-consuming process, or crash the service.

How to detect it

There is no public exploit, named actor, or KEV ransomware use, so look for crash and library-load evidence rather than a known payload. Review core dumps, systemd-coredump, container runtime OOM/exit logs, and language runtimes (Python/Ruby/PHP/Java native frames) for fatal signals (SIGSEGV/SIGABRT) in libxml2 with frames in xmlXPtrEval or xmlXPtrEvalXPtrPart. Search application and audit logs around XML parse failures, XPointer evaluation errors, and unexpected cert-manager or libxml2-linked process restarts. On hosts, confirm whether the running process still maps an unfixed libxml2 via /proc/<pid>/maps. Network IOCs are not expected because the vector is local. Absence of crashes does not prove non-exploitation of a silent heap overwrite; pair detection with inventory of unfixed packages.

• xmlXPtrEvalXPtrPart
• xmlXPtrEval
• libxml2.so
• xpointer(
• SIGSEGV in libxml2
• SIGABRT in libxml2
• cert-manager
• RHSA-2026:72470

What your security team should do

• Patch Red Hat libxml2 and cert-manager images to the RHSA-2026:72470 versions listed above and roll the fleet, prioritizing clusters where cert-manager handles production TLS.
• Identify statically linked or container-vendored libxml2 copies (language bindings, operator images, mesh sidecars) and rebuild those artifacts rather than only patching the host RPM.
• Until patched, reduce local untrusted XML/XPointer intake and isolate parsers from high-value secrets and cluster credentials.
• Track this CVE as medium-high library risk (CVSS 6.9, local/high complexity, no KEV/ransomware/known exploit); do not deprioritize solely because EPSS/KEV are quiet—cert-manager sits on the cluster identity path.
• After rollout, verify running processes loaded the new library and watch for XML-parser crashes during the transition window.