Python 3.15.2 and four other releases block the compromised eMudhra keys in ssl

Five CPython releases shipped together on October 26, 2026: 3.15.2, 3.14.10, 3.13.18, 3.12.16 and 3.11.18. They are expedited security releases, and the headline fix is that the ssl module now rejects the compromised eMudhra (emSign) intermediate CA keys on its own, even if the trust store you use still trusts them.

01The block moves into the runtime

A compromised intermediate CA lets whoever holds its keys issue a valid certificate for any domain. Until now, Python's defence depended on every trust store being patched: the system CA bundle, certifi, or whatever a given tool ships. If one piece of the chain lagged behind, the client kept accepting forged certificates.

With these releases (CVE-2026-115557, gh-160040), ssl itself blocks those keys "as a last resort". The release team spells it out for pip: normal pip usage, including upgrading pip, is now safe from attacks built on those keys even if pip hasn't been updated yet. The same logic applies to any HTTP client that verifies through ssl: a stale certifi in a forgotten image stops being a hole once the interpreter is current.

What it doesn't cover: software that doesn't verify through CPython's ssl, and interpreters you don't upgrade. The second part is where the work is, because the Python running in production is rarely the one on your laptop.

02Two more fixes in the same batch

All five releases also include:

• CVE-2026-114583 (gh-160097): tarfile.tar_filter now rejects links that replace the destination. If you extract tarballs from outside sources with the tar filter (build artefacts, backups, user uploads), this is the fix that matters to you.
• gh-160300: http.cookiejar rejects cookies with a negative version.

The 3.13, 3.12 and 3.11 branches also pick up what 3.15.1 and 3.14.9 already had: Expat 2.9.0 (CVE-2026-77214 and CVE-2026-102633), no longer reading mimetypes.knownfiles by default on Windows (CVE-2024-3220), and a header refolding edge case (gh-87720). 3.13.18 and 3.12.16 also fix a race condition in tempfile.TemporaryDirectory cleanup.

03How to upgrade, branch by branch

3.15 and 3.14 have installers on python.org. For the other three branches you rely on your distro, your base image, or building from source. With the usual version managers:

# uv: install and pin the version for the project
uv python install 3.15.2
uv python pin 3.15.2

# pyenv: refresh the version list and build
pyenv update
pyenv install 3.12.16

In containers, pin the full version in FROM (for example python:3.15.2-slim) instead of python:3.15, and rebuild: an image you already built doesn't change just because the floating tag moved.

04Checklist before it reaches production

• Inventory the interpreters you actually run: base images, serverless runtimes, CI agents and VMs on the system Python. What runs in production is not what pyproject.toml says.
• Check the version inside each artefact, not on the host: python -c "import sys; print(sys.version)" in the built container.
• Review any extractall with filter="tar" or a custom filter over third-party tarballs, and run the tests that extract archives.
• Watch the logs after rollout for new TLS verification errors. If any of your services relied on a certificate issued by those intermediates, it will start failing; the answer is to replace the certificate, not to turn verification off.
• On 3.13, 3.12 and 3.11, confirm your distro package or base image is already on 3.13.18, 3.12.16 or 3.11.18, or at least carries the gh-160040 patch.

05Sources

• Python 3.15.2, 3.14.10, 3.13.18, 3.12.16 and 3.11.18 are out — Python Insider, 2026-10-26
• Python 3.15.2 — python.org, 2026-10-26