The news of the eMudhra Intermediate CA compromise was published on October 20th, 2026. Responding to an incident like a Certificate Authority (CA) compromise at an ecosystem-scale is far from “routine”; the assumption that HTTPS is secure is baked into many aspects of Python applications and packaging. This meant it was critical to mount a response that was both comprehensive and customized to each affected project and service, ranging from the Python language, pip, and the Python Package Index (PyPI).
This is where security staffing at the Python Software Foundation made a difference for Python. Staffing meant that Seth Larson, the Security Developer-in-Residence, was on standby able to respond and begin work on the issue immediately. Pre-existing relationships with affected project maintainers afforded plenty of trust, and the work was completed in a way that respected the time of volunteer maintainers for affected packages by reaching out proactively with clear next steps. Thanks to Alpha-Omega for funding the Security Developer-in-Residence position at the Python Software Foundation.
The incident was mitigated across multiple components within two days. Thanks to the work of their respective maintainers: fixes were made available for certifi, Python, pip, uv, sigstore, virtualenv, conda, pixi, manylinux, gh-action-pypi-publish, and many other projects. Vulnerable versions of certifi, pip, and sigstore were patched across all projects and services that the Python Software Foundation stewards, including PyPI, Python’s release process and build bots, and python.org. Containers have been rebuilt with the correct set of certificates.
Advisories, CVE records, banners, and discussion threads were created to alert the community about the work necessary to mitigate this incident and to be a location where relevant discussions and questions were answered by experts. Subscribe to the security-announce mailing list for future advisories about Python, pip, and other exceptional circumstances like this incident. Information about which projects are affected is available on discuss.python.org and around the web for more projects.
How did this incident affect Python as an ecosystem?
This section details the current situation of multiple Python projects. An aspect of positive security culture is “blameless post-portems”, we can only improve the future and the best way to do this is to show up and support the projects and maintainers that you depend on. Please note that all decisions below have historical context and sound reasons for being: Python is about the same age as TLS and is much older than the expectation that your system has up-to-date and secure CA certificate bundles.
The key component requiring a prompt response to the incident from the Python ecosystem is “certifi” and the advisory GHSA-6q48-6c7w-9gw2. Certifi is a repackaging of Mozilla’s CA bundle as a Python package and used by many popular projects including pip and requests. The package only includes root CAs, not intermediates, and therefore needed to remove the root CA from the CA bundle (“emSign Root TLS CA - G3”) to distrust all the impacted intermediate certificates.
Keeping a long story short: certifi is a critical dependency for being able to bootstrap a Python virtual environment into being able to install packages from PyPI. pip bundles its dependencies which includes “Requests” which depends on certifi. Python bundles pip so new virtual environments always contain pip through a mechanism called “ensurepip”.
This arrangement put all three of these components, Python, pip, and certifi, in the critical path for permanently remediating this incident as a user through software updates. There also isn’t an easy answer for older versions of Python which would permanently contain an older version of pip due to compatibility concerns. To address this concern, Python has added a “last-resort” denylist to reject the compromised intermediate certificates during a TLS handshake, fixed versions and more information tracked via CVE-2026-115557 which has been backported to older versions of Python.
What happens next?
We’re continuing our efforts to alert users through advisories and CVE and using banners on the PyPI and discuss.python.org and will be closely monitoring the uptake of patched versions of “certifi” across the ecosystem. The immediate, synchronous response has concluded, now we turn to what should be prioritized so a future incident like a CA compromise might not require as urgent a response from volunteer maintainers.
Right from the beginning of the incident it was identified that TLS handshakes made by browsers were secure, but tools like pip, git, uv weren’t secure. Why is this? Browsers were able to secure their certificate stores quickly and without requiring a software update by using Certificate Revocation Lists (CRL). CRLs allow providers of CAs to provide information to verifiers outside of the software update process, such as when certain certificates should no longer be used due to revocation or compromise.
These technologies may be integrated into Python in the future to provide a quicker and robust response to future incidents involving CA certificates and allow distributions to configure these facilities system-wide. One potential project to watch is upki, which has already been adopted by Ubuntu, provides certificate revocation functionality similar to that of browsers on platforms which previously did not offer such facilities.
