Information for Python users regarding eMudhra / emSign CA certificate security incident

A security incident affecting eMudhra intermediate certificates has required removing the emSign root CA certificate from CA bundles such as “ certifi ”. It’s important to immediately upgrade the software packages below to at least the versions specified and rebuild container images to fetch the latest system certificates. Failure to do so could result in monster-in-the-middle (MITM) attacks against TLS clients, including python.org and pypi.org .

certifi 2026.10.19 (1)

(1): Advisory mentions 2026.10.18, but 2026.10.19 is recommended for compatibility with unaffected emSign root certificates.

For all existing virtual environments on your system, please upgrade pip and uv to the latest versions.

Note that the certifi CA bundle is included in the macOS installation of Python from python.org . To upgrade certificates for this installation and pip itself, run the command below like so:

This topic will be updated as more information is made available.

Just to stress one point: users must update pip to >= 26.2.2.

pip always loads the CA certificates from its vendored certifi in addition to the system trust store, and there is no supported way to disable this. REQUESTS_CA_BUNDLE / --cert only add CAs; truststore is used “in addition to certifi” by design. As a result, any pip < 26.2.2 will keep trusting the compromised intermediate CAs regardless of the system trust store, so distrusting them at the OS level is not enough.

uv users can block the bad certs in their system trust store and UV_SYSTEM_CERTS=true . That does not work with pip . Updating pip is the only reliable fix. See Switch to using truststore only by default (currently mixed certifi + truststore) · Issue #14374 · pypa/pip · GitHub

PS: The ‘security incident’ is a bad private key. An elliptic key with private key value d=4 is not secure… All 8 eMudhra CAs had private keys with d < 256 .

Is there advice on how to securely update Pip without running an older version of Pip that’s vulnerable to MitM attacks?

Yes, browsers should all updated their certificate stores and certificate revocation lists so are secure to use. From here you can confirm that the checksums for pip and uv are correct and use these values to install securely, regardless of a MITM attack against certifi-based verifiers. For example, below is the command to install using a “Direct URL” with a SHA256 checksum:

From this secure installation you can bootstrap into a secure installation of certifi, uv, or other dependencies.

Is anything needed to update the pip shipped with Python as part of the ensurepip module? Obviously, upgrading CPython is the ultimate fix, but until a new CPython release, what should people do?

Upgrading pip after creating any new venv is the workaround, but that’s probably easy to forget.

GH-159910 is merged and has backports open, with plans to cut security releases as soon as reasonably possible. If an enterprising user would like to patch their own current installations, it’s a relatively simple matter of placing the new wheel in the right directory and making a one character change to .../ensurepip/__init__.py .

For those of us with a bunch of virtualenv’s this can be a lot of work. I’ve repurposed a script I had for virtualenv cleanups to do this for me.

This only finds regular virtualenv’s under your directory. It doesn’t find system installations or app-embedded environments.

This doesn’t cover homebrew installs or installs from the official python.org installers. I can probably extend it to cover those but that’s not my usecase so it’s not high priority for me.

It doesn’t update python environments older than 3.10 since pip 26.2.2 doesn’t support those. I haven’t looked into this but I suspect those are not at risk?

It doesn’t update dependency pins or lockfiles. There are too many variations for me to cover those. But at least you get a list of virtualenvs so you can handle that manually without hunting for them.

It doesn’t rebuild containers that might still have this issue. You’re on your own in that case. Again, maybe the list will help there.

The script will use ‘fd’ if it’s found on your system. ‘fd’ is much faster than ‘find’ so I suggest installing it first but this will work with ‘find’ too.

Invoke it like so to show the list of found virtualenvs:

Invoke it like so to update pip in each:

Similarly for uv, the easiest way to bootstrap to a newer version of uv without using the embedded CA bundle:

That will use the host’s root program (CA bundle) and verifier rather than the embedded root program.

(Like the pip solution, this assumes that your system certificates/verifier are already updated, which they should be for macOS and Windows. For Linux, it will depend on your distribution and whether you’ve updated ca-certificates or similar.)