Advisory · CVE-2026-77214
libexpat heap buffer over-read can leak memory and defeat ASLR
A heap buffer over-read in libexpat's XML_ParseBuffer, fixed by upstream commit 13c5f63, lets attackers recover heap and libc pointers and defeat address randomization.
- Vendor
- libexpat
- Product
- libexpat
- Identifier / CWE
- CVE-2026-77214
CWE-125 - Action timing
- Immediate
Explain it like I’m five
A hugely popular text-reading helper does not double-check how far it is allowed to read. It can peek at neighboring memory and hand attackers the secret map they need for bigger attacks.
- 01Parse buffer present
An application using libexpat has a parse buffer present, for example after a prior XML_GetBuffer or XML_Parse call.
- 02Unvalidated length
The application calls XML_ParseBuffer with a caller-supplied length that xmlparse.c does not validate against the allocated buffer size.
- 03Pointer walks past the end
Repeated calls advance the parse buffer end past the heap allocation, and subsequent parsing reads out of bounds.
- 04Memory disclosed
The over-read exposes adjacent heap memory, recovering heap pointers, libc function pointers, and code pointers sufficient to defeat ASLR and build further exploitation primitives.
What happened
VulnCheck disclosed CVE-2026-77214 on October 7, 2026, scoring it 8.3 (CVSS 4.0) / 8.2 (CVSS 3.1). libexpat before upstream commit 13c5f63 (releases up to 2.8.5) contains a heap buffer over-read in xmlparse.c: XML_ParseBuffer advances the parse buffer end using a caller-supplied length without validating it against the allocated buffer size, so repeated calls move the pointer past the heap allocation and subsequent parsing reads out of bounds.
The over-read discloses adjacent heap memory to the calling application, recovering heap pointers, libc function pointers, and code pointers sufficient to defeat ASLR and build further exploitation primitives. Upstream fixed the issue in commit 13c5f63 (pull request 1393).
What to do
- Identify where libexpat is used in your stack; it ships inside countless applications, OS packages, and language runtimes.
- Upgrade to a libexpat release containing the fix (past commit 13c5f63) via your OS vendor or rebuild from upstream.
- Rebuild or update dependent applications that statically link libexpat.
- Prioritize internet-facing XML parsers (web services, document pipelines, email gateways) that feed attacker-controlled XML into the library.
Management note
libexpat is plumbing: you almost certainly run it without knowing. The direct impact is memory disclosure rather than code execution, but ASLR bypass is the enabler that turns other memory bugs into reliable exploits. Patch it through normal dependency updates and make sure statically linked copies are not forgotten.