CVE-2026-32777

What it actually does

libexpat versions before 2.7.5 can enter an infinite loop while parsing crafted DTD content in XML input. The vulnerability affects availability: a process that uses libexpat to parse attacker-supplied or otherwise untrusted XML may consume CPU indefinitely or become stuck, potentially causing request hangs, worker exhaustion, service degradation, or process supervision restarts. There is no indication from the provided data that the flaw enables code execution, data disclosure, or data modification.

Why it matters to the business

Systems, applications, and products that rely on vulnerable libexpat versions may become slow or unavailable when processing specially crafted XML. The business risk is primarily service disruption, particularly for XML-processing services, document ingestion pipelines, API gateways, SSO/SAML handlers, configuration parsers, or middleware that accepts XML from users or partners. Current public exploitation signals are low: EPSS is 0.00216 with no 30-day increase, it is not listed in CISA KEV, and no mature exploit is reported; however, libexpat is commonly embedded in many products, so exposure may exist indirectly through operating system packages, language runtimes, or bundled third-party software.

How an attack unfolds

An attacker first identifies an application or service path that causes XML data to be parsed by a vulnerable libexpat version. They then submit XML containing malformed or specially constructed DTD content that triggers the parser flaw. When the vulnerable parser processes the DTD, it can enter an infinite loop rather than completing or failing cleanly. Repeated submissions can tie up worker threads or processes, consume CPU, and degrade availability of the application or dependent service. Because this is a denial-of-service issue, successful exploitation is measured by service slowdown, timeouts, stuck parsing processes, watchdog restarts, or resource exhaustion rather than unauthorized access.

How to fix it

Upgrade libexpat to version 2.7.5 or later wherever it is installed or bundled. Because libexpat is frequently embedded, remediation should include operating system packages, container base images, statically linked binaries, language runtime packages, application dependencies, appliances, and vendor-supplied software that include their own libexpat copy. If immediate upgrade is not possible, reduce exposure by rejecting or disabling DTD processing for untrusted XML where application functionality permits, enforcing XML parser timeouts, limiting input size and nesting complexity, applying CPU and request-duration limits, isolating XML parsing workers, and rate-limiting endpoints that process XML. Rebuild and redeploy containers or applications after the dependency update rather than only updating the host package if libexpat is bundled in the artifact.

How to confirm the fix worked

Confirm the installed or bundled libexpat version is 2.7.5 or later. Use package-manager inventory, software composition analysis, container image scanning, and binary inspection to identify both dynamically linked and statically bundled copies. Validate runtime exposure by identifying services that parse XML and determining whether they allow DTD content from untrusted sources. After patching, rerun vulnerability scans and dependency checks, rebuild affected applications or images, and verify that production artifacts no longer include libexpat before 2.7.5. Where DTD processing has been disabled as a mitigation, test expected XML workflows to confirm legitimate use cases still function and crafted DTD input is rejected or times out safely.

Typical attack path

1. Find an application, API, import function, document processor, authentication component, or backend workflow that accepts XML input.
2. Confirm or infer that the XML parsing path uses libexpat before version 2.7.5, either directly or through an embedded dependency.
3. Craft XML containing DTD content designed to trigger the infinite-loop parser condition.
4. Submit the crafted XML to the target parsing path.
5. Observe the target process hang, consume CPU, stop responding, or exhaust available workers.
6. Repeat requests to amplify service degradation or cause partial outage.

How to detect it

To determine whether exploitation may already have occurred, review application, web server, API gateway, and ingestion pipeline logs for repeated XML submissions that include DTD or DOCTYPE content followed by unusually long request durations, 5xx errors, client disconnects, worker timeouts, or service restarts. Correlate timestamps with host telemetry showing sustained CPU consumption by XML-processing services, stuck threads, watchdog restarts, container restarts, or process hangs. For document-processing or file-import workflows, examine uploaded XML files around outage windows for unusual DTD declarations or malformed entity/markup structures. Because the vulnerability manifests as an availability condition and the input pattern is not uniquely defined in the provided data, detection should focus on behavioral evidence: XML parsing operations that never complete, repeated requests to XML-capable endpoints immediately preceding resource exhaustion, and recovery events such as process termination or restart. No named threat actors, ransomware use, or known public exploitation campaigns are provided for this issue.

What your security team should do

• Inventory all uses of libexpat across hosts, containers, appliances, and application dependencies, prioritizing internet-facing and externally supplied XML-processing services.
• Upgrade libexpat to 2.7.5 or later and rebuild any applications or container images that bundle the library.
• Identify XML ingestion paths that allow DTD content and disable DTD processing for untrusted input where feasible.
• Apply request timeouts, parser execution limits, worker isolation, and rate limits to XML-processing endpoints to reduce denial-of-service impact.
• Monitor for abnormal CPU spikes, long-running XML parsing operations, request timeouts, and repeated malformed XML submissions against services that process XML.
• Because EPSS is low, no KEV listing exists, and exploit maturity is reported as none, prioritize remediation based on exposure and service criticality rather than emergency internet-wide exploitation assumptions.