Update bundled pip to 26.0.1

[darklight3it]

Python 3.10's bundled pip (23.0.1) and setuptools (79.0.1) contain 5 known security vulnerabilities (CVEs). This is not a problem for the majority of users that can update those dependencies manually but it definitely is for users in managed environments like AWS Lambda.

CVE ID	Component	Severity	Link
CVE-2023-5752	pip	Medium	https://nvd.nist.gov/vuln/detail/CVE-2023-5752
CVE-2025-8869	pip	Moderate	https://ubuntu.com/security/CVE-2025-8869
CVE-2026-1703	pip	Low	https://nvd.nist.gov/vuln/detail/CVE-2026-1703
CVE-2024-23949	jaraco-context (setuptools)	High	https://ubuntu.com/security/CVE-2024-23949
CVE-2026-24049	wheel (setuptools)	High	https://www.thehackerwire.com/vulnerability/CVE-2026-24049/

I created a CR for that.

I know it's a big bump on a non execution context but a lot of users need this. I also propose to make a similar bump in all the other affected versions.

Python 3.11 - both pip and setuptools
Python 3.12 - both pip and setuptools
Python 3.13 - only pip
Python 3.14 - only pip

Linked PRs

• [3.10] gh-144538: Upgrade pip to 26.0.1 and setuptools to 80.10.2 (GH-144538) #144539

[bedevere-app]

GH-144539 is a backport of this pull request to the 3.10 branch.

[hugovk]

Right now we have:

Python	pip	CVE-2023-5752	CVE-2025-8869	CVE-2026-1703
3.10	23.0.1	not patched	not patched	not patched
3.11	24.0	patched	not patched	not patched
3.12	25.0.1	patched	not patched	not patched
3.13	25.3	patched	patched	not patched
3.14	25.3	patched	patched	not patched
3.15	25.3	patched	patched	not patched

But note we usually don't update wheels in security releases (currently 3.10-3.12) because they're source-only releases. See for example #131860 (comment).

Similarly, the setuptools change only affects security branches.

[darklight3it]

Hello @hugovk ,

thanks for your help. However, I think that .whl file should be updated in security releases. As I said in my previous message there are users that can't update those libraries themselves using

python -m ensurepip

this cause a lot of confusion because they are expecting a supported python runtime free of CVEs, and there is no way for them to fix CICDs except from creating continuous exceptions.

Besides that I was thinking the community decided to allow for this kind of changes, we had one just closed a couple months ago:

#135374

[hugovk]

In the end, it's up to the relevant release managers for those releases.

There was a suggestion (#131860 (comment)) to remove the wheels from security branches so automated security scanners don't trigger.

Security releases are source-only. Which redistributor provides your Python 3.10? Are they currently supplying latest 3.10.19 or something older? Have you asked if they can patch their builds?

Also, I recommend evaluating your risk to each of these and configuring your security scanner. Are you pip installing from Mercurial? Or can you upgrade to a bugfix version of Python? AWS Lambda has all of 3.10-3.14. And I think there are ways to upgrade pip in Lambda.

[edmorley]

we usually don't update wheels in security releases (currently 3.10-3.12) because they're source-only releases

There was a suggestion (#131860 (comment)) to remove the wheels from security branches so automated security scanners don't trigger.

To me a "source only" release means "we don't ship end user binaries of the compiled source, only the source code". ie: Only that end users will need to compile from source, rather than anything more.

IMO it shouldn't mean "end users also need to unbundle and or fix the source tree by adding wheels back before it will even work"? Yes for Linux distributions that unbundle they won't be using the wheels, but there are lots of other projects that build from source that don't unbundle, and don't want to be in the business of maintaining patchsets.

For example the official Docker Hub Python images use the wheels in the source tree across all versions, even those that are "source only" Python versions:
https://github.com/docker-library/python

Plus we do the same for the Python binaries compiled for Heroku, and I'm presuming similar for say the Python binaries compiled for other platforms like GitHub Actions etc.

I totally understand not wanting to backport breaking pip/setuptools changes to older Python major versions (if that was the reason, then I'm fine with wontfixing the backports if the risk is deemed too high). But if so, then I think "we don't want to backport breaking changes" should be the quoted reason (rather than "source only"), plus wheels shouldn't be removed from the source tree otherwise it will break the compile-from-source builds (and be a different kind of breaking change).

[hugovk]

Yep, risks from breaking changes was the reason why the aforementioned Setuptools bump was only to 79.0.1 and not 80.x: #135374 (comment).

[sethmlarson]

Please note that CVE-2026-1703 is rated as Low (CVSSv4: 2.0): https://www.cve.org/CVERecord?id=CVE-2026-1703 and does not impact the ability of pip to be upgraded securely. Users that are using pip without the patch are able to upgrade just fine and resolve the issue, regardless of the version packaged with CPython.

[notatallshaw]

FYI, CVE-2025-8869 is fixed by CPython >=3.9.17, >=3.10.12, >=3.11.4, and >=3.12 as it is a specific instance of the CPython security issue CVE-2007-4559, so there is no security reason to back port it. Perhaps CPython should remove vendored libraries for source only releases?

Regardless, I recommend this issue be re-titled as it appears to be a discussion of CPython's vendoring policy. If I have time later today I will make a new issue and PR to bundle pip 26.0.1.