Upgrade bundled Expat to 2.8.2 (e.g. for the fix to CVE-2026-56132 and 12 others)

@StanFromIreland

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.h
lib/memory_sanitizer.h
lib/xcsinc.c

Related: #149698 (predecessor for Expat 2.8.1)

CC @StanFromIreland

Linked PRs

@hartwork

Hi @hartwork @StanFromIreland

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.

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.

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.

Should this be added to xmltok_impl.c upstream then?

#ifdef __clang__
#pragma clang diagnostic ignored "-Wunreachable-code-fallthrough"
#endif

@cdce8p

@cdce8p I have no interest in adding things like that to the Expat code base.

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

@StanFromIreland

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-fallthrough here:

cpython/Makefile.pre.in

Lines 1451 to 1452 in 1fece44

    
           Modules/expat/xmltok.o: $(srcdir)/Modules/expat/xmltok.c $(LIBEXPAT_HEADERS) $(PYTHON_HEADERS) 
        
           	$(CC) -c $(LIBEXPAT_CFLAGS) -o $@ $(srcdir)/Modules/expat/xmltok.c

@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 -pedantic with -Werror and that -Wunreachable-code-fallthrough is beyond that. The goal of libexpat is to fix bugs, not to address warnings beyond -Wextra that 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 -pedantic with -Werror and that -Wunreachable-code-fallthrough is beyond that.

To be fair, AFAIK CPython only enables -Wunreachable-code explicitly. 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.

cpython/Makefile.pre.in

Lines 1518 to 1519 in 701a7c5

    
           Modules/_hacl/Hacl_Streaming_HMAC.o: $(srcdir)/Modules/_hacl/Hacl_Streaming_HMAC.c $(LIBHACL_HMAC_HEADERS) 
        
           	$(CC) -Wno-unused-variable -c $(LIBHACL_CFLAGS) -o $@ $(srcdir)/Modules/_hacl/Hacl_Streaming_HMAC.c

[3.13] gh-152216: Update bundled expat to 2.8.2 (GH-152234) (#154747)

[3.12] gh-152216: Update bundled expat to 2.8.2 (GH-152234) (GH-154747)…

[3.11] gh-152216: Update bundled expat to 2.8.2 (GH-152234) (#155576)

[3.10] gh-152216: Update bundled expat to 2.8.2 (GH-152234) (#155577)

Navigation Menu

Repository navigation

Upgrade bundled Expat to 2.8.2 (e.g. for the fix to CVE-2026-56132 and 12 others) #152216

Linked PRs

13 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

	Modules/expat/xmltok.o: $(srcdir)/Modules/expat/xmltok.c $(LIBEXPAT_HEADERS) $(PYTHON_HEADERS)
	$(CC) -c $(LIBEXPAT_CFLAGS) -o $@ $(srcdir)/Modules/expat/xmltok.c

	Modules/_hacl/Hacl_Streaming_HMAC.o: $(srcdir)/Modules/_hacl/Hacl_Streaming_HMAC.c $(LIBHACL_HMAC_HEADERS)
	$(CC) -Wno-unused-variable -c $(LIBHACL_CFLAGS) -o $@ $(srcdir)/Modules/_hacl/Hacl_Streaming_HMAC.c

Upgrade bundled Expat to 2.8.2 (e.g. for the fix to CVE-2026-56132 and 12 others) #152216

Description

Linked PRs

Activity

zainnadeem786 commented on Jun 25, 2026

StanFromIreland commented on Jun 25, 2026

13 remaining items

neek78 commented on Jul 13, 2026

cdce8p commented on Jul 13, 2026

hartwork commented on Jul 13, 2026

neek78 commented on Jul 13, 2026

cdce8p commented on Jul 13, 2026

StanFromIreland commented on Jul 13, 2026

hartwork commented on Jul 13, 2026

cdce8p commented on Jul 13, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions