CVE-2026-32778

What it actually does

libexpat versions before 2.7.5 can dereference a NULL pointer in the XML parsing context handling path, specifically in setContext, when parsing is retried after a prior out-of-memory condition. The result is a process crash rather than code execution or data exposure. Exploitation requires an attacker to influence XML parsing behavior and trigger a constrained memory-failure/retry sequence, which makes practical exploitation higher complexity and primarily limited to denial of service against software that embeds libexpat.

Why it matters to the business

Applications, services, command-line tools, or middleware that parse XML using vulnerable libexpat versions may crash when processing attacker-controlled or malformed XML under memory pressure. The expected impact is localized service interruption, failed jobs, degraded availability, or instability in dependent software rather than compromise of confidential data. Current public exploitation likelihood appears low: EPSS is 0.00171, the 30-day trend is flat, it is not listed in CISA KEV, and no exploit maturity is reported.

How an attack unfolds

An attacker first identifies software that accepts XML input and uses a vulnerable libexpat build before 2.7.5. They then provide XML content or workload conditions intended to force or coincide with an out-of-memory state during parsing. If the application retries parsing after the earlier memory allocation failure, the vulnerable setContext code path can dereference a NULL pointer. This causes the hosting process to terminate or crash, producing a denial-of-service condition for that application or processing pipeline. There is no indication from the vulnerability description that the flaw enables arbitrary code execution, privilege escalation, or data theft.

How to fix it

Upgrade libexpat to version 2.7.5 or later wherever it is directly installed, statically linked, vendored, or bundled inside applications, containers, language runtimes, appliances, or operating-system packages. Because libexpat is commonly consumed as a transitive dependency, inventory both system packages and embedded copies. If immediate patching is not possible, reduce exposure by limiting who can submit XML, enforcing strict request size and resource limits, disabling unnecessary XML ingestion features, applying process supervision/restart controls, and isolating XML parsing workloads so a crash does not take down higher-value services.

How to confirm the fix worked

Confirm that all deployed libexpat instances report version 2.7.5 or later, including package-manager installations, container images, statically linked binaries, and vendored source copies. Use software composition analysis, package inventory, container scanning, and binary inspection where appropriate. Validate that applications depending on libexpat still function after upgrade and that XML parsing workloads no longer crash under controlled memory-pressure and retry testing. For exposure review, identify services, APIs, import functions, file processors, or local workflows that accept XML from untrusted or semi-trusted users.

Typical attack path

1. Identify an application, service, batch processor, or library consumer that parses XML using libexpat before 2.7.5.
2. Submit attacker-controlled XML or otherwise trigger XML parsing through an exposed feature, import path, API, or local processing workflow.
3. Induce or wait for an out-of-memory condition during XML parsing.
4. Cause the application to retry parsing after the earlier allocation failure.
5. Trigger the vulnerable setContext retry path, resulting in a NULL pointer dereference.
6. Cause the affected process to crash, interrupting the service or XML-processing operation.

How to detect it

Look for evidence of application crashes or abnormal restarts in services that parse XML and link to libexpat. Useful sources include Linux system logs, Windows Application Event Logs, container runtime logs, Kubernetes pod restart events, application error logs, core dump metadata, crash reporters, EDR telemetry, and service supervisor logs. Focus on crashes preceded by XML processing, import jobs, API requests carrying XML, unusually large XML payloads, or out-of-memory messages. Because the vulnerability produces a crash rather than a distinctive network exploit signature, detection should correlate SIGSEGV/access-violation events with libexpat stack frames such as setContext or XML_Parse and with recent XML input activity. Absence of these artifacts does not prove non-exploitation, especially if crash dumps are disabled or logs rotate quickly.

• setContext
• XML_Parse
• libexpat.so
• libexpat.dll
• expat.dll
• SIGSEGV
• segmentation fault
• NULL pointer dereference
• Out of memory
• oom-killer
• core dumped

What your security team should do

• Prioritize upgrade of internet-facing, multi-tenant, or high-availability applications that parse XML with libexpat before 2.7.5.
• Inventory direct, transitive, vendored, and statically linked copies of libexpat across hosts, containers, build artifacts, and third-party software.
• Add crash monitoring for XML-processing services, especially SIGSEGV events involving libexpat, setContext, XML_Parse, or out-of-memory conditions.
• Apply memory, payload-size, timeout, and restart controls around XML parsing paths to limit denial-of-service blast radius.
• Treat this as a routine availability fix unless the affected XML parser is part of a critical production service; KEV status is false, ransomware use is not reported, EPSS is low and flat, and exploit maturity is listed as none.
• Update base images and rebuild dependent applications so patched libexpat versions are actually included in runtime artifacts.