CVE-2026-6653

What it actually does

CVE-2026-6653 is a use-after-free flaw in GNOME libxml2 affecting versions 2.9.11 through 2.11.0. The issue occurs in xmlParseInternalSubset during XML internal subset parsing when malformed entity resolution causes the parser to reference memory after it has been freed. A remote, unauthenticated attacker can trigger the bug by supplying specially crafted XML to an application or service that parses untrusted XML with a vulnerable libxml2 version. The described primary impact is denial of service through parser or process crash; memory-safety behavior also warrants conservative treatment in high-risk parsing contexts, although public exploit maturity is currently reported as none and EPSS is low at 0.00355.

Why it matters to the business

Applications, APIs, document-processing workflows, security tools, message brokers, SSO/SAML handlers, SOAP/XML integrations, and file-ingestion pipelines that rely on vulnerable libxml2 versions may be crashed by malicious XML input. The most likely consequence is service disruption, failed processing jobs, degraded availability, and operational incident response activity. Because libxml2 is widely embedded directly and indirectly in many Linux distributions, language runtimes, libraries, containers, and appliances, exposure may exist through transitive dependencies even when organizations do not explicitly deploy libxml2-facing services. The vulnerability is not currently in CISA KEV, is not known to be used in ransomware campaigns, and has no public exploit maturity reported, so urgency should be driven by whether internet-facing or high-volume XML parsing is present.

How an attack unfolds

An attacker first identifies an application endpoint, file upload path, API integration, XML-based protocol handler, or backend processing workflow that accepts attacker-controlled XML and parses it using libxml2 2.9.11 through 2.11.0. The attacker then crafts XML containing an internal DTD subset and entity structures designed to trigger improper entity resolution behavior in xmlParseInternalSubset. When the vulnerable parser processes the malicious input, it may access memory that has already been freed, causing a crash or abnormal termination of the parsing process. If the parser runs inside a long-lived service process, this can interrupt the service; if it runs inside batch workers, it can repeatedly kill jobs or poison queues. Practical exploitation may require precise XML structure and parser behavior, reflected by the high attack complexity and currently low EPSS score.

How to fix it

Upgrade libxml2 to a vendor-fixed version newer than the affected 2.9.11 through 2.11.0 range, using the patched package provided by the operating system, container base image, appliance vendor, or application distribution. Because no exact fixed package versions were provided in the input, use the relevant vendor advisory as the source of truth and confirm that the installed libxml2 package is not in the affected range. Rebuild and redeploy statically linked applications, containers, language bindings, and third-party products that bundle libxml2 rather than relying only on host package updates. If immediate patching is not possible, reduce exposure by rejecting untrusted XML where feasible, disabling DTD and external/internal entity processing when the application does not require it, enforcing strict XML schema validation, limiting maximum document size and entity expansion depth, isolating XML parsing workers, applying request-rate controls, and ensuring crashed workers restart cleanly without losing message integrity.

How to confirm the fix worked

Inventory systems, containers, appliances, and application dependencies for libxml2 versions 2.9.11 through 2.11.0. Validate remediation by checking package manager output, SBOMs, container image scans, runtime library paths, and statically linked binary dependency reports. On Linux, commands such as `xml2-config --version`, `pkg-config --modversion libxml-2.0`, distribution package queries, and container image scanners can help confirm the deployed version. Verify that applications using XML parsing have been restarted or redeployed after the library update. Where safe, run regression tests with representative XML, DTD, and entity inputs to confirm parsing still works and that malformed XML is rejected without process termination. Confirm mitigations by testing that unneeded DTD/entity processing is disabled and that oversized or deeply nested XML payloads are blocked or constrained.

Typical attack path

1. Identify a reachable application, API, file upload, message queue, or integration that accepts XML or XML-containing documents.
2. Determine or infer that the target processing path uses a vulnerable libxml2 version between 2.9.11 and 2.11.0.
3. Create malformed XML with an internal subset, DTD/entity declarations, or nested entity resolution patterns that exercise xmlParseInternalSubset.
4. Submit the XML through the exposed interface, such as an HTTP request body, uploaded document, SOAP/SAML message, or queued payload.
5. Trigger use-after-free behavior during parsing, causing the parser, worker, or service process to crash.
6. Repeat submissions to sustain denial of service or disrupt downstream XML processing workflows.

How to detect it

Look for evidence of abnormal termination in applications that parse XML, especially crashes correlated with inbound XML requests, uploaded XML-like files, SAML/SOAP messages, API calls with `Content-Type: application/xml` or `text/xml`, or queued XML payloads. Relevant log sources include web access logs, API gateway logs, application logs, worker supervisor logs, container runtime events, systemd/journald, kernel crash logs, coredump records, EDR telemetry, and WAF logs. Search for parser crashes, segmentation faults, aborts, heap-use-after-free diagnostics, or stack traces referencing libxml2 functions such as xmlParseInternalSubset near the time of suspicious XML submissions. Review request bodies or retained samples, where legally and operationally appropriate, for DOCTYPE declarations, internal DTD subsets, ENTITY declarations, unusual entity nesting, repeated malformed XML submissions, or payloads that consistently crash the same service. Because no named threat actors, KEV activity, or public exploit maturity were provided, detection should focus on crash correlation and malformed XML delivery rather than known campaign infrastructure.

• xmlParseInternalSubset
• libxml2.so
• libxml2
• heap-use-after-free
• AddressSanitizer: heap-use-after-free
• Segmentation fault
• SIGSEGV
• SIGABRT
• coredump
• core dumped
• DOCTYPE
• <!DOCTYPE
• <!ENTITY
• Content-Type: application/xml
• Content-Type: text/xml
• application/soap+xml

What your security team should do

• Prioritize patching internet-facing services, APIs, SSO/SAML/SOAP endpoints, file-upload processors, document conversion services, and message-processing workers that parse untrusted XML.
• Inventory libxml2 usage across hosts, containers, base images, embedded products, and statically bundled application dependencies; do not rely solely on operating-system package inventory.
• Upgrade vulnerable libxml2 versions 2.9.11 through 2.11.0 using vendor-fixed packages and rebuild affected containers or statically linked applications.
• If patching is delayed, disable DTD and entity processing wherever business functionality allows, and enforce XML size, depth, and rate limits.
• Monitor for unexplained crashes or restarts in XML-processing services, especially following malformed XML submissions or spikes in 4xx/5xx responses.
• Add negative testing for malformed XML with internal subsets and entity declarations to application security and CI/CD test suites.
• Treat repeated parser crashes from the same source or payload path as an attempted denial-of-service even though the CVE is not currently KEV-listed and exploit maturity is reported as none.