CVE-2026-41080

What it actually does

libexpat versions before 2.8.0 use insufficient entropy in internal hashing, allowing an attacker to create XML input that causes hash-collision behavior. When a vulnerable parser processes a crafted XML document, operations that should be efficient can become disproportionately expensive, consuming CPU and slowing or blocking XML parsing. The primary impact is availability degradation rather than confidentiality or integrity compromise.

Why it matters to the business

Systems, applications, or services that parse untrusted XML with vulnerable libexpat versions may experience slowdowns, request timeouts, worker exhaustion, or localized denial of service. The overall severity is low, EPSS is low and stable, there is no known KEV listing, and no public exploit maturity is reported, but libexpat is commonly embedded in downstream software, so exposure may exist indirectly through bundled dependencies.

How an attack unfolds

An attacker first identifies a workflow that causes vulnerable libexpat code to parse attacker-controlled XML, such as an import feature, document-processing path, API endpoint, message processor, or local XML-handling utility. The attacker then supplies a specially crafted XML document designed to trigger hash-collision-heavy behavior inside the parser. If the XML reaches a vulnerable libexpat version before 2.8.0, parsing can consume excessive CPU relative to the input size, delaying processing and potentially tying up application workers or batch jobs. Successful exploitation results in degraded availability rather than code execution or data disclosure.

How to fix it

Upgrade libexpat to version 2.8.0 or later wherever it is installed directly or bundled inside software. Because libexpat is often included transitively, update operating system packages, container base images, language-runtime packages, embedded third-party products, and statically linked applications that include libexpat. If immediate upgrade is not possible, reduce risk by rejecting untrusted XML where feasible, enforcing XML size and complexity limits, limiting parsing time, isolating XML-processing workers, applying request rate limits, and monitoring for abnormal CPU consumption during XML parsing.

How to confirm the fix worked

Confirm that all installed or bundled libexpat instances report version 2.8.0 or later. Check package managers, container images, software bills of materials, application build manifests, and statically linked binaries where applicable. Validate that applications processing XML still function after upgrade and that XML size, parsing-time, and request-rate limits are enforced. For exposure testing, submit benign large or complex XML test cases in a controlled environment and verify that processing remains bounded and does not cause sustained CPU exhaustion or worker starvation.

Typical attack path

1. Find an application, service, job, or tool that parses XML using libexpat before 2.8.0.
2. Determine whether attacker-controlled XML can reach that parsing path, either remotely through an application feature or locally through a processing pipeline.
3. Generate or submit a crafted XML document intended to create excessive hash collisions during parsing.
4. Cause the parser to spend abnormal CPU time processing the document.
5. Repeat or parallelize submissions to increase resource exhaustion and trigger service degradation or processing delays.

How to detect it

There are no reliable public exploit-specific indicators for this issue. Detection should focus on behavioral evidence around XML parsing: sustained CPU spikes in processes that handle XML, increased request latency or timeouts on XML ingestion endpoints, repeated submissions of unusually large or complex XML documents, worker pool exhaustion, and application logs showing XML parsing failures or long parse durations. Useful log sources include web and API access logs, application logs, XML-processing job logs, container and host CPU telemetry, process accounting, EDR process telemetry, and load balancer timeout logs. Investigate clusters of requests or files that immediately precede CPU saturation in XML-handling processes, especially repeated uploads or posts from a small number of sources. Since this is a denial-of-service condition, absence of persistent malware artifacts does not rule out attempted exploitation.

What your security team should do

• Inventory direct and transitive uses of libexpat across servers, containers, appliances, developer images, and packaged applications.
• Prioritize upgrades for internet-facing services, file-ingestion systems, message processors, and any workflow that accepts XML from untrusted users or partners.
• Upgrade all vulnerable libexpat instances to 2.8.0 or later, including bundled and statically linked copies.
• Add or verify defensive limits on XML document size, element and attribute counts, parsing duration, request rate, and worker concurrency.
• Monitor XML-processing services for spikes in CPU utilization, request latency, parse failures, and repeated submissions from the same source.
• Because exploitation intelligence is currently low and stable, handle through normal vulnerability remediation SLAs unless the vulnerable parser is exposed to untrusted XML at scale.