CVE-2026-56404

What it actually does

libexpat versions before 2.8.2 contain an integer overflow in the addBinding code path used while processing XML namespace bindings. If an attacker can cause a vulnerable application to parse a specially crafted XML document, the overflow can lead to memory corruption. Depending on compiler, platform hardening, allocator behavior, and how the consuming application uses libexpat, this may result in process crashes, corrupted parser state, disclosure or modification of process memory, and in higher-impact scenarios possible arbitrary code execution in the context of the application using libexpat. The published CVSS vector rates exploitation as local, high complexity, no privileges required, and no user interaction, so practical exploitation is expected to be environment-dependent rather than commodity at this time.

Why it matters to the business

Applications, services, developer tools, desktop software, and appliances that parse XML through vulnerable libexpat builds may be exposed to denial of service or memory-corruption risk when handling attacker-controlled XML. Because libexpat is commonly embedded or bundled by other software, exposure may exist indirectly through downstream packages, containers, operating-system packages, or statically linked binaries. The CVSS score is moderate and EPSS is currently low, with no known CISA KEV listing or public exploit maturity reported, but organizations should still prioritize remediation for systems that parse untrusted XML, run with elevated privileges, or are embedded in business-critical workflows.

How an attack unfolds

An attacker first identifies software that uses a vulnerable libexpat version before 2.8.2 and that accepts XML input from a local file, IPC path, job queue, command-line workflow, upload pipeline, or another attacker-influenced source. The attacker crafts XML designed to exercise the vulnerable namespace-binding path in addBinding and to trigger the integer overflow under specific parser and memory-layout conditions. When the target application parses the XML, the overflow can corrupt memory inside the process. In the simplest case this causes a crash and denial of service. With favorable conditions and additional exploitation work, the attacker may be able to influence corrupted memory to read or modify process data or potentially execute code with the privileges of the vulnerable application. Because exploitation is rated high complexity and exploit maturity is currently none, reliable attacks are likely to require careful targeting of the application, platform, allocator, and build options.

How to fix it

Upgrade libexpat to version 2.8.2 or later wherever it is installed, bundled, statically linked, or vendored. Because the input did not provide package-specific fixed versions, use the fixed packages from the relevant operating-system distribution, language ecosystem, appliance vendor, or container base image, and verify that the resulting runtime library reports libexpat 2.8.2 or newer. Rebuild applications that statically link or vendor libexpat, refresh container images and base layers, and ensure downstream products that bundle libexpat receive vendor updates. Where immediate upgrade is not possible, reduce exposure by preventing untrusted users from supplying XML to affected components, disabling XML features or workflows that are not required, applying application sandboxing and least-privilege controls, and isolating XML parsing workloads from sensitive processes.

How to confirm the fix worked

Confirm remediation by inventorying runtime and bundled libexpat versions and verifying they are 2.8.2 or later. Check package-manager output, software bill of materials data, container image scans, and binary dependency inspection for libexpat or expat references. For dynamically linked applications, validate which libexpat library is loaded at runtime rather than only which package is installed. For statically linked or vendored builds, rebuild and rescan the final artifact. Regression-test XML parsing functionality after upgrade. If vulnerability scanners are used, rescan hosts, images, and application artifacts and confirm that findings for libexpat before 2.8.2 are closed or suppressed only with documented evidence that the vulnerable code is not present or not reachable.

Typical attack path

1. Identify an application, utility, service, container image, or appliance that includes libexpat before 2.8.2.
2. Confirm that the target parses XML from an attacker-controlled or attacker-influenced source.
3. Construct XML content that triggers the vulnerable addBinding namespace-binding code path.
4. Deliver the XML through a local file, batch job, import function, message queue, upload workflow, or other accepted input path.
5. Cause the vulnerable process to parse the XML.
6. Trigger integer overflow and memory corruption in the libexpat parsing process.
7. Use the resulting condition to crash the process, corrupt process state, or attempt more advanced exploitation depending on runtime protections and application context.

How to detect it

There are no universal, vulnerability-specific indicators that prove exploitation of this libexpat flaw, and successful memory-corruption exploitation may leave few artifacts beyond application behavior. To assess possible prior exploitation, review logs from applications that parse XML for unexpected crashes, restarts, segmentation faults, core dumps, allocator corruption messages, and bursts of malformed XML processing errors. Correlate these events with file ingestion, upload, import, job execution, or local processing activity involving XML content. On Linux and Unix-like systems, inspect systemd journal, syslog, kernel logs, application logs, crash reporters, and core dump metadata for crashes in processes linked to libexpat. On Windows, review Application event logs, Windows Error Reporting entries, and application crash dumps for faults in expat-linked modules. If crash dumps are available, examine stack traces for libexpat XML parsing functions and the addBinding path. Also review EDR telemetry for suspicious child processes spawned by XML-processing applications, unexpected file writes, privilege changes, or network connections immediately after XML parser crashes. Treat strings such as addBinding or libexpat in crash traces as investigative leads, not definitive proof of exploitation.

• addBinding
• libexpat
• libexpat.so
• libexpat.dll
• Segmentation fault
• segfault
• core dumped
• malloc(): memory corruption
• malloc(): corrupted top size
• double free or corruption
• AddressSanitizer: signed integer overflow
• AddressSanitizer: heap-buffer-overflow
• Windows Error Reporting
• Faulting module name: libexpat.dll

What your security team should do

• Prioritize patching systems and applications that parse untrusted XML, process uploaded files, run automated import jobs, or execute XML parsing in privileged or highly available services.
• Inventory both direct and transitive libexpat exposure across operating-system packages, containers, appliances, third-party software, and statically linked application binaries.
• Upgrade to libexpat 2.8.2 or later through trusted vendor channels and rebuild any internally maintained software that vendors or statically links libexpat.
• Ask third-party software vendors to confirm whether their products bundle vulnerable libexpat versions and to provide fixed releases or compensating controls.
• Apply sandboxing, resource limits, crash restart controls, and least privilege to XML parsing components to reduce impact if exploitation is attempted before patching is complete.
• Monitor for unusual parser crashes, repeated malformed XML submissions, and memory-corruption signals in applications known to use libexpat.
• Track exploit maturity and EPSS changes; while current EPSS is low and the CVE is not in KEV, urgency should increase if proof-of-concept code, active exploitation, or vendor advisories appear.