> ## Content Index
> Fetch the complete content index at: https://globalfeed.ai/llms.txt
> Use this file to discover other available public pages before exploring further.

# eMudhra crisis rattles Python: upgrade pip and certifi now
- URL: https://globalfeed.ai/en/emudhra-crisis-rattles-python-upgrade-pip-and-certifi-now/
- Published: 2026-10-23T00:36:29.000Z
- Updated: 2026-10-23T00:36:29.000Z
- Description: The compromised keys of India-based certificate authority eMudhra hit the Python world far harder than browsers. Because pip carries its own certificate list and it cannot be turned off, old pip keeps trusting forged certificates even on an up-to-date operating system. Python core developers are ask
- Author: GlobalFeed Editor
- Tags: Python, pip, certifi, eMudhra, cybersecurity, HTTPS, x-ThePSF, x-pypi, dil-en, elle

The discovery that the private keys of eight intermediate certificates from India-based certificate authority eMudhra could be recovered by anyone is hitting Python users hardest. According to the [pinned advisory thread](https://discuss.python.org/t/information-for-python-users-regarding-emudhra-emsign-ca-certificate-security-incident/109576?ref=globalfeed.ai) that CPython core developer Seth Michael Larson opened on Python's official discussion site on October 20, Python users need to upgrade several packages immediately and rebuild container images with layer caching disabled. Otherwise tools connecting to python.org and pypi.org can remain open to man-in-the-middle (MITM) attacks. The thread drew more than 90,000 views and dozens of replies in two days.

## What happened

The private keys of eight intermediates eMudhra generated in April 2025 were far smaller numbers than they should be; one was just 4\. With these keys anyone could create fake HTTPS certificates that look valid for any site. Browsers blocked the certificates on the night of October 17, and Mozilla and Google removed trust in eMudhra's ECC root. But some of these intermediates were also cross-signed by another root, Comodo/Sectigo AAA Certificate Services, which is still present in older certificate lists. That is what caught Python tools out.

## Why Python is hit harder

Browsers and operating systems distributed their own revocation lists. In the Python world, however, many tools ship their own trusted root certificates. As Christian Heimes, a longtime contributor to Python's security work, explained in the thread, pip always loads trusted certificates from its own vendored copy of certifi, and there is no supported way to disable this. Pointing to your own certificate file does not switch the old list off. As a result, **every pip release older than 26.2.2 keeps trusting the compromised intermediates**; according to Heimes, upgrading pip is the only reliable fix.

That means someone in the middle of a pip install could pose as PyPI with a forged certificate and serve a malicious package. This is why the official thread recommends installing pip from a direct URL with a pinned checksum (hash), which ensures the right file is installed even under a MITM attack. **Copy that command and its checksum only from the official discussion thread, not from second-hand sources.**

## What to upgrade

The minimum safe versions given in the official thread and the linked security advisories:

- **certifi 2026.10.19** (the advisory says 2026.10.18; the thread recommends 2026.10.19; the advisory is rated critical)
- **pip 26.2.2**
- **uv 0.13.4** (uv's own advisory is rated high)
- **conda 26.9.4**; ca-certificates 2026.10.19 on conda-forge and 2026.10.20 on the Anaconda channel
- **pixi 0.82.1**, **sigstore 4.5.1**
- The GitHub action that uploads to PyPI, **pypi-publish 1.14.3**; the wheel builder **cibuildwheel 4.3.3**, and 4.3.4 for pip on Python 3.9
- Python releases that bundle the fixed pip: **3.15.1, 3.14.9 and 3.13.17**

The thread also gives uv users an extra option: setting UV\_SYSTEM\_CERTS=true makes uv use the operating system's certificates. pip has no such setting.

## By operating system

- **macOS (python.org installer):** According to the thread, certifi is bundled with this installation and must be upgraded separately.
- **macOS (system Python):** According to the incident page, macOS blocks the compromised certificates, but the bundled python3, curl and git check against /etc/ssl/cert.pem, which has not been updated, and the system pip uses its own outdated list.
- **Windows:** Microsoft shipped the block through automatic updates. A separate script exists for machines that do not receive them, but it is not recommended on enterprise-managed devices.
- **Linux:** Depends on the distribution's ca-certificates package; Ubuntu, Debian, Fedora, Alpine, Arch and others have shipped updates. Debian patches its own pip package to use the system certificates.

## Docker, CI and lockfiles

In the thread, a user reported that the official python:3.15-slim Docker image ships pip 26.2.1 and is therefore unsafe. Python core developers replied that these "official" images are Docker's official images rather than the Python project's, and are maintained by a separate team. Python Steering Council member Barry Warsaw wrote that the semi-official CI images update automatically to the latest releases, so Python 3.13 to 3.15 should be safe, while 3.16 is not fully safe until alpha 2 is released.

Projects that manage dependencies with lockfiles or pinned versions are not fixed automatically if they pinned an old certifi. Those using dependency cooldowns that delay new releases also stay exposed until they upgrade. That is also why container images must be rebuilt without cache; pip and certifi left in an old layer may not change even when the image is rebuilt.

## The heart of the dispute: 3.11 and 3.12

The most heated part of the thread concerns Python 3.11 and 3.12, which receive security fixes only. Security releases of these branches normally do not update the bundled pip. Release manager Hugo van Kemenade explained that pip is normally not updated in security releases, and Steering Council member Thomas Wouters noted that pip has no security releases separate from new features and breaking changes. Users argued that people on these versions would stay insecure by default and asked for fixed releases of older pip branches; pip maintainers said they cannot maintain old branches.

Moderator Łukasz Langa announced that the release managers prefer a targeted fix over upgrading pip wholesale and will post details soon. As part of that, Heimes proposed a change adding a blocklist of known-compromised keys to CPython's ssl module. The proposal itself sparked debate: some core developers stressed that the list is not a security boundary and that telling people to "upgrade Python" should not become the standing answer to every future incident, while Heimes said the list will be updated only when a trusted root or intermediate is compromised and is designed as a last line of defense. Node.js has added a similar blocklist.

## How to check

- Check your pip version with `python -m pip --version` and certifi's location with `python -m certifi`.
- Connect to the test addresses on the incident page with curl; a certificate error means your tool does not trust the compromised certificates.
- Do not forget every virtual environment (venv) on your machine; each one can hold its own copy of pip and certifi.

The details rest on Python's official discussion thread, the security advisories of certifi, uv and conda, and the reporting researcher's incident page. Keep in mind that the compromised keys were effectively guessable since April 2025 and it is unknown whether they were misused in that time. Unlike browsers, most Python tools do not check Certificate Transparency logs, so updating Python code running on servers, in CI pipelines and in old Docker images matters even more than updating browsers. Follow assessments from independent security researchers for other perspectives.