libexpat through 2.9.0 contains a signed integer overflow vulnerability in storeAtts() in lib/xmlparse.c that allows attackers to trigger out-of-bounds writes via oversized attribute counts. Attackers can supply a multi-gigabyte document with a start tag carrying over 2^30 attributes to overflow attIndex and nPrefixes, crashing applications or corrupting heap memory.
libexpat through 2.9.0 contains a NULL pointer dereference vulnerability in externalEntityInitProcessor2() in lib/xmlparse.c that mishandles the XMLTOKNONE token from empty input. Attackers who control stream chunking can force an empty non-final first parse on an external entity subparser, causing a later parse to crash the application.
libexpat through 2.9.0 contains a denial of service vulnerability because billion laughs protection in accountingDiffTolerated() in xmlparse.c detects entity amplification too late. Attackers can supply a moderately sized XML document with a large DTD and nested entity expansions to consume tens of seconds of CPU per parse.
libexpat 2.7.2 through 2.9.0 contains a denial of service vulnerability because XMLParserReset zeroes the direct byte count but never offsets tracked heap allocations. Attackers can submit a large XML document so later documents on the same reset parser fail with XMLERRORNOMEMORY until it is recreated.
libexpat before commit 13c5f63 contains a heap buffer over-read vulnerability in xmlparse.c. XMLParseBuffer advances the parse buffer end with parser->mbufferEnd += len using a caller-supplied length that is not validated against the allocated buffer size, so repeated XMLParseBuffer calls move mbufferEnd past the end of the heap allocation and subsequent parsing reads out of bounds. Reaching this path requires a parse buffer to already be present; otherwise XMLParseBuffer returns XMLERRORNOBUFFER. A buffer is present after a prior call to XMLGetBuffer, either directly (the common case) or indirectly through a prior XMLParse call that allocates the buffer internally. 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.
libexpat before commit 13c5f63 contains a heap buffer over-read vulnerability in xmlparse.c. XMLParseBuffer advances the parse buffer end with parser->mbufferEnd += len using a caller-supplied length that is not validated against the allocated buffer size, so repeated XMLParseBuffer calls move mbufferEnd past the end of the heap allocation and subsequent parsing reads out of bounds. Reaching this path requires a parse buffer to already be present; otherwise XMLParseBuffer returns XMLERRORNOBUFFER. A buffer is present after a prior call to XMLGetBuffer, either directly (the common case) or indirectly through a prior XMLParse call that allocates the buffer internally. 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.
libexpat versions 2.7.2 through 2.8.5 contain an integer overflow vulnerability in expatrealloc() function on 32-bit platforms when computing allocation sizes. Attackers supplying malicious XML to applications parsing with vulnerable libexpat can cause heap buffer overflow, memory corruption, or denial of service.
libexpat 2.7.2 through 2.8.5 Integer Overflow in expatrealloc
Last updated 21 September 2026
Last updated 24 September 2026
Last updated 24 September 2026
Last updated 24 September 2026
Last updated 21 September 2026
Last updated 24 September 2026
Last updated 24 September 2026
Last updated 6 October 2026
Last updated 6 October 2026
Last updated 21 September 2026
In libexpat before 2.8.2, there is a heap-based buffer overflow in doProlog in xmlparse.c because scaffold backing array reallocation is mishandled when there is data-structure sharing across parsers.
In libexpat before 2.8.2, there is a heap-based buffer overflow in doProlog in xmlparse.c because scaffold backing array reallocation is mishandled when there is data-structure sharing across parsers.
libexpat before 2.8.2 lacks handler call depth tracking for calls to XMLResumeParser from within handlers in cases of a policy violation. Thus, a use-after-free can occur (similar to the CVE-2026-50219 situation).
libexpat before 2.8.2 lacks handler call depth tracking for calls to XMLGetBuffer, XMLParse, XMLParseBuffer, XMLParserFree, or XMLParserReset from within handlers in cases of a policy violation. Thus, a use-after-free can occur,
Last updated 21 September 2026
Hello oss-security,
just a quick note that libexpat 2.8.1 (or "Expat 2.8.1") released yesterday is fixing CVE-2026-45186:
Fix quadratic runtime from attribute name collision checks that allowed denial of service attacks through moderately sized crafted XML input (CWE-407). Please note that a layer of compression around XML can significantly reduce the minimum attack payload size.
Some key links are:
- The blog post about it https://blog.hartwork.org/posts/expat-2-8-1-released/
- The change log of release 2.8.1 https://github.com/libexpat/libexpat/blob/R281/expat/Changes
- The fixing pull request https://github.com/libexpat/libexpat/pull/1216
- The NVD CVE metadata https://nvd.nist.gov/vuln/detail/CVE-2026-45186
PS: The CVE database lists an unrealistically low CVSS score for this. The complexity of an attack is very low (not "High") and the attack vector is remote (not "Local"). I have asked Mitre to fix this earlier today. My blog post linked above has a few more words on that topic.
Best
Sebastian
xml.parsers.expat and xml.etree.ElementTree use insufficient entropy for Expat hash-flooding protection, which allows a crafted XML document to trigger hash flooding.\r\n\r\nFully mitigating this vulnerability requires both updating libexpat to 2.8.0 or later and applying this patch.
xml.parsers.expat and xml.etree.ElementTree use insufficient entropy for Expat hash-flooding protection, which allows a crafted XML document to trigger hash flooding.\r\n\r\nFully mitigating this vulnerability requires both updating libexpat to 2.8.0 or later and applying this patch.
xml.parsers.expat and xml.etree.ElementTree use insufficient entropy for Expat hash-flooding protection, which allows a crafted XML document to trigger hash flooding.\r\n\r\nFully mitigating this vulnerability requires both updating libexpat to 2.8.0 or later and applying this patch.
In libexpat before 2.8.1, the computational complexity of attribute name collision checks allows a denial of service via moderately sized crafted XML input.
In libexpat before 2.8.1, the computational complexity of attribute name collision checks allows a denial of service via moderately sized crafted XML input.
Hello oss-security,
just a quick note that libexpat 2.8.0 (or "Expat 2.8.0") released two days ago is fixing CVE-2026-41080.
Some key links are:
- The blog post about it https://blog.hartwork.org/posts/expat-2-8-0-released/
- The change log of release 2.8.0 https://github.com/libexpat/libexpat/blob/R280/expat/Changes
- The fixing pull request https://github.com/libexpat/libexpat/pull/1183
- The official CVE metadata https://nvd.nist.gov/vuln/detail/CVE-2026-41080
Best
Sebastian