libexpat CVE-2026-56403

Exploitation requires that the target application uses libexpat before 2.8.2 to parse attacker-controlled XML that includes namespace-qualified attributes - specifically, the vulnerable storeAtts() code path is only reached when the parsed XML uses XML namespace bindings (xmlns: prefix declarations); plain XML documents without namespace usage do not enter the affected code. The namespace prefix name or XML local-part name must be crafted to approach or exceed INT_MAX (~2.1 billion) bytes in length, a condition that is AC:H because it demands deliberate construction and will frequently be blocked by upstream protocol message-size limits (e.g., HTTP max body size, SAML message constraints, or OS pipe limits). The library itself imposes no authentication requirement, but the calling application's access controls determine whether external, unauthenticated parties can supply XML documents. No non-default libexpat compile-time or runtime configuration is required; the vulnerability is present in the default build. Exploitation is limited in practice by allocator hardening (ASLR, heap metadata canaries) and the difficulty of constructing a multi-gigabyte XML token within typical protocol constraints.

The vendor-assigned CVSS vector AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:L (score 6.9) assigns a Local attack vector, which is conservative relative to libexpat's actual deployment footprint: the library routinely parses XML originating from HTTP bodies, SOAP messages, SAML assertions, RSS feeds, and other network-delivered content, making an independent AV:N assessment more representative of real-world exposure. AC:H is well-justified because crafting a namespace prefix or local-part that approaches INT_MAX (~2 billion characters) is non-trivial and will frequently be blocked by upstream protocol message-size limits or application-layer input validation. The High C and I scores reflect the theoretical worst case - heap corruption enabling code execution - though actual exploitability to that level depends heavily on heap layout and allocator mitigations. No CVE is listed in the CISA KEV catalog, no EPSS data is present in the available intelligence, and no public exploit code has been identified, all pointing to low current exploitation activity. The principal real-world concern is services that parse large, attacker-controlled XML documents (e.g., public XML APIs, document upload endpoints, federated identity flows using SAML) without enforcing document size limits; those deployments warrant near-term patching. Organizations processing only bounded, trusted XML face substantially lower risk.

An attacker submits a crafted XML document containing a namespace declaration whose prefix name is constructed to be close to or exceeding INT_MAX bytes in length to a service that passes the document through libexpat before 2.8.2. The storeAtts() function increments prefixLen until integer overflow yields a small wrapped value, causing heap allocation of an undersized buffer; the subsequent memcpy writes the full-length string past the buffer boundary, corrupting adjacent heap metadata and potentially enabling controlled code execution within the parsing process.