* SECURITY UPDATE: Use-after-free because handler call depth tracking was absent entirely, leaving XML_Parse, XML_ParseBuffer, XML_GetBuffer, XML_ParserFree, XML_ParserReset and XML_ResumeParser callable on the running parser from inside an application handler, and the XML_TOK_DATA_CHARS handler calls in doCdataSection() left untracked (libexpat before 2.8.2) - debian/patches/CVE-2026-56131.patch: introduce the handler call depth counter m_handlerCallDepth with the beforeHandler() / afterHandler() / isCalledFromInsideHandler() helpers from upstream PR #1246, wrap all 55 handler call sites in expat/lib/xmlparse.c, and reject the six affected entry points with XML_STATUS_ERROR / NULL when the counter is non-zero; XML_StopParser and XML_ExternalEntityParserCreate are deliberately left unguarded, as upstream intends. Also carries upstream PR #1278, which wraps the two doCdataSection XML_TOK_DATA_CHARS charDataHandler calls that the original framework missed and through which the depth guard was otherwise bypassable. Of the 55 wrapped call sites 53 are live; the other two sit inside expat's pre-existing "else if (0 && ...)" disabled branches, which upstream 2.8.2 wraps as well. Carries upstream's regression test into expat/tests/runtests.c. Behaviour change inherited from upstream: leaving a handler through a non-local exit, such as a C++ exception or longjmp(), skips afterHandler(), so the counter stays non-zero and every guarded entry point refuses from then on, XML_ParserFree() included. Upstream accepts the resulting leak in place of a use-after-free and provides no way to clear the counter - CVE-2026-56131 - CVE-2026-50219 - CVE-2026-56412 * SECURITY UPDATE: Quadratic runtime when detecting duplicate default attributes, allowing denial of service through a crafted DTD (libexpat before 2.8.1) - debian/patches/CVE-2026-45186.patch: add ELEMENT_TYPE.defaultAttsNames and resolve default-attribute collisions through a hash table lookup instead of a linear scan over defaultAtts in defineAttribute(), with matching hashTableInit()/hashTableDestroy() calls in storeAtts(), getElementType(), dtdCopy(), dtdReset() and dtdDestroy() in expat/lib/xmlparse.c. The trade-off, upstream's as well, is one hash table per element type: a constant extra amount of memory and setup work per element type and per tag, linear in document size, in exchange for removing the quadratic term - CVE-2026-45186 * SECURITY UPDATE: Integer overflow when reallocating the tag name conversion buffer (libexpat before 2.7.4) - debian/patches/CVE-2026-25210.patch: reject a doubling that would overflow before it happens (SIZE_MAX / 2 pre-check) and widen doContent()'s bufSize from int to size_t in expat/lib/xmlparse.c. Also carries the storeRawNames() half of upstream commit 25ec4f1b, which widens that function's bufSize and nameLen to size_t. Upstream released 25ec4f1b in 2.7.2, ahead of this fix in 2.7.4, and it is a prerequisite rather than cosmetics: once tag->buf is allowed past INT_MAX bytes, the (int) narrowing of convLen in doContent() can store a negative tag->name.strLen, and storeRawNames() would then compute a negative int bufSize, skip its reallocation and memcpy() below the buffer. Widened, the same value becomes a huge size_t, the reallocation fails and the function returns XML_FALSE, which is how upstream 2.7.4 behaves - CVE-2026-25210 * SECURITY UPDATE: Integer overflow in doProlog related to storeEntityValue and entity textLen (libexpat before 2.8.2) - debian/patches/CVE-2026-56407.patch: cap the entity value pool length against INT_MAX before assigning m_declEntity->textLen in expat/lib/xmlparse.c. The second hunk of upstream commit 30c2fc17 is omitted because it targets storeSelfEntityValue(), which arrived in expat 2.6.0 and does not exist here - CVE-2026-56407 * SECURITY UPDATE: Integer overflow in copyString (libexpat before 2.8.2) - debian/patches/CVE-2026-56408.patch: reject charsRequired > SIZE_MAX / sizeof(XML_Char) before the allocation in copyString() in expat/lib/xmlparse.c. This is upstream parity hardening rather than a live fix on 2.2.10: charsRequired is a size_t holding the length of the application-supplied encoding name rather than of document content, so tripping the guard would need a string larger than the address space even in the -DXML_UNICODE (buildw) library that debian/rules also builds, where sizeof(XML_Char) is 2 - CVE-2026-56408