Python 3.15.1, 3.14.9 and 3.13.17 came out on 21 October 2026 as rushed security releases, and the fix inside them isn’t really about Python. It’s about pip, and specifically about a certificate authority whose private keys turned out to be small enough to guess.
The catch: installing the new Python does nothing for the virtual environments you already have. Those need their own update.
Key takeaways
- All three releases bundle pip 26.2.2, which carries certifi 2026.10.19. That certifi release removes the emSign ECC Root CA – G3 from Python’s trusted list.
- Eight eMudhra intermediate certificates had weak private keys. Anyone could work them out from the public certificates and forge a certificate for any website.
- pip always trusts its own bundled certificates, so an old pip stays exposed even if your operating system has been patched.
- Existing environments need pip 26.2.2 or later, and uv 0.13.4 or later.
- 3.15.1 also carries about 330 bug fixes and a macOS fix for a tkinter hang.
Why did Python 3.15.1 ship as an emergency release?
The trigger was eMudhra, an Indian certificate authority (CA), meaning a company that browsers and operating systems trust to vouch that a website is who it says it is. According to The Hacker News, a researcher credited only as “Wayne” reported to browser root programs on 17 October 2026 that eight of eMudhra’s intermediate keys were broken. As proof, they signed the message “We have a problem here – Wayne” with each one.
The keys weren’t stolen. They were generated badly. Security researcher Scott Helme recovered all eight from the public certificates in under a second, and one of them was simply the number 4. CPython core developer Christian Heimes summed it up on the Python forum: every one of the eight keys was a number below 256.
Think of it as a bank vault whose combination is printed on the door. Whoever holds such a key can issue a valid-looking certificate for any domain and sit in the middle of your encrypted traffic. eMudhra says only one of the eight intermediates was used in production and none had issued certificates to websites. The keys were still trusted, though, and that’s what counts.
Browsers moved first. Chrome blocked the six web-facing intermediates on the evening of 17 October and Firefox followed that night. Apple acted on 19 October and Microsoft on 20 October. Cloudflare’s write-up explains why browsers had it easy: they ship one app with a fast way to revoke certificates. Every other tool that carries its own certificate list has to ship a release.
Why isn’t patching your operating system enough for pip?
This is the part most people miss. In the Python Software Foundation advisory, Heimes explains that pip “always loads the CA certificates from its vendored certifi in addition to the system trust store”, and you can’t switch that off.
Settings like REQUESTS_CA_BUNDLE or --cert only add certificates. They never take one away. So a fully patched Mac or Linux box with pip 26.2.1 still trusts the bad keys whenever pip downloads a package. In Heimes’s words: “Updating pip is the only reliable fix.”
Python 3.15.1, 3.14.9 and 3.13.17 compared
| Release | Series status | What’s in it |
|---|---|---|
| 3.15.1 | Latest feature series, first bugfix release | pip 26.2.2, about 330 fixes from 117 contributors, macOS Tk fix |
| 3.14.9 | Ninth maintenance release | pip 26.2.2, macOS Tk fix, a reminder that Windows is moving to the new install manager |
| 3.13.17 | Security-only (only just) | pip 26.2.2 and certifi 2026.10.19, plus full installers as a one-off |
The 3.13 release is the unusual one. Security-only versions normally ship as source code with no pip updates. The release team, Hugo van Kemenade, Thomas Wouters, Ned Deily and Steve Dower, wrote on the Python blog that a special release with installers “seemed prudent” because 3.13 has only just entered that phase.
One bonus fix: the macOS installers use a pre-release of Tk, which fixes a possible hang on macOS 27.0 in tkinter apps such as IDLE.
How to fix your existing environments
A new Python only helps environments you create after installing it. Every virtual environment, container and CI image you already have keeps the pip it was built with. These are the minimum safe versions from the advisory:
- pip: 26.2.2
- certifi: 2026.10.19
- uv: 0.13.4 (if you missed it, here’s our look at uv 0.13.3’s export slowdown fix)
- sigstore: 4.5.1
- pixi: 0.82.1
There’s a chicken-and-egg problem. Upgrading pip with an old pip means trusting the old certificate list during the download. Seth Larson, the PSF’s security developer in residence, suggests installing the pip 26.2.2 wheel from a direct URL pinned to its SHA-256 checksum, a fingerprint of the file, so any tampered file gets rejected. The exact command is in the advisory. uv users can run UV_SYSTEM_CERTS=true uv self update to lean on the already-patched system store.
Containers are easy to forget. Forum users noted that the official Python Docker images still shipped pip 26.2.1 when the advisory went up. One team set PIP_CERT=/etc/ssl/certs/ca-certificates.crt as a stopgap. Debian is a special case: it patches pip to use the system store, so its ca-certificates update covers it.
My take: this is the second reminder in a short time that vendored dependencies are a patching blind spot. As we wrote about the NetScaler flaw, shipping a patch and being protected are not the same thing.
What happens next
CPython developers are discussing a defence-in-depth change (issue 160040, pull request gh-160042) that would block the eight bad keys by their public-key fingerprint directly in the ssl module, copying an approach Go has already taken. A fix to ensurepip, the module that installs pip into new environments, has been merged, and backports are open.
On eMudhra’s side, the company blames a flaw in its 30 April 2025 key ceremony and says its investigation is ongoing. Chrome is also reviewing eMudhra’s other trusted root. Expect more downstream releases from Linux distributions, Docker images and CI tools in the coming weeks.
FAQ
Do I need Python 3.15.1 if I already upgraded pip?
For the certificate issue, no. pip 26.2.2 or later in each environment is what protects you. Python 3.15.1 still brings about 330 bug fixes, so it’s worth installing anyway.
Was anyone attacked using the eMudhra keys?
No public reports of abuse had appeared by 21 October 2026, and Cloudflare reported no active exploitation of its services. Because the keys could be computed by anyone, they still had to be distrusted everywhere.
Does the requests library need an update too?
requests uses the separate certifi package installed in your environment, so upgrade certifi to 2026.10.19 or later wherever your code makes HTTPS calls.
Your next step: run pip --version in each project, CI image and Dockerfile you own, and anything below 26.2.2 gets upgraded.
Leave a comment