Hello oss-security,

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

- CVE-2026-113351 - CVE-2026-115506 - CVE-2026-117610 - CVE-2026-118370

The related part of the change log is this:

#1431 CVE-2026-113351 -- Fix denial of service with use of XMLParserReset #1433 #1436 .. #1438 #1439 .. #1442 CVE-2026-115506 -- Detect billion laughs attacks quicker and more of its variations. Related payload fuzzer at: https://github.com/hannob/lololol Please note that a layer of compression around XML can significantly reduce the minimum attack payload size. In case of backporting, please note pull request #1439 in particular. #1444 CVE-2026-117610 -- Fix initial non-final empty subparser parse calls. Was segfaulting previously. #1450 CVE-2026-118370 -- Protect attIndex and nPrefixes in function storeAtts from signed integer overflow

Some key links are:

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

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

- The fixing pull requests - https://github.com/libexpat/libexpat/pull/1431 - https://github.com/libexpat/libexpat/pull/1433 - https://github.com/libexpat/libexpat/pull/1439 - https://github.com/libexpat/libexpat/pull/1444 - https://github.com/libexpat/libexpat/pull/1450

- The NVD CVE metadata - https://nvd.nist.gov/vuln/detail/cve-2026-113351 - https://nvd.nist.gov/vuln/detail/cve-2026-115506 - https://nvd.nist.gov/vuln/detail/cve-2026-117610 - https://nvd.nist.gov/vuln/detail/cve-2026-118370

Best

Sebastian

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.

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

Expat through 2.8.4 fails to validate low surrogates following high surrogates in UTF-16 input, allowing malformed UTF-16 sequences to be accepted. Attackers can craft UTF-16 encoded XML with lone high surrogates that consume following code units, hiding markup characters from the parser and enabling XML injection attacks.

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.

Expat through 2.8.3 contains a denial of service vulnerability caused by quadratic algorithmic complexity in the storeAtts() function in xmlparse.c, where processing N specified attributes with non-normalized values triggers an O(N^2) linear scan of elementType->defaultAtts to determine CDATA status. A remote unauthenticated attacker can supply a single well-formed XML document of a few megabytes to an application parsing untrusted XML to cause excessive CPU consumption, resulting in denial of service without requiring authentication, external entity resolution, or non-default parser options.

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