CVE-2026-76957 is a medium severity (4.9) use-after-free in libexpat before 2.8.4. The parser did not track handler call depth for custom encoding callbacks, so an application that calls back into the parser from them could trigger it. Upgrade to libexpat 2.8.4 or later.
What's affected
The record says libexpat before 2.8.4 is affected, with the fix in 2.8.4. The record also notes the issue is similar to CVE-2026-50219, CVE-2026-56131 and CVE-2026-56412, earlier re-entry style bugs in the same library.
The fix pull request protects the XML_Encoding convert and release callbacks with expat's existing handler re-entrancy counter, so a call back into the same parser from those callbacks is rejected just as it is from other handlers. The 2.8.4 release preparation pull request was merged on 31 August 2026.
Where sources differ. No vendor score was found beyond the record's 4.9 Medium. The record's vector is local with high complexity.
How to check if you're exposed
Find the expat in your systems. It is often bundled inside other software, so check more than one place:
pkg-config --modversion expat
python3 -c "import pyexpat; print(pyexpat.EXPAT_VERSION)"
dpkg -l libexpat1
rpm -q expat
apk info expat
Distribution packages frequently carry backported fixes under an older version string, so check your vendor's tracker for the CVE as well. Also look for vendored copies of expat inside language runtimes, browsers, PDF tools and firmware, which do not appear in package lists. Then ask a narrower question. This issue matters only to programs that supply a custom encoding callback, the XML_Encoding handlers used for unknown encodings, and call back into the parser from it. Search your own code for XML_SetUnknownEncodingHandler. A dependency scan is the quickest way to find this kind of component across many projects. Safeguard's free in-browser scan at gold.safeguard.sh/scan checks your dependencies against known CVEs, and reachability analysis helps you separate libraries your code actually calls from ones that only sit in the tree.
What to do now
- Find every copy of libexpat and note any version before 2.8.4.
- Upgrade to 2.8.4 or later, or to a distribution package that lists the fix.
- Search your code for XML_SetUnknownEncodingHandler and review what those handlers do. They should never call back into the same parser.
- Rebuild software that bundles or statically links expat.
- Record versions after the update.
Why it matters
A parser that lets a handler call back into itself has to track how deep it is, or internal state can be freed while the outer call still uses it. Expat already counted this for ordinary handlers. The record says custom encoding callbacks lacked that tracking, so a use-after-free can occur. The weakness is filed under CWE-416.
The score is modest because the vector is local and complex, and most applications never register such a callback. It is still the fourth bug in a family of re-entry problems the record lists, which tells you where fuzzing and review keep finding gaps. The record does not mark it as a CISA KEV entry.
Quick check
Do all expat users need to worry?
Mostly those whose software supplies custom encoding callbacks. Even so, upgrading to 2.8.4 is the simple fix for everyone.
What did the fix change?
It protects the encoding convert and release callbacks with the existing re-entrancy counter, per the fix pull request.
Sources
Last reviewed: 18 October 2026.
