* SECURITY UPDATE: Out-of-bounds read and resultant infinite loop because low surrogates were treated the same as high surrogates in the *_toUtf16 functions (libexpat before 2.8.3) - debian/patches/CVE-2026-72522.patch: mask the high byte of the trailing code unit with 0xFC instead of 0xF8 in the DEFINE_UTF16_TO_UTF16(E) macro in expat/lib/xmltok.c, so the guard that avoids splitting a surrogate pair across two conversion calls matches only genuine high surrogates (0xD800-0xDBFF) and no longer accepts low surrogates (0xDC00-0xDFFF). On a buffer ending in a lone low surrogate the old test reported XML_CONVERT_INPUT_INCOMPLETE without consuming any input, so the caller retried while reading two bytes past the intended limit. One edit covers both little2_toUtf16 and big2_toUtf16. Reachable in the libexpatw (-DXML_UNICODE) build, which is where xmlparse.c maps XmlConvert to XmlUtf16Convert. - CVE-2026-72522 * SECURITY UPDATE: Use-after-free because handler call depth tracking was missing for custom encoding callbacks (libexpat before 2.8.4) - debian/patches/CVE-2026-76957.patch: route the application's unknown-encoding convert and release callbacks through the new callUnknownEncodingConvert() and callUnknownEncodingRelease() wrappers in expat/lib/xmlparse.c, storing the application callback in the new m_unknownEncodingConvert member and passing the parser itself as the encoding's user data. handleUnknownEncoding previously handed both callbacks out unwrapped, so m_handlerCallDepth stayed at zero while they ran and the reentrancy guard that rejects XML_ParserFree, XML_GetBuffer and XML_ResumeParser from inside a handler did not fire for them. - CVE-2026-76957