CVE-2026-86139

What it actually does

An integer overflow in libxml2's xmlURIEscapeStr (uri.c) can cause an undersized allocation when escaping a URI string, leading to memory corruption (typically an out-of-bounds write) in processes that use the library to handle URIs. Impact is local, high complexity, and can affect confidentiality and integrity of the hosting process, with a lesser availability impact (crash).

Why it matters to the business

Any Red Hat-based system or application that links libxml2 and processes URIs or XML-related input can crash or, in a worst case, allow a local attacker to run code in that process. This is not listed in CISA KEV, is not associated with ransomware, and has no known public exploit about a month after disclosure, so mass-exploitation risk is currently low—but unpatched libxml2 remains a shared library risk across many packages. Upgrade via the vendor advisory to remove the defect.

How an attack unfolds

A local attacker who can influence a URI string processed by a vulnerable libxml2 (for example through a file, IPC, or an application that accepts local URI input) triggers the overflow in xmlURIEscapeStr. High attack complexity means the attacker must hit a narrow allocation/escaping condition. Successful corruption can crash the process or, if they also control nearby memory layout, overwrite adjacent data or function pointers in that process. There are no named threat actors, KEV listings, or mature public exploits for this issue at this time.

How to fix it

Patch libxml2 to a fixed build. For Red Hat libxml2-main, upgrade to 2.15.4-0.1.hum1 (RHSA-2026:64463) or later 2.15.4+. Rebuild or restart services and applications that statically or dynamically link libxml2 after the library update. If immediate patching is not possible, restrict local untrusted input to URI-handling tools and avoid exposing libxml2-based parsers to untrusted local users; this is mitigation only, not a fix.

How to confirm the fix worked

Confirm the installed libxml2 package is 2.15.4-0.1.hum1 or newer (for example rpm -q libxml2 and compare to RHSA-2026:64463). Inventory binaries and containers that vendor or bundle libxml2 and ensure they picked up the patched shared object (ldd / readelf). After upgrade, restart long-lived daemons so they unload the old library. Do not use proof-of-concept overflow inputs to validate; rely on package version, changelog, and vendor advisory mapping.

Typical attack path

1. Gain local ability to supply or influence a URI string consumed by an application linked to vulnerable libxml2
2. Cause that application to call xmlURIEscapeStr on the attacker-influenced string
3. Trigger the integer overflow so the escape buffer is too small
4. Corrupt process memory (crash or, with additional local control, hijack the process)
5. Abuse the compromised process only within its existing privileges

How to detect it

There is no known in-the-wild exploitation, so look for suspicious local crashes rather than a distinctive campaign. Review coredumps, ABRT/systemd-coredump, audit, and syslog/journal for processes aborting in libxml2 with frames in xmlURIEscapeStr or uri.c during URI handling. Correlate with local users or jobs that recently fed unusual URI strings into XML/HTTP/tooling that links libxml2. Memory-sanitizer or crash-reporter stacks naming xmlURIEscapeStr after untrusted local input are the main artifact; network IOCs are not expected because the vector is local.

What your security team should do

• Prioritize RHSA-2026:64463 / libxml2 2.15.4-0.1.hum1 on Red Hat systems that process local or untrusted URIs
• Inventory runtime and container images for libxml2 older than 2.15.4 and rebuild those images
• Restart services after the library update so processes load the patched .so
• Treat this as a standard patch cycle item: not KEV, exploit maturity None, no ransomware use reported
• Watch vendor and distro feeds for downstream package rebuilds that still ship the old libxml2