libexpat CVE-2026-77214

Exploitation requires that (1) a parse buffer already exists - the application must have previously called XML_GetBuffer directly, or XML_Parse which allocates the buffer internally (otherwise XML_ParseBuffer returns XML_ERROR_NO_BUFFER and the path is unreachable), and (2) the application calls XML_ParseBuffer with a len argument larger than the allocated/remaining buffer capacity. The decisive limiting factor is that len is CALLER-supplied: the attacker must be able to influence the length value the embedding application passes, which does not occur in standard usage where the application sizes the buffer to match the data it copies in. Default XML document parsing where len matches the buffer is NOT affected; only applications that derive the ParseBuffer length from untrusted input independent of the actual buffer size are exposed.

Signals are mixed. The input CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:L, score 8.3) rates this High, driven by VC:H - the over-read discloses adjacent heap memory including heap, libc, and code pointers sufficient to defeat ASLR. However, the AT:P (attack requirements present) metric is the crucial qualifier: this is a library API-misuse flaw, not a self-contained remote bug. XML_ParseBuffer trusts a CALLER-supplied length (len) that it fails to validate against allocated buffer size, so exploitation requires the embedding application to pass an attacker-influenced len larger than the buffer obtained via XML_GetBuffer/XML_Parse. In the overwhelmingly common usage pattern the application sizes the buffer and len itself, so PR:N/AV:N overstates real-world reachability for most consumers - the network attacker rarely controls the len argument directly. No EPSS score, KEV listing, or public exploit was provided, so there is no evidence of active exploitation; this reads as a genuine but conditional information-disclosure primitive rather than a mass-exploitable RCE. Priority is moderate: patch promptly because libexpat is ubiquitous, but realistic impact hinges on specific calling-code patterns rather than default XML parsing.

An application embeds libexpat and passes a length value derived from attacker-controlled input (e.g. a declared content-length) to XML_ParseBuffer after obtaining a smaller buffer via XML_GetBuffer or a prior XML_Parse. The oversized len drives m_bufferEnd past the heap allocation, and subsequent parsing reads out-of-bounds heap memory, leaking pointers back to the attacker to defeat ASLR. No public exploit was identified at time of analysis; a regression test accompanies the fix but is not a weaponized POC.