CVE-2026-32776

What it actually does

The flaw is a denial-of-service condition in libexpat versions before 2.7.5. When libexpat parses XML that uses an external parameter entity whose resolved content is empty, an internal code path can dereference a NULL pointer and crash the parsing process. The impact is limited to availability: it does not provide code execution, data disclosure, or data modification by itself. The CVSS vector indicates local attack vector, low complexity, no privileges, and low availability impact, which means exploitation generally requires an attacker to get a vulnerable local process or application component to parse the crafted XML input.

Why it matters to the business

Applications, services, or tools that rely on vulnerable libexpat builds may crash when processing specially crafted XML, causing failed jobs, interrupted document processing, service instability, or localized outages. The currently low EPSS score, flat EPSS trend, lack of known exploitation, and absence from the CISA KEV catalog indicate low immediate internet-scale exploitation pressure, but libexpat is widely embedded in operating systems, developer tools, and application dependencies, so exposure can be indirect and easy to overlook.

How an attack unfolds

An attacker first identifies a workflow that parses XML using a vulnerable libexpat version, such as a file import feature, local document-processing tool, backend XML ingestion job, or application component that accepts XML from a local or semi-trusted source. The attacker then supplies XML that references an external parameter entity whose returned content is empty. When the vulnerable parser processes that entity, libexpat reaches a NULL pointer dereference condition and terminates the process. The attacker’s practical goal is to repeatedly trigger crashes or processing failures, creating a denial of service for the affected component.

How to fix it

Upgrade libexpat to version 2.7.5 or later wherever it is used directly, bundled, statically linked, or supplied by the operating system package manager. Rebuild applications that statically link libexpat so they incorporate the fixed library. If immediate patching is not possible, reduce exposure by disabling external entity processing where application behavior allows, rejecting untrusted XML input, enforcing strict XML schema and size limits, isolating XML parsing in a crash-contained worker process, and using supervisor controls or rate limits to prevent repeated crash loops.

How to confirm the fix worked

Confirm that all deployed and bundled libexpat instances report version 2.7.5 or later. On Linux and Unix-like systems, check package-manager inventory, shared library versions, container images, and application dependency manifests; for statically linked software, verify through vendor advisories, SBOMs, or rebuilt binaries. Where feasible, run regression tests that parse XML using external parameter entities with empty resolved content and confirm the parser returns a handled error instead of crashing. Also validate that applications either disable external entity processing or safely handle malformed XML from untrusted sources.

Typical attack path

1. Identify an application, service, script, or command-line workflow that uses libexpat to parse XML.
2. Confirm or infer that the linked or bundled libexpat version is earlier than 2.7.5.
3. Craft XML that causes parsing of an external parameter entity with empty resolved content.
4. Submit or place the XML where the vulnerable parser will process it.
5. Trigger parsing and cause the process using libexpat to crash.
6. Repeat delivery if necessary to cause recurring job failures, service restarts, or localized denial of service.

How to detect it

To assess whether exploitation may have occurred, review application, service-manager, crash-reporting, and operating-system logs for abnormal process exits in components that parse XML using libexpat. Focus on crashes that coincide with XML file imports, XML API requests, message-queue ingestion, batch processing jobs, or document-conversion workflows. Useful sources include syslog or journald, Windows Application Error logs, container runtime logs, Kubernetes pod restart history, application exception logs, core dump metadata, and endpoint detection telemetry. Look for segmentation faults or access violations with stack traces referencing libexpat parsing routines, especially around external entity parsing. Also review recently submitted XML inputs or quarantined files for external parameter entity declarations and references that resolve to empty content. There are no known public exploit campaigns, named threat actors, or stable network indicators for this issue, so detection should be behavior- and crash-correlation based rather than signature-only.

What your security team should do

• Inventory libexpat usage across operating systems, containers, appliances, developer tooling, and applications, including statically linked or vendored copies.
• Prioritize upgrading exposed XML-processing services, automated ingestion pipelines, and systems that process XML from untrusted or semi-trusted sources to libexpat 2.7.5 or later.
• Ask application owners and vendors to confirm whether their products bundle libexpat and whether fixed builds are available.
• Disable external entity processing for XML parsers where it is not explicitly required by business functionality.
• Add crash monitoring for XML-processing components and alert on repeated segmentation faults or abnormal exits associated with XML parsing workflows.
• For high-availability services, run XML parsing in isolated worker processes with restart limits, queue backoff, and input quarantine to reduce denial-of-service impact.
• Because this issue is not known to be exploited and has low EPSS, handle it through normal vulnerability management timelines unless the affected parser processes untrusted XML in critical workflows.