CVE-2026-56132

What it actually does

libexpat versions before 2.8.2 contain a heap-based buffer overflow in doProlog in xmlparse.c. The flaw is caused by incorrect handling of scaffold backing-array reallocation when parser data structures are shared across parsers. If an application parses a specially crafted XML document under the vulnerable conditions, memory adjacent to the heap buffer can be overwritten. Depending on allocator behavior, compile-time hardening, and the embedding application, this can lead to process crashes, memory corruption, disclosure of process memory, or potentially arbitrary code execution in the context of the process using libexpat. Exploitation is assessed as high complexity, and no public exploit maturity or known exploited status is currently reported.

Why it matters to the business

Applications, services, command-line tools, and language runtimes that depend on vulnerable libexpat builds may be exposed when they parse untrusted XML. A successful attack could disrupt XML-processing workloads, compromise data handled by the affected process, or allow an attacker to tamper with application execution. Because libexpat is a widely embedded library, exposure may exist indirectly through operating-system packages, application bundles, containers, appliances, and statically linked software even when libexpat is not used directly by application code. Current exploitation likelihood appears low based on the available EPSS score and lack of KEV listing, but the potential confidentiality and integrity impact warrants planned remediation, especially for systems that process XML from untrusted sources.

How an attack unfolds

An attacker first identifies software that uses a vulnerable libexpat version to parse XML. The attacker then crafts an XML input intended to trigger parser behavior involving prolog processing and shared parser data structures, causing the scaffold backing array to be reallocated incorrectly. When the vulnerable code path in doProlog is reached, heap memory corruption occurs. In the simplest outcome, the target process terminates unexpectedly, producing a denial-of-service condition. With precise heap shaping and knowledge of the embedding process, allocator, and build protections, an attacker may be able to convert the overflow into unauthorized memory disclosure or execution control within the process. Because the CVSS vector is local and attack complexity is high, exploitation generally requires the attacker to already have a path to place or supply XML to a vulnerable parser under specific runtime conditions; however, products that accept XML over network-facing interfaces can increase practical exposure beyond the base library assessment.

How to fix it

Upgrade libexpat to version 2.8.2 or later wherever it is present. Remediation should include operating-system packages, vendor-supplied application packages, container base images, language runtime dependencies, statically linked binaries, embedded firmware, and bundled third-party libraries. Rebuild or redeploy applications that statically link libexpat so they actually incorporate the patched code. If immediate patching is not possible, reduce exposure by blocking or strictly validating untrusted XML, disabling XML features that are unnecessary, isolating XML parsing in a low-privilege sandbox, applying memory-safety hardening such as ASLR/DEP/stack and heap protections, and limiting access to XML ingestion paths. Monitor vendor advisories for downstream products that bundle libexpat, because the visible application version may not clearly reveal the embedded library version.

How to confirm the fix worked

Confirm the effective runtime version of libexpat is 2.8.2 or later. Use package inventory tools such as rpm, dpkg, apk, pkg, or vendor software inventory to check dynamically installed libraries, and use container/image scanners and SBOM tooling to identify bundled copies. For binaries, inspect linked libraries with tools such as ldd, otool, readelf, strings, or equivalent platform tooling, and verify that statically linked applications were rebuilt after the patched library became available. Where feasible, run dependency scanners against source and build artifacts to locate vendored expat/xmlparse.c copies. Validate that XML-processing services restart after the upgrade so patched libraries are loaded into memory. Negative validation should include confirming that no libexpat.so, expat.dll, or statically embedded expat code from versions before 2.8.2 remains in active runtime paths.

Typical attack path

1. Identify an application, service, package, container image, or appliance that includes libexpat before 2.8.2.
2. Confirm that the target processes XML using the vulnerable libexpat code path rather than a different XML parser or a patched library.
3. Find an input channel where attacker-controlled XML can be parsed, such as a local file import, job queue, document processing workflow, configuration loader, API payload, or message ingestion path.
4. Craft XML that exercises prolog parsing and parser data-structure sharing conditions needed to trigger the scaffold backing-array reallocation bug.
5. Deliver the crafted XML to the vulnerable parsing component.
6. Trigger heap corruption in doProlog during parsing.
7. Use the resulting memory corruption to crash the process, leak data, corrupt application state, or attempt code execution depending on process privileges and exploit reliability.

How to detect it

There are no known public exploit indicators, no KEV listing, and no reliable network signature specific to this vulnerability. Detection should focus on exposure identification and post-event evidence of memory corruption in XML-processing components. Review application logs, system journals, crash dumps, EDR telemetry, core dump directories, container restart events, and service supervisor logs for crashes occurring during XML parsing or shortly after processing XML inputs. Look for allocator corruption messages, segmentation faults, access violations, AddressSanitizer findings, or stack traces referencing libexpat, xmlparse.c, or doProlog. Correlate crashes with recently processed XML files, imports, API requests, queued messages, or document-processing jobs. Preserve suspicious XML inputs, core dumps, and process memory artifacts for analysis. For externally reachable services that accept XML, review web server, API gateway, WAF, and application access logs for unusual XML payload volume, malformed XML submissions, repeated parser failures, or requests preceding process crashes. Because heap corruption may produce nonspecific symptoms, absence of these indicators does not prove absence of exploitation.

• doProlog
• xmlparse.c
• libexpat.so
• libexpat.so.1
• expat.dll
• AddressSanitizer: heap-buffer-overflow
• heap-buffer-overflow
• Segmentation fault
• SIGSEGV
• access violation
• malloc(): corrupted
• malloc(): invalid size
• corrupted double-linked list
• double free or corruption
• free(): invalid pointer
• core dumped

What your security team should do

• Prioritize inventory of systems and products that parse XML from untrusted or semi-trusted sources, including file ingestion, document conversion, SSO/SAML/XML integrations, SOAP services, configuration importers, and message-processing pipelines.
• Upgrade libexpat to 2.8.2 or later through OS, application, container, and vendor update channels; rebuild statically linked applications.
• Search SBOMs, container images, appliance manifests, and source repositories for bundled or vendored libexpat copies, especially expat/xmlparse.c.
• Apply compensating controls for exposed XML parsers until patched: restrict input sources, enforce XML size and structure limits, sandbox parsers, and run parsing components with least privilege.
• Review crash telemetry and application logs for unexplained XML parser crashes or heap corruption events since publication, while recognizing that reliable exploit-specific indicators are not currently available.
• Track vendor advisories for downstream products that include libexpat and verify their fixed releases incorporate libexpat 2.8.2 or later.
• Treat exploitation risk as currently low but non-negligible: it is not listed as known exploited and EPSS is low, but the vulnerability affects a widely embedded parsing library with high potential confidentiality and integrity impact.