IT

Python 3.15.2 and Security Releases Block eMudhra CA Keys

Python 3.15.2, 3.14.10, 3.13.18, 3.12.16 and 3.11.18 block compromised eMudhra CA keys in ssl and fix tarfile issues. ',

27 October 2026  ·  4 min read  ·  Anand

Python 3.15.2 and Security Releases Block eMudhra CA Keys

The Python release team has published five expedited releases at once: Python 3.15.2, 3.14.10, 3.13.18, 3.12.16 and 3.11.18. The main reason is the eMudhra certificate authority incident, in which intermediate CA private keys were compromised. These versions make Python’s ssl module refuse those keys as a last line of defence. The releases also include other security fixes, so if you run Python applications, scripts or services on your servers, plan to upgrade.

What Changed

eMudhra intermediate keys are now blocked

The headline fix is tracked as CVE-2026-115557. The ssl module now distrusts the compromised eMudhra intermediate CA keys. That means a Python client will reject a TLS certificate chain that depends on them, even when the system trust store or a bundled CA file would otherwise accept it. This matters because Python code makes outbound HTTPS calls in many places: API clients, webhooks, monitoring checks, backup uploads and deployment tooling.

The Python team also says that normal pip use, including upgrading pip itself, is safe from attacks that use these keys even if pip has not been updated. So you can use pip to manage packages as usual while you plan the interpreter upgrade.

Other fixes in all five releases

  • CVE-2026-114583: tarfile.tar_filter now rejects links that replace the destination. If your code extracts uploaded or downloaded archives, this one matters.
  • http.cookiejar now rejects cookies with a negative version.

Extra fixes for the older branches

Python 3.13.18, 3.12.16 and 3.11.18 also pick up fixes that 3.15.1 and 3.14.9 already had:

  • Bundled Expat updated to 2.9.0, fixing CVE-2026-77214 and CVE-2026-102633
  • CVE-2024-3220: on Windows, mimetypes.knownfiles is no longer read by default
  • A fix for an edge case in email header refolding and quoting

Python 3.13.18 and 3.12.16 also fix a race condition in the cleanup of tempfile.TemporaryDirectory.

Which Version Do You Need?

Branch Patched release Distribution
3.15 3.15.2 Source and binary installers
3.14 3.14.10 Source and binary installers
3.13 3.13.18 Source only
3.12 3.12.16 Source only
3.11 3.11.18 Source only

Python.org only publishes source tarballs for 3.13, 3.12 and 3.11. If you rely on the official Windows or macOS installers, you need to be on 3.14 or 3.15 to get a ready-made patched build.

How to Upgrade

Start by finding out which interpreters you actually run. Servers often have more than one: the system Python, a pyenv or uv-managed version, and whatever is baked into your container images.

# Check the interpreter your app uses
python3 --version
/path/to/venv/bin/python --version

# List versions installed with pyenv or uv
pyenv versions
uv python list --only-installed

System Python from your distribution

Distribution packages are built and patched by the vendor, often by backporting fixes, so the version number may not match upstream. Apply your normal updates and read your vendor’s security notices. It is also a good moment to update the ca-certificates package.

# Debian / Ubuntu
sudo apt update && sudo apt upgrade

# RHEL / Rocky / AlmaLinux
sudo dnf upgrade --refresh

pyenv, uv and source builds

# pyenv
pyenv install 3.14.10

# uv
uv python install 3.14.10

After you install a new interpreter, rebuild virtual environments that were created from the old one, then restart the services that use them. A virtualenv keeps pointing at the interpreter it was created with.

Containers

Rebuild images with docker build --pull so the base image is fetched fresh, and confirm the Python version inside the new image before you deploy. A long-running container keeps the old interpreter until it is replaced.

Quick Checklist

  1. List every Python interpreter on each server and in each image.
  2. Upgrade to the patched release for each branch, or apply the vendor package update.
  3. Recreate virtual environments and restart application services and workers.
  4. Review any code that extracts tar archives from untrusted sources.
  5. If you are still on 3.11 or 3.12, start planning a move to a newer branch.

How TechProvidence Can Help

TechProvidence maintains Linux servers and application stacks for businesses, including Python runtimes, virtual environments and container images. We can audit which interpreters you run, roll out patched versions without breaking your applications, and plan upgrades away from ageing Python branches. For help, contact us.

Source: Python Insider

Running into something similar?

We look after Linux servers, control panels and virtualization for businesses every day. If an update, vulnerability or outage here affects you, we can help.