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.

A stack overflow vulnerability exists in the libexpat library due to the way it handles recursive entity expansion in XML documents. When parsing an XML document with deeply nested entity references, libexpat can be forced to recurse indefinitely, exhausting the stack space and causing a crash. This issue could lead to denial of service (DoS) or, in some cases, exploitable memory corruption, depending on the environment and library usage.

The libexpat library is vulnerable to a stack overflow due to uncontrolled recursion when processing deeply nested XML entities. This can cause the application to crash, resulting in a denial of service (DoS) or potentially leading to memory corruption, depending on the user's environment and how the library is used. The issue is triggered by supplying a specially crafted XML document designed to create a long chain of recursive entities.

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

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

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.

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,

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.

libexpat before 2.8.0 uses insufficient entropy, and thus hash flooding can occur via a crafted XML document.

libexpat before 2.8.2 does not consider XMLTOKDATACHARS in doCdataSection and thus lacks handler call depth tracking for various calls from within handlers in cases of a policy violation. Thus, a use-after-free can occur. NOTE: this issue exists because of an incomplete fix for CVE-2026-50219.

libexpat before 2.8.2 has an integer overflow in getAttributeId.

libexpat before 2.8.2 has an integer overflow in doProlog that is related to storeEntityValue and entity textLen.

libexpat before 2.8.2 has an integer overflow in storeAtts.

libexpat before 2.8.2 has an integer overflow in XMLParseBuffer because it lacked a check that was present in XMLParse.

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 has an integer overflow in addBinding.

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

xmlwf in libexpat before 2.8.2 has an integer overflow in resolveSystemId.

xmlwf in libexpat before 2.8.2 has an integer overflow for the output filename when -d outputDir is used.

xmlwf in libexpat before 2.8.2 has an integer overflow in endDoctypeDecl via NOTATION declarations.

An issue was discovered in libexpat before 2.6.3. xmlparse.c does not reject a negative length for XMLParseBuffer.

An issue was discovered in libexpat before 2.6.3. dtdCopy in xmlparse.c can have an integer overflow for nDefaultAtts on 32-bit platforms (where UINTMAX equals SIZEMAX).

libexpat before 2.8.2 has an integer overflow in copyString.

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

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

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