Repository navigation
Upgrade bundled Expat to 2.8.2 (e.g. for the fix to CVE-2026-56132 and 12 others) #152216
Description
Activity
I can take a look at this and prepare a focused PR if no one else is already working on it.
I checked the previous Expat 2.8.1 update pattern from gh-149698 / gh-149699 and started comparing the bundled 2.8.1 copy with upstream 2.8.2.
From the initial investigation, this looks like a focused vendoring update involving the refreshed Expat sources, the new upstream files mentioned here, SBOM metadata, and a Security NEWS entry while preserving CPython’s local Expat configuration and symbol namespacing.
I’ll validate the update with the focused XML/pyexpat test suite before opening a PR.
I've assigned myself this, please check such things in the future.
Reacted by Zain Nadeem- changed the title
[-][security] Please upgrade bundled Expat to 2.8.2 (e.g. for the fix to CVE-2026-56132 and 12 others)[/-][+]Upgrade bundled Expat to 2.8.2 (e.g. for the fix to CVE-2026-56132 and 12 others)[/+]on Jun 25, 2026 13 remaining items
Ok, it's because cpython's non-debug build turns on -Wunreachable-code - this results in warnings from both AppleClang and clang. It would be possible to disable -Wunreachable-code-fallthrough specifically.
Reacted by Marc MuellerOk, it's because cpython's non-debug build turns on -Wunreachable-code - this results in warnings from both AppleClang and clang. It would be possible to disable -Wunreachable-code-fallthrough specifically.
Should this be added to
xmltok_impl.cupstream then?#ifdef __clang__ #pragma clang diagnostic ignored "-Wunreachable-code-fallthrough" #endif
@cdce8p I have no interest in adding things like that to the Expat code base.
i tend to agree. Libexpat has its own buildsystem(s), which set appropriate flags for the code; Cpython takes the code, but builds it itself. I would suggest making the change in Cpython's build system for building expat somewhere.
Out of interest, are these warnings showing up in CI ?
I have no interest in adding things like that to the Expat code base.
In that case another option might be to add
-Wno-unreachable-code-fallthroughhere:
Lines 1451 to 1452 in 1fece44
@StanFromIreland Would that be acceptable?
I don't think we should be ignoring warnings, we also shouldn't be fixing them, they should be resolved upstream instead. Previously, there were several warnings which this update allowed us to remove from our ignore list.
I would like to note that Expat CI is using
-Wall -Wextra -pedanticwith-Werrorand that-Wunreachable-code-fallthroughis beyond that. The goal of libexpat is to fix bugs, not to address warnings beyond-Wextrathat do not expose actual bugs. If there is a bug to fix related to this warning, an in-depth analysis is welcome upstream.I would like to note that Expat CI is using
-Wall -Wextra -pedanticwith-Werrorand that-Wunreachable-code-fallthroughis beyond that.To be fair, AFAIK CPython only enables
-Wunreachable-codeexplicitly. While I do share the desire to get these kind of changes upstream, I can also understand the position not to include it. Anyway, I opened #153671 in case silencing it during the build is ok. There at least seems to be some precedent to doing that for other warning types.
Lines 1518 to 1519 in 701a7c5
- moved this from Todo to Done in Release and Deferred blockers 🚫
on Aug 12, 2026
Please see blog post https://blog.hartwork.org/posts/expat-2-8-2-released/ for an overview and the change log at https://github.com/libexpat/libexpat/blob/R_2_8_2/expat/Changes for details. Affects all alive branches of Python. Thank you!
PS: Note that this release comes with three new files files to be bundled:
lib/fallthrough.hlib/memory_sanitizer.hlib/xcsinc.cRelated: #149698 (predecessor for Expat 2.8.1)
CC @StanFromIreland
Linked PRs