CVE-2026-56405

What it actually does

libexpat before 2.8.2 contains an integer overflow in getAttributeId, a code path used while parsing XML attributes. If an application parses a specially crafted XML document with a vulnerable libexpat build, arithmetic used to size or index attribute-related data can wrap, potentially causing memory corruption. Depending on compiler, platform, allocator behavior, and how the embedding application uses libexpat, the likely outcomes range from parser crash and denial of service to possible disclosure or modification of process memory. The CVSS vector indicates local attack requirements and high attack complexity, but software that accepts attacker-controlled XML through files, uploads, messages, documents, archives, configuration imports, or service-to-service data paths may expose the vulnerable parser indirectly.

Why it matters to the business

Systems and applications that rely on vulnerable libexpat versions may be destabilized or compromised when they process malicious XML content. Operationally, this can cause crashes in XML-consuming services, failed document or data ingestion workflows, and potential exposure or tampering of sensitive data handled by the affected process. Current public exploitation signals are low: EPSS is 0.00125, exploit maturity is listed as none, and the issue is not in the CISA KEV catalog or associated with known ransomware use. However, libexpat is widely embedded in operating systems, runtimes, libraries, and applications, so organizations should treat remediation as a dependency-management and software-supply-chain priority rather than only looking for a directly installed package.

How an attack unfolds

An attacker first identifies an application or command-line workflow that parses XML using libexpat before 2.8.2. They then craft XML content with attributes designed to drive the vulnerable getAttributeId logic into an integer overflow condition. The malicious XML must reach a parsing path in the victim process, such as an imported document, local file, uploaded XML, packaged metadata, configuration file, or another format that contains XML internally. When the vulnerable parser processes the crafted attributes, integer wraparound can corrupt parser state or adjacent memory. In many environments the practical result will be process termination or parsing failure; in favorable conditions an attacker may be able to influence memory contents enough to affect confidentiality or integrity inside the parsing process. No public mature exploit is reported in the supplied intelligence, so exploitation should be considered plausible but not currently commodity-scale.

How to fix it

Upgrade libexpat to version 2.8.2 or later wherever it is present, including operating-system packages, container base images, statically linked applications, vendored source copies, language runtime dependencies, and third-party products that bundle libexpat. Because fixed_versions was not provided in the input, use the upstream boundary from the description: versions before 2.8.2 are affected; 2.8.2 and later should be considered fixed. Rebuild and redeploy applications that statically link libexpat, because updating the system shared library will not protect binaries that include their own copy. Where immediate upgrade is not possible, reduce exposure by limiting XML ingestion to trusted sources, disabling nonessential XML import features, applying file-size and attribute-count limits, running XML parsers in sandboxed or low-privilege processes, and monitoring for parser crashes. Prefer vendor-supported packages over manually compiled copies so future parser security fixes are inherited reliably.

How to confirm the fix worked

Confirm installed and bundled libexpat versions are 2.8.2 or later. On Linux and Unix-like systems, check package manager output and shared library metadata, and inspect containers and application images rather than only the host OS. For applications that statically link libexpat, use software composition analysis, SBOMs, source dependency manifests, binary strings, or vendor advisories to confirm the embedded version. Validate that rebuilt services are actually loading the fixed library at runtime using tools such as ldd, otool, process module listings, container image scans, or package inventory. Regression-test XML import and parsing workflows after upgrade. Exposure remains if any reachable XML-processing component still includes libexpat before 2.8.2, even if the system package has been patched.

Typical attack path

1. Identify software or workflows that parse XML using libexpat before version 2.8.2.
2. Determine an input path where attacker-controlled XML can be supplied, such as file import, document upload, local processing, archive extraction, or automated ingestion.
3. Create XML content with crafted attributes intended to trigger integer overflow in getAttributeId.
4. Deliver the XML to the target parsing workflow and cause the vulnerable application to process it.
5. Observe for parser crash, abnormal memory behavior, service failure, or other side effects.
6. If exploitation is reliable in the target process, attempt to use memory corruption effects to disclose data, alter process state, or disrupt service.

How to detect it

To determine whether exploitation may already have occurred, review logs and telemetry from applications that parse XML using libexpat before 2.8.2. Focus on unexplained crashes, segmentation faults, aborts, heap corruption errors, sanitizer findings, core dumps, or service restarts that occur immediately after XML file ingestion, document import, archive processing, configuration loading, or message parsing. Useful sources include application logs, system logs, crash reporters, EDR process telemetry, container runtime logs, web upload logs, file-ingestion pipeline logs, mail/document processing logs, and core dump directories. Look for stack traces or crash reports referencing getAttributeId, libexpat, XML_Parse, attribute parsing, integer overflow, heap corruption, or malformed XML. Correlate suspicious XML submissions with process crashes, repeated parser failures from the same source, unusual local file-processing activity, or attempts to deliver oversized or attribute-heavy XML. There are no known public threat actors, KEV listing, ransomware linkage, or mature exploit indicators in the supplied intelligence, so detection should rely on behavioral evidence rather than fixed attacker infrastructure.

• getAttributeId
• libexpat.so
• libexpat.dylib
• expat.dll
• XML_Parse
• Segmentation fault
• SIGSEGV
• heap corruption
• malloc(): corrupted
• double free or corruption
• AddressSanitizer
• integer overflow
• core dumped

What your security team should do

• Inventory all direct, transitive, bundled, and statically linked uses of libexpat across servers, endpoints, containers, build images, appliances, and commercial software.
• Prioritize remediation for internet-facing, multi-tenant, automated-ingestion, document-processing, and high-privilege services that parse XML from untrusted or semi-trusted sources.
• Upgrade libexpat to 2.8.2 or later and rebuild/redeploy any software that vendors or statically links the library.
• Ask vendors of third-party products that process XML to confirm whether they bundle libexpat before 2.8.2 and provide fixed builds if applicable.
• Add temporary controls for XML parsing paths until patched, including input source restrictions, file-size limits, attribute-count limits, sandboxing, and least-privilege execution.
• Monitor crash telemetry, application logs, EDR events, and core dump generation for XML parser failures involving libexpat or getAttributeId.
• Because EPSS is low, exploit maturity is none, and the issue is not KEV, handle as a scheduled-but-prioritized patching item unless the vulnerable parser is exposed to untrusted XML at scale or runs in a sensitive process.