libexpat is vulnerable to a denial of service, caused by improper system resource allocation. By sending a specially crafted request using an overly large token, a remote attacker could exploit this vulnerability to cause a denial of service.

A use-after-free flaw was found in the Expat package, caused by destruction of a shared DTD in XMLExternalEntityParserCreate in out-of-memory situations. This may lead to availability disruptions.

A flaw in XML parsing could have led to a use-after-free causing a potentially exploitable crash.In official releases of Firefox this vulnerability is mitigated by wasm sandboxing; versions managed by Linux distributions may have other settings.

A flaw was found in expat. Passing malformed 2- and 3-byte UTF-8 sequences (for example, from start tag names) to the XML processing application on top of expat can lead to arbitrary code execution. This issue is dependent on how invalid UTF-8 is handled inside the XML processor.

A flaw was found in expat. Passing one or more namespace separator characters in the "xmlns[:prefix]" attribute values made expat send malformed tag names to the XML processor on top of expat. This issue causes arbitrary code execution depending on how unexpected cases are handled inside the XML processor.

An integer overflow was found in expat. The issue occurs in storeRawNames() by abusing the mbuffer expansion logic to allow allocations very close to INTMAX and out-of-bounds heap writes. This flaw can cause a denial of service or potentially arbitrary code execution.

An integer overflow flaw was found in expat. This issue affects the encoding name parameter at the parser creation time, which is often hard-coded (rather than user input), takes a value in the gigabytes to trigger, and on a 64-bit machine. This flaw can cause a denial of service.

A flaw was found in expat. A stack exhaustion in doctype parsing could be triggered by a file with a large number of opening braces, resulting in a denial of service.

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

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,

Peter Valchev discovered a flaw in the way expat handled malformed UTF-8 sequences when processing XML files. Incorrect UTF-8 sequenced could cause expat to fail to properly detect end of input and continue reading behind the end of input buffer. This results in a crash once reading reaches unmapped memory.

Non-public upstream bug report: http://sourceforge.net/tracker/?func=detail&aid=1990430&groupid=10127&atid=110127

Contents of the report leaked via expat-bugs mailing list posts: http://mail.python.org/pipermail/expat-bugs/2009-January/002781.html

Upstream patch: http://expat.cvs.sourceforge.net/viewvc/expat/expat/lib/xmltokimpl.c?r1=1.13&r2=1.15

References: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551936 https://bugs.gentoo.org/showbug.cgi?id=280615

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

libexpat before 2.7.5 allows a NULL pointer dereference with empty external parameter entity content.

libexpat before 2.7.5 allows an infinite loop while parsing DTD content.

libexpat before 2.7.5 allows a NULL pointer dereference in the function setContext on retry after an earlier ouf-of-memory condition.

In libexpat through 2.7.3, a crafted file with an approximate size of 2 MiB can lead to dozens of seconds of processing time.

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

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

Accounts. A logic issue was addressed with improved file handling.

In libexpat before 2.7.4, XMLExternalEntityParserCreate does not copy unknown encoding handler user data.

In libexpat before 2.7.4, the doContent function does not properly determine the buffer size bufSize because there is no integer overflow check for tag buffer reallocation.

As reported on oss-security [1]:

So here are the CVE's for the two big ones, libxml2 and expat. Both are affected by the expansion of internal entities (which can be used to consume resources) and external entities (which can cause a denial of service against other services, be used to port scan, etc.).

To be clear:

==================== Internal entity expansion refers to the exponential/quadratic/fast linear expansion of XML entities, e.g.: ==================== <!DOCTYPE xmlbomb [ <!ENTITY a "1234567890" > <!ENTITY b "&a;&a;&a;&a;&a;&a;&a;&a;"> <!ENTITY c "&b;&b;&b;&b;&b;&b;&b;&b;"> <!ENTITY d "&c;&c;&c;&c;&c;&c;&c;&c;"> ]> <bomb>&d;</bomb>

or

<!DOCTYPE bomb [ <!ENTITY a "xxxxxxx... a couple of ten thousand chars"> ]> <bomb>&a;&a;&a;... repeat</bomb>

Which causes resources to be consumed

... Please use CVE-2013-0340 for expat internal entity expansion

[1] http://www.openwall.com/lists/oss-security/2013/02/22/4

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.