01 · The Real Story
A library that chokes on poisoned XML only when an app forgets to disable legacy parsing features
RHSA-2026:90309 for RHEL 9 bundles fixes for multiple libxml2 flaws: arbitrary code execution via heap/stack buffer overflows (CVE-2026-86138, CVE-2026-86140, CVE-2026-11979), heap overflow in xmlXPtrEval (CVE-2026-86142), integer overflow in write callbacks (CVE-2026-86143), info disclosure/SSRF (CVE-2026-86144), and use-after-free/DoS (CVE-2026-6653, among others). Affected packages include base libxml2 and python3-libxml2 in RHEL 9 BaseOS and AppStream.
Vendor severity CRITICAL is too high for most deployments. These are real memory-corruption bugs, but they only trigger when an application parses attacker-controlled XML with DTD, XInclude, or XPointer enabled. Red Hat's own mitigation guidance says to disable DTD processing and XInclude; many apps already do. No public exploit or in-the-wild activity is known. However, because libxml2 is a dependency across high-value Linux roles, any app that parses untrusted XML is a potential path to full host compromise, so the aggregate remains a high-priority patch.
"Patch now, but don't panic: RCE in libxml2 needs an XML endpoint with DTD/XInclude turned on."
02 · The Attack Path
5 steps from start to impact.
STEP 01
Reach an XML-consuming service
The attacker must find a RHEL 9 application that parses attacker-supplied XML via libxml2. Examples include SOAP/XML APIs, document converters, config importers, or SAML processors. Direct network exposure of libxml2 does not exist because it is a library, not a service.
Conditions required:
- Network access to an application that accepts XML input
- Application is running on vulnerable RHEL 9 libxml2 package
Where this breaks in practice:
- Most RHEL 9 installs are not directly exposed to the internet
- The vulnerable library is only reachable through a host application that actively parses untrusted XML
- Applications may require authentication or user interaction before parsing
Detection/coverage: Tenable plugin 372134 identifies unpatched libxml2 packages; network scanners do not see the library itself.
STEP 02
Deliver malicious XML with DTD/XInclude/XPointer content
The attacker crafts an XML document that leverages DTD entity expansion, XInclude directives, or XPointer expressions. These features are only processed if the application enables them (e.g., via
XML_PARSE_DTDLOAD, XML_PARSE_XINCLUDE, or direct calls to xmlXIncludeProcess/xmlXPtrEval).Conditions required:
- Application enables DTD processing, external entities, XInclude, or XPointer
- No input sanitization or XML feature restriction
Where this breaks in practice:
- Modern libxml2 defaults and many application configs set
XML_PARSE_NONETor disable DTD for untrusted input - Red Hat advises disabling DTD and XInclude; many vendors already do
- Input validation may reject large or malformed XML before parsing
Detection/coverage: WAF may inspect HTTP XML payloads, but no public signatures exist for these CVEs.
STEP 03
Trigger vulnerable libxml2 code path
The malicious XML reaches a vulnerable function such as
xmlSnprintfElements, xmlXPtrEval, or the xmlcatalog utility. These functions mishandle buffer sizes, leading to heap-based or stack-based buffer overflows. The attacker must tailor the input to the specific libxml2 version and parse flags.Conditions required:
- Vulnerable libxml2 version (before fixed packages)
- Parser reaches the affected function with crafted input
- Adequate input length and structure to trigger the overflow
Where this breaks in practice:
- Memory corruption is not deterministic; ASLR, PIE, stack canaries, and RELRO complicate exploitation
- No public proof-of-concept exists to lower the skill barrier
- The
xmlcatalogutility is a local tool, not remotely reachable in most deployments
Detection/coverage: Crash logs, ASAN instrumentation, or host IDS on application hosts might reveal attempts.
STEP 04
Achieve code execution or denial of service
Successful exploitation can corrupt memory and either crash the process (DoS) or execute attacker-controlled code with the privileges of the XML-processing application. Remote code execution usually requires bypassing modern exploit mitigations and crafting a reliable ROP chain.
Conditions required:
- Exploit succeeds despite ASLR/DEP/canaries
- Attacker can control the overflowed buffer precisely
- Application runs with a useful privilege level
Where this breaks in practice:
- Modern RHEL mitigations significantly raise exploit complexity
- SELinux enforcing can restrict even successful code execution
- No active exploitation or public exploit code has been observed
Detection/coverage: EDR detects anomalous child processes or memory tampering; auditd and SELinux logs may show violations.
STEP 05
Escalate privileges or move laterally
If the compromised application runs as a privileged service account (e.g., root or a domain-joined identity), the attacker may pivot to other hosts or escalate. However, RHEL service hardening often limits this step.
Conditions required:
- Service account has high privileges or weak separation
- Network reachability from the compromised host to other targets
- Additional vulnerabilities for privilege escalation or lateral movement
Where this breaks in practice:
- RHEL services are commonly confined by SELinux and run as non-root
- No direct credential theft from libxml2 itself
- Requires a second-stage exploit to leave the host
Detection/coverage: EDR, network segmentation monitoring, and SIEM correlation detect lateral movement.
03 · Compensating Control
1
HIGH 7.5→IGNORE 0.0
SEVERITY REDUCEDApply RHSA-2026:90309 updates to
libxml2 and python3-libxml2 — This is the remediation. For a HIGH verdict, the noisgate remediation SLA is ≤180 days for fleet rollout, but patch critical hosts first. Residual severity: IGNORE, score 0.0.2
HIGH 7.5→MEDIUM 5.0
SEVERITY REDUCEDDisable DTD processing and XInclude/XPointer in applications that parse untrusted XML — This mitigation removes the trigger condition; apply within 30 days per the noisgate mitigation SLA for HIGH. Residual severity MEDIUM, score 5.0.
3
HIGH 7.5→HIGH 6.5
Enforce SELinux enforcing mode and restrict network egress from XML-processing services — Limits impact if code execution occurs; apply within 30 days. Residual severity HIGH, score 6.5 (still vulnerable but confined).
4
HIGH 7.5→HIGH 7.5
Monitor XML endpoint logs and enable crash telemetry — Detect exploitation attempts; residual severity HIGH, score 7.5 (does not prevent the vulnerability).
What doesn't work
- Blocking port 80/443 does not help; XML payloads travel over allowed HTTPS.
- WAF signature blocking alone; no known signatures exist, and XML can be encoded/obfuscated.
- Disabling external entity resolution (XXE) without disabling DTD/XInclude may not stop all overflow triggers.
04 · Intelligence Metadata
The supporting signals.
| In-the-wild status | No known active exploitation; not in CISA KEV as of 2026-10-25. |
|---|---|
| Public PoC | No public proof-of-concept found. GitHub repos referenced in advisories are upstream libxml2 fixes, not exploits. |
| EPSS | Not listed in FIRST EPSS as of search date; percentile unknown. |
| KEV status | Not in CISA Known Exploited Vulnerabilities. |
| CVSS vector | Vendor severity CRITICAL per Tenable plugin; individual CVEs not individually scored in NVD as of search date. |
| Affected versions | RHEL 9 libxml2 and python3-libxml2 packages prior to RHSA-2026:90309; fixed in 2.9.13-13.el9_6 (BaseOS 9.6) and 2.9.13-14.el9_8.5 (AppStream 9.8). |
| Fixed versions | 2.9.13-13.el9_6 / 2.9.13-14.el9_8.5 (see RHSA-2026:90309). |
| Scanning/exposure | Tenable plugin 372134 detects unpatched packages; GreyNoise shows no direct internet exposure because libxml2 is a library, not a service. |
| Disclosure date | 2026-10-25 (RHSA-2026:90309). |
| Reporting researcher/org | Red Hat Product Security and GNOME libxml2 upstream. |
Sources.
05 · The Call
Final Verdict
↓ DOWNGRADED to HIGH (7.5/10)
Why this verdict
- Attack path friction: the vulnerable functions are reached only when an application parses attacker-supplied XML with DTD/XInclude/XPointer enabled; RHEL's default
libxml2install does not expose a network service. - No exploit activity: no public PoC, no CISA KEV listing, and no in-the-wild reports as of 2026-10-25.
- Role multiplier: libxml2 is a dependency in high-value Linux roles such as XML gateways, document services, and some IdP/SIEM components. If one of those parses untrusted XML, RCE can lead to domain or fleet compromise, so the verdict floor is HIGH.
Why not higher?
Not a direct pre-auth remote bug; it requires an application to choose libxml2 parsing of untrusted XML with dangerous flags enabled. The aggregate advisory mixes lower-severity DoS/SSRF with the RCE flaws, and modern mitigations (ASLR, SELinux) raise exploit complexity.
Why not lower?
Arbitrary code execution in a library used across enterprise Linux loads is too dangerous to ignore; if reached on a high-value host, impact can be severe. The only clean fix is updating libxml2.
06 · Verification
Crowdsourced verification payload.
Run on each RHEL 9 host as root. Save the script, then invoke: sudo bash check_libxml2_CVE-2026-86138.sh. It uses rpm -q --changelog to look for fixed CVE IDs; requires read access to the RPM database.
#!/bin/bash
# Check for RHEL 9 libxml2 RHSA-2026:90309
set -euo pipefail
pkg="libxml2"
if ! rpm -q "$pkg" >/dev/null 2>&1; then
echo "UNKNOWN: $pkg not installed"
exit 0
fi
patched_cves="CVE-2026-6653|CVE-2026-11979|CVE-2026-86138|CVE-2026-86140|CVE-2026-86142|CVE-2026-86143|CVE-2026-86144"
if rpm -q --changelog "$pkg" | grep -Eq "$patched_cves"; then
echo "PATCHED: libxml2 changelog contains RHSA-2026:90309 CVE IDs"
exit 0
else
echo "VULNERABLE: libxml2 changelog does not list RHSA-2026:90309 CVE fixes"
exit 1
fi