eMudhra CA Key Compromise: What Python, uv and Container Teams Must Update Now

Browsers have already blocked the weak eMudhra keys, so most people are safe. Programs that carry their own list of trusted certificate authorities are not, until they are updated. That includes older pip, uv and certifi, and any container image built with them.

Is pip install compromised, and can anyone now impersonate pypi.org? The sources we opened support part of that and not the rest. Below is what holds up, then the update list.

What Happened to the eMudhra Keys?

On 17 October 2026 a researcher reported that the private keys of eight eMudhra intermediate certificate authorities were weak. Mozilla’s bug record says the keys are P-384 keys whose private values were tiny integers, below 256. Scott Helme’s write-up lists the smallest as 4. A secure key should be a random 384-bit number, so each of these can be found by trying a few hundred guesses.

eMudhra says the keys came from a key generation ceremony on 30 April 2025. A wrap and unwrap step there created a second, weak set of keys that was used by mistake. It says the flaw went unnoticed for about 18 months across two audit cycles. The eight intermediates, six for TLS and two for code signing, were revoked on 18 October. The root cause is not yet final.

The keys matter because anyone who recovers one can issue a certificate that looks valid for any website. That is the setup for an adversary-in-the-middle attack, which also needs the attacker to sit on the network path.

Is Pip Install Compromised? What Is True and What Is Overstated

True:

• Versions of pip before 26.2.2 ship a copy of certifi that still trusts the emSign ECC Root CA – G3. The pip changelog lists 26.2.2, dated 20 October 2026, as a release that only upgrades certifi to 2026.10.19.
• Christian Heimes wrote in the Python forum thread that pip always loads its own certifi in addition to the system store. In his words, “there is no supported way to disable this”, and setting --cert or REQUESTS_CA_BUNDLE only adds more authorities. So removing the root from your operating system alone does not protect an old pip.
• The certifi advisory GHSA-6q48-6c7w-9gw2 is rated critical, CVSS 9.1, and names pip among the affected software.

Overstated:

• Nothing we read says PyPI or pip was breached. The weakness is in a certificate authority that older trust lists still accept.
• Impersonating pypi.org also needs the attacker to intercept your traffic. The advisory says an attacker who holds a key and can intercept connections could read or change TLS sessions.
• eMudhra says it knows of no evidence the keys were used before disclosure. Talos saw no malicious use as of 21 October, 14:00 UTC.

In short, the risk is real for an old pip on a hostile network, and the fix is one version bump. It becomes a supply chain attack only if someone can sit between your build host and the package index.

Which Browsers and Tools Are Exposed?

Chrome, Mozilla and Apple blocked the six TLS intermediates, and Microsoft blocked the two code signing ones, according to Talos. Mozilla is removing the emSign ECC Root CA – G3 from its store. Google says Chrome will remove the emSign ECC Root CA – G3 on 27 October 2026. eMudhra says its G1 roots remain active, and Google says it is still reviewing eMudhra’s remaining CA certificates.

Tools with their own bundle and no revocation checks are the gap. Scott Helme reports that default curl, Python and Node on Linux and macOS accepted a forged certificate in his tests. Talos also names CI/CD pipelines, package manager TLS paths, VPN appliances and embedded devices with stale or separately managed trust stores.

What Should You Update, Ecosystem by Ecosystem?

• pip: 26.2.2 or later. Check with pip --version. Every virtual environment and image has its own pip, so check each one.
• certifi: 2026.10.19 or later. Check with python -c "import certifi; print(certifi.__version__)". Release 2026.10.18 removed all emSign roots and 2026.10.19 restored the unaffected ones.
• uv: 0.13.4 or later (GHSA-hq85-5cpj-mr62). If you cannot upgrade, use system certificates with --system-certs or point SSL_CERT_FILE or SSL_CERT_DIR at a bundle without the affected roots.
• Go: 1.26.10 or 1.27.3, both released 19 October with crypto/x509 security fixes. The Go vulnerability database lists CVE-2026-111943 (GO-2026-6809), a denylist that makes Certificate.Verify reject known untrusted intermediates. Cisco Talos links this entry to the eight eMudhra intermediates; the Go entry itself does not name eMudhra.
• Other Python tools: the Python thread lists sigstore 4.5.1, conda 26.9.4 and pixi 0.82.1 as minimum versions.
• Docker and other containers: the certifi advisory says to rebuild images so the CA stores refresh. Pull a fresh base image, then check pip and certifi inside it.
• Operating system: take the distribution’s ca-certificates update. The emudhra.we-have-a-problem.com page lists fixed Debian ca-certificates versions (Debian bug 1151413) and says the macOS file /etc/ssl/cert.pem had not been updated and that curl’s CA bundle was updated on 2026-10-20.
• Node: 26.12.1, 24.22.1 or 22.23.4, released 21 October, update the bundled root certificates to NSS 3.131.1, which removes the emSign ECC Root CA – G3.

One caution from the Python thread: Seth Larson’s reply there lists SHA-256 checksums for pip and uv so you can install them “regardless of a MITM attack against certifi-based verifiers”.

How Do You Check Whether You Are Exposed?

Start with an inventory, not a scan. List every place a TLS client runs with its own bundle: build hosts, CI runners, container images, developer laptops and appliances. Record the version of pip, certifi, uv and Go in each. Anything below the versions above is exposed.

For a live test, the page at emudhra.we-have-a-problem.com, published by Dennis Jackson, offers hosts that present chains through the affected intermediates. A client that connects without an error still trusts them. A second set of hosts also tests whether the client enforces Certificate Transparency, which many non-browser clients do not.

Supply chain risk is part of your attack surface. Read about compromising the software supply chain and about why a lapsed or untrusted certificate is an attack path.

What Is Still Open?

eMudhra says the impact is limited to one customer ecosystem in the United States. In the Mozilla bug, eMudhra estimated about 30,000 certificates need migration. The Chrome Root Program counted about 30,800 in Certificate Transparency, 99.9 percent from two subordinate CAs of one operator. eMudhra has not published the full root cause, and several questions in the Mozilla bug are still unanswered.

The full dated record is on our eMudhra CA key compromise incident page.