Python's release team has issued expedited updates across five supported release lines to reject compromised eMudhra intermediate certificate authority keys. The October 26, 2026 announcement identifies Python 3.15.2, 3.14.10, 3.13.18, 3.12.16 and 3.11.18 as carrying the protection in the ssl module.
For application teams, this is a coordinated environment update. The interpreter, packaging tools, existing virtual environments and container images can have separate update paths. A new version installed on a developer's laptop does not establish the state of the runtime used by CI or production.
Which releases are available
Python's source-release index dates all five releases to October 25. That is the release date; October 26 is the date of the combined announcement.
| Python line | Release containing the fix | Upstream 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 security release |
| 3.12 | 3.12.16 | Source-only security release |
| 3.11 | 3.11.18 | Source-only security release |
The source-only designation describes what the Python project supplies. Teams using a distribution, managed runtime or container image should check that provider's update rather than assume an upstream release has already reached their environment.
What the interpreter protection covers
The Python 3.15.2 release notes describe the block as a last line of defense against the compromised keys. They also state that ordinary uses of pip on the patched runtime, including upgrading pip itself, are protected against attacks based on those keys even before pip has been updated.
That is a specific protection. It does not establish that an environment has current dependencies, that every TLS client uses this interpreter, or that the application has been tested on the new release. Treat the security fix and application compatibility as separate questions.
Update the environments that actually run the work
The Python security team's incident guidance also calls for updating packaging tools and certificate bundles. It lists pip 26.2.2, certifi 2026.10.19 and uv 0.13.4 among the minimum versions for its recommendations, and addresses additional tools separately. It asks users to update existing virtual environments and rebuild container images without reusing cached layers so that current certificates are fetched.
Use that guidance to prepare an inventory of the environments you own:
- Record the interpreter and packaging tools used by each application, CI job and image build.
- Select the applicable upstream or provider update and verify what was actually installed.
- Run the application's meaningful compatibility checks, including affected network integrations where applicable.
- Preserve the resulting version and image records so the deployed environment can be compared with the one tested.
For the upgrade procedure, consult the current security notice, including its instructions for securely bootstrapping packaging tools. Disabling certificate verification is not an appropriate shortcut.
Our dependency-update workflow explains how to connect an upstream change to application-specific checks and recovery planning. In this case, a rollback decision must also account for the security exposure it could restore.
This report is based on release documentation and the security team's guidance checked on October 28. We have not performed an upgrade or tested the certificate mitigation in a running application.
