CVE-2026-45186

What it actually does

This flaw affects libexpat versions before 2.8.1. When parsing XML, libexpat performs attribute-name collision checks whose computational cost can grow disproportionately for specially constructed input. An attacker who can cause an affected application or tool to parse crafted XML can trigger excessive CPU consumption or prolonged parsing, resulting in a denial of service. The vulnerability does not provide code execution, data disclosure, or data modification based on the available information; the impact is availability degradation.

Why it matters to the business

Systems, services, build tools, document processors, APIs, or desktop/server applications that parse untrusted XML through vulnerable libexpat versions may become slow or temporarily unavailable when handling crafted XML. Although the CVSS and EPSS values indicate relatively low urgency and there is no known KEV listing or public exploit maturity reported, libexpat is widely embedded in many products and dependencies, so exposure may exist indirectly through operating system packages, language runtimes, or third-party applications.

How an attack unfolds

An attacker first identifies a workflow where XML content is parsed by software linked against libexpat before 2.8.1. The attacker then submits or places a moderately sized XML document designed to trigger expensive attribute-name collision checking. When the vulnerable parser processes the document, CPU time is spent disproportionately on collision handling rather than normal parsing. Repeated submissions or processing in a resource-constrained service can cause request timeouts, worker exhaustion, degraded throughput, or service interruption. Because the reported attack vector is local and the attack complexity is high, exploitation is most likely where an attacker already has a way to supply XML to a local process, batch job, import feature, CI/build step, or service-side parser.

How to fix it

Upgrade libexpat to version 2.8.1 or later wherever it is used directly or bundled transitively. Apply vendor operating system, container image, language runtime, appliance, and application updates that include the corrected libexpat library. Rebuild statically linked binaries and redeploy containers or packages that include vulnerable libexpat copies. Where immediate upgrade is not possible, reduce risk by limiting XML input size, enforcing request and parsing timeouts, rejecting unusually complex XML documents, isolating XML parsing workloads, applying CPU and memory limits, and rate-limiting XML-processing endpoints or jobs.

How to confirm the fix worked

Confirm that all deployed and bundled libexpat instances report version 2.8.1 or later, including system packages, container layers, statically linked binaries, language runtime dependencies, and vendor-supplied applications. Use software composition analysis, package inventory, container scanning, and binary inspection to locate embedded libexpat copies. Validate that patched applications continue to parse legitimate XML normally and that XML parsing is bounded by configured timeouts and resource limits. Review SBOMs and build artifacts to ensure old libexpat libraries are not still shipped in downstream packages.

Typical attack path

1. Identify an application, service, automation job, or utility that accepts XML input and uses libexpat before 2.8.1.
2. Craft XML with attribute patterns that cause expensive attribute-name collision checks during parsing.
3. Deliver the XML through an accepted input path such as file upload, document import, configuration processing, package metadata, IPC, or local file processing.
4. Trigger parsing of the crafted XML by the vulnerable component.
5. Cause elevated CPU usage, slow parsing, request timeouts, worker starvation, or temporary unavailability.
6. Repeat delivery or combine with concurrency to amplify service degradation.

How to detect it

Look for evidence of denial-of-service activity against XML-processing paths rather than a fixed exploit signature. Useful sources include application access logs, API gateway logs, web server logs, XML import or document-processing logs, job scheduler logs, EDR telemetry, host CPU metrics, container orchestration events, and service timeout/error dashboards. Investigate bursts of XML submissions followed by increased CPU utilization, long request durations, worker restarts, parser timeouts, queue backlogs, or application health-check failures. Correlate suspicious XML-processing events with source IPs, user accounts, upload filenames, job IDs, and process-level CPU spikes. For local workflows, review file creation and execution timelines around XML files processed immediately before service degradation. Absence of a crash or explicit parser error does not rule out exploitation, because the likely symptom is excessive parsing time rather than a distinctive log message.

What your security team should do

• Inventory all direct and transitive uses of libexpat, including embedded copies in applications, containers, appliances, SDKs, and statically linked binaries.
• Prioritize upgrades for internet-facing services, automated import pipelines, CI/build systems, and high-volume workloads that parse XML from untrusted or semi-trusted sources.
• Update libexpat to 2.8.1 or later through vendor packages or rebuilt application dependencies.
• Redeploy containers and applications after patching; do not rely only on updating the base host if vulnerable copies are bundled inside artifacts.
• Add XML parser resource controls: input-size limits, request timeouts, CPU quotas, worker isolation, and rate limits.
• Monitor XML-processing services for unusual CPU spikes, request latency increases, parser timeouts, and repeated XML ingestion failures.
• Because the vulnerability is not currently in KEV and has low EPSS, schedule broadly but escalate remediation where XML parsing is exposed to untrusted users or automated external feeds.