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.

Hello oss-security,

just a quick note that libexpat 2.9.0 (or "Expat 2.9.0") released today is fixing two vulnerabilities:

- CVE-2026-77214 - CVE-2026-102633

The related part of the change log is this:

#1392 CVE-2026-102633 -- Integer overflow in function expatrealloc on 32bit platforms #1393 CVE-2026-77214 -- Validate parameter len against available buffer capacity in XMLParseBuffer

Some key links are:

- The blog post about it https://blog.hartwork.org/posts/expat-2-9-0-released/

- The full change log of release 2.9.0 https://github.com/libexpat/libexpat/blob/R290/expat/Changes

- The fixing pull requests - https://github.com/libexpat/libexpat/pull/1392 - https://github.com/libexpat/libexpat/pull/1393

- The NVD CVE metadata - https://nvd.nist.gov/vuln/detail/cve-2026-77214 - https://nvd.nist.gov/vuln/detail/cve-2026-102633

Best

Sebastian

libexpat 2.7.2 through 2.8.5 Integer Overflow in expatrealloc

Hello oss-security,

just a quick note that libexpat 2.8.5 (or "Expat 2.8.5") released today is fixing CVE-2026-93990:

Reject high surrogates not followed by a low surrogate during UTF-16 decoding; previously, malformed UTF-16 could be smuggled into the application using Expat and could cause arbitrary damage there, depending on how malformed UTF-16 was handled inside the application; validation was not their job but Expat's. This is similar to past vulnerability CVE-2022-25235. Upstream CVSS 3.1 vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (CVSS score: 9.8)

Some key links are:

- The blog post about it https://blog.hartwork.org/posts/expat-2-8-5-released/

- The change log of release 2.8.5 https://github.com/libexpat/libexpat/blob/R285/expat/Changes

- The fixing pull request https://github.com/libexpat/libexpat/pull/1282

- The NVD CVE metadata https://nvd.nist.gov/vuln/detail/CVE-2026-93990 (with a different CVSS vector)

Best

Sebastian

Expat before 2.8.5 fails to validate that a high surrogate in UTF-16 input is followed by a low surrogate, allowing malformed UTF-16 sequences to be accepted. Attackers can supply UTF-16 encoded XML containing lone high surrogates that consume the following code unit, causing Expat to pass unpaired surrogates to applications built with XMLUNICODE and to silently replace input characters in other builds.

Expat through 2.8.3 contains an out-of-bounds read vulnerability that allows attackers to trigger memory corruption by processing XML with external entity parsers created via XMLExternalEntityParserCreate. A struct size mismatch between ELEMENTTYPE members causes storeAtts to read the attIndex member past allocated memory boundaries, resulting in failure to normalize whitespace in non-CDATA attributes or a wild pointer dereference causing a segfault. This vulnerability was introduced by the fix for CVE-2026-66046.

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.

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).

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.

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

Last updated 21 September 2026

Hello oss-security,

just a quick note that libexpat 2.7.5 (or "Expat 2.7.5") released today is fixing three vulnerabilities.

Some key links are:

- The blog post about it: https://blog.hartwork.org/posts/expat-2-7-5-released/

- The change log of release 2.7.5 https://github.com/libexpat/libexpat/blob/R275/expat/Changes

- The fixing pull requests - https://github.com/libexpat/libexpat/pull/1158 - https://github.com/libexpat/libexpat/pull/1162 - https://github.com/libexpat/libexpat/pull/1163

- The official CVE metadata - https://nvd.nist.gov/vuln/detail/CVE-2026-32776 - https://nvd.nist.gov/vuln/detail/CVE-2026-32777 - https://nvd.nist.gov/vuln/detail/CVE-2026-32778

Best

Sebastian

When an Expat parser with a registered ElementDeclHandler parses an inline document type definition containing a deeply nested content model a C stack overflow occurs.

https://github.com/libexpat/libexpat/issues/1076 notes: Hi!

Just a quick note that there is another unfixed vulnerability in Expat on my desk by now:

- It's been reported on September 25th by a human (not fuzzing) - The impact is denial of service - To be more concrete: A crafted file of size ~2 MiB can cause 25–100 seconds processing time, depending on the used hardware.

My own priorities are elsewhere at the moment. Please reach out if:

- you want to help finding a true fix and - you are okay with signing a freeform NDA (to keep the vulnerability details confidential until a fix has made its way into Git master).

It's not going to be as complex as resolving recursion for Expat 2.7.0 but the path forward for a fix is not clear yet.

Best, Sebastian

PS: Comments are intentionally closed, please reach out via the e-mail in my profile, instead. [note that I'm just passing this along - if you want to help, contact Sebastian via the link to his profile from the github issue, not me.]

libexpat in Expat before 2.7.2 allows attackers to trigger large dynamic memory allocations via a small document that is submitted for parsing.

Accessibility. A privacy issue was addressed by removing sensitive data.