Repository navigation
Update bundled pip to 26.0.1 #144538
Description
Activity
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.
- changed the title
[-]Upgrade pip to 26.0.1 and setuptools to 80.10.2[/-][+]Update bundled pip to 26.0.1[/+]on Feb 6, 2026 Hello @hugovk ,
thanks for your help. However, I think that
.whlfile should be updated in security releases. As I said in my previous message there are users that can't update those libraries themselves usingpython -m ensurepipthis 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:
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.
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/pythonPlus 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).
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).
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.
Reacted by Hugo van KemenadeFYI, 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.
Reacted by Zachary Ware and Hugo van KemenadeWe might as well use this issue rather than a new one, otherwise we'll likely mark this as a duplicate of that and the discussion may end up there anyway 🙃
I'd like to delineate between the responsibility of the pip release manager and the CPython maintainers, the discussion in this thread is firmly for the latter, and therefore not really related to me as the pip release manager.
This may have been blurry in the past because pip release managers were generally CPython maintainers, but at least for the last few releases this hasn't been the case.
Perhaps it makes sense to move the responsibility of bundling pip into CPython to the CPython maintainers? cc @pfmoore who often handles this.
1 remaining item
Raised #144556
Reacted by Hugo van Kemenadepip has been updated to 26.0.1 for Python 3.13-3.15. The next 3.15 release is 10 February, and the next 3.13 and 3.14 are 7 April.
sorry to answer only now but I got busy during the weekend.
In the end, it's up to the relevant release managers for those releases.
Is there a clear policy about that? Something written about the older support the community agreed upon? I think this rule should be clear and unambiguous.
There was a suggestion (#131860 (comment)) to remove the wheels from security branches so automated security scanners don't trigger.
If it is possible that would be great. I don't know how the user experience will be then.
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?
The user cannot patch the runtimes, they sit on managed Lambda and AWS provides the runtime itself without allowing to run
ensurepip.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.
Users cannot easily move to new python versions and cannot change their model.
In Lambda it's only possible doing that if you are baking your own OCI image.
The user cannot patch the runtimes, they sit on managed Lambda and AWS provides the runtime itself without allowing to run
ensurepipIn this example AWS is responsible for the security of the images they are providing, and you should be filing issues with them.
AWS absolutely has the skill and engineering capability to determine which vendored projects should be included in security only releases of CPython.
I would again advise if this is a real issue that CPython remove all vendored projects from source only releases, forcing builders to make a choice about what to include.
Reacted by Hugo van Kemenade and Zachary WareI agree with @notatallshaw here, with the exception that I wouldn't necessarily agree that the bundled pip wheels need to be removed from source-only releases. Making it harder for users to build their own Python from the supplied sources, just because a large organisation like AWS isn't ensuring that their builds (from the same sources) meet their users' needs, seems like the wrong trade-off.
Furthermore, if users can't do
python -m pip install --upgrade pipto upgrade the supplied pip to the latest version, then that would suggest that in the AWS environment, pip is unusable. Which begs the question of why anyone should care about the version of pip bundled with Python in any case.If this is purely about security scanners flagging false positives, then I don't think we should worry about it. Either the scanners can be updated, or the user can acknowledge that this is a false positive and move on.
Reacted by Hugo van Kemenade and Damian ShawIn the end, it's up to the relevant release managers for those releases.
Is there a clear policy about that? Something written about the older support the community agreed upon? I think this rule should be clear and unambiguous.
Yes, https://devguide.python.org/developer-workflow/development-cycle/#security-branches says:
The only changes made to a security branch are those fixing issues exploitable by attackers such as crashes, privilege escalation and, optionally, other issues such as denial of service attacks. Any other changes are not considered a security risk and thus not backported to a security branch. You should also consider fixing hard-failing tests in open security branches since it is important to be able to run the tests successfully before releasing.
Commits to security branches are to be coordinated with the release manager for the corresponding feature version, as listed in the Status of Python versions. Merging of pull requests to security branches is restricted to release managers. Any release made from a security branch is source-only and done only when actual security fixes have been applied to the branch.
Reacted by Damian Shawthe exception that I wouldn't necessarily agree that the bundled pip wheels need to be removed from source-only releases. Making it harder for users to build their own Python from the supplied sources
If this is a real security issue it is trivial for a builder to download the pip wheel, there are no platform tags to determine or dependencies to resolve, it's a single curl, or equivalent, command.
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.
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