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

Update 31 October: Cloudflare reported on 30 October about 22,000 attempted handshakes with the weak eMudhra keys on its own outbound connections in the week after it began logging them. About 160 carried forged certificates naming other organizations’ domains, but Cloudflare found no evidence of interception. GitHub’s advisory database now lists GHSA-5xjx-3w67-w9x9 for the PyPI publishing action, fixed in 1.14.3. Both are covered below.

Update 28 October: Microsoft released out-of-band Windows updates on 26 October. They remove six eMudhra G3 roots and one AAA Certificate Services cross-sign from the Windows trust list, per Microsoft’s response post. Python 3.11.18, 3.12.16, 3.13.18, 3.14.10 and 3.15.2, released on 25 October, now carry the ssl denylist of CVE-2026-115557. Oracle had also issued a first Java alert, CVE-2026-91403, on 21 October.

Update 26 October: Red Hat has now listed fixed builds of CVE-2026-111943 for rhc, grafana, oci-seccomp-bpf-hook and the container-tools:rhel8 module. They are in the update list below.

Update 24 October: Oracle has issued Security Alert CVE-2026-114820 for Java. Python has added an eMudhra denylist to its ssl module as CVE-2026-115557. Both are in the update list below.

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’s incident statement 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.
• Cloudflare later saw forged certificates apparently made with the weak keys, one dated 20 October at 18:19 UTC. It says they looked like servers’ own default certificates and found no evidence of interception.

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, according to Cisco Talos. Microsoft’s response post goes further. On 20 October it published a Windows Disallowed Certificate Trust List update that blocks all eight keys. A CRLSet update for Edge and WebView2 blocks the affected TLS certificates.

Mozilla is removing the emSign ECC Root CA – G3 from its store. Google said Chrome would 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.

On 26 October Microsoft removed trust in more than the eight keys. An out-of-band Windows update takes seven certificates off the Windows trust list: six eMudhra G3 roots and an AAA Certificate Services cross-sign. Microsoft took the same seven off the Edge trust list on 27 October. It says this is a broader decision than blocking the compromised keys, and that it is still evaluating the remaining eMudhra roots.

The updates are KB5134133 for Windows 11 24H2, 25H2 and 26H2 (builds 26100.9725, 26200.9725 and 26300.9725). For Windows 10 21H2 and 22H2 it is KB5134125 (builds 19044.7811 and 19045.7811). Microsoft’s release notes say they carry an updated trusted root payload for devices that cannot reach Microsoft’s certificate-update service, or where automatic certificate trust list updates are off. The Microsoft Trusted Root Program announcement also names KB5134137 for Windows Server 2025.

Apple has blocked the 12 affected TLS certificates since 19 October, and the emSign ECC Root CA – G3 since 23 October, according to Apple’s support page. The block reaches Safari, Mail and apps that use Apple’s networking frameworks. Apple says command-line tools that read /etc/ssl/cert.pem, among them curl, git, python3, ruby, perl and openssl, do not check that block. They can still accept these certificates until a future macOS update.

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.

Cloudflare’s 30 October follow-up logged about 22,000 attempted handshakes with the weak keys in the week after its logging went live on 21 October. Two thirds were fetches of test sites. About 160 presented forged certificates naming other organizations’ domains, some valid for over two years. Cloudflare says these looked like servers’ own default certificates, not interception attempts.

Cloudflare also tested visitors with about 50 million probes from a share of its challenge pages. Across the large networks, more than half of probes still accepted the compromised chain. Embedded browsers such as Android WebView lagged, with 30 to 40 percent still accepting. Cloudflare cautions that this traffic is skewed by unconfirmed bots, so the figures are an indication, not a census.

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 vendors list fixed software for the same CVE:
  • SUSE’s tracker names buildpacks-cli 0.40.10-1.1 and istioctl 1.31.3-1.1 or later for openSUSE Tumbleweed.
  • Red Hat’s RHSA-2026:89031 of 24 October updates Red Hat OpenShift Builds to 1.8.3, including its controller, git-cloner, image-bundler, image-processing and operator images.
  • Red Hat’s errata of 26 October list the same CVE as a Go crypto/x509 flaw in six more updates:
    • rhc 0.2.7-16.el9_8 for RHEL 9.8 EUS (RHSA-2026:89740) and rhc 0.2.5-13.el8_10 for RHEL 8 (RHSA-2026:89741).
    • grafana 10.2.6-23.el9_8.7 for RHEL 9 (RHSA-2026:89744) and grafana 10.2.6-28.el10_2.8 for RHEL 10.2 EUS (RHSA-2026:89751).
    • oci-seccomp-bpf-hook 1.2.11-3.el10_2 for RHEL 10 (RHSA-2026:89752).
    • The container-tools:rhel8 module for RHEL 8 (RHSA-2026:89760).
  • Alpine’s tracker lists go 1.26.10-r0 in 3.24-community as fixed.
• Tailscale: bulletin TS-2026-013 of 21 October says Tailscale 1.104.2 or later includes Go 1.27.3, which distrusts the compromised certificates even if the system certificate store still holds them.
• Other Python tools: the Python forum thread lists sigstore 4.5.1, conda 26.9.4 and pixi 0.82.1 as minimum versions.
• PyPI publishing in GitHub Actions: GHSA-5xjx-3w67-w9x9, rated critical, covers pypa/gh-action-pypi-publish 1.14.2 and earlier. Those versions bundled the emSign root through certifi, which Sigstore uses for Trusted Publishing and digital attestations. Release 1.14.3 of 20 October upgrades certifi and sigstore. Move workflows pinned to an older tag or commit to 1.14.3; on 31 October the release/v1 branch already pointed to it.
• Java: Oracle has issued two Security Alerts for this incident, both scored 9.1:
  • Oracle’s Security Alert CVE-2026-91403 of 21 October says Java updates distrust the impacted eMudhra intermediate CA certificates. It lists Java SE 8u511, 8u511-perf, 11.0.33, 17.0.21, 21.0.13, 25.0.5 and 27.0.1 as affected, plus GraalVM for JDK 17.0.21 and 21.0.13 and GraalVM Enterprise Edition 21.3.20.
  • Oracle’s Security Alert CVE-2026-114820 of 24 October says Java updates remove the impacted eMudhra root CAs. Oracle lists Java SE 8u511-b32, 8u511-perf-b32, 11.0.33.0.2, 17.0.21.0.2, 21.0.13.0.2, 25.0.5.0.2 and 27.0.1.0.2 as affected. It also lists GraalVM for JDK 17.0.21.0.2 and 21.0.13.0.2, and GraalVM Enterprise Edition 21.3.20.0.2. Oracle’s advice is to update to the latest Java version or apply its recommended mitigations, and the alert points to ops.java/emudhra for details.
• CPython: CVE-2026-115557, announced 24 October, adds a denylist of known compromised certificates to the ssl module, so listed certificates are rejected whatever the SSLContext policy says. The change is merged in CPython (pull request 160042). Python 3.11.18, 3.12.16, 3.13.18, 3.14.10 and 3.15.2, all released on 25 October, include it, according to the Python 3.14 changelog and the changelogs of the other branches.
• That changelog calls the denylist a last line of defense. It says removing trust is mainly the platform root store’s job, so keep pip, certifi and the system store updated.
• 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.
• Windows: let automatic certificate trust updates run. On disconnected devices install KB5134133 (Windows 11) or KB5134125 (Windows 10), or deliver the updated trust lists through your own update process. Microsoft also says to find any of your certificates that chain to the seven removed ones and replace them. It warns against restoring trust locally without understanding the risk.
• Windows check: run certutil -f -verifyCTL DisallowedWU | findstr SequenceNumber. Microsoft says the Disallowed list update with the eMudhra blocks has SequenceNumber 01dd5f6ca45c9d86, dated 10/18/2026 6:53 PM. In Edge, open edge://components. Microsoft says CRLSet component 2026.10.20 includes the eMudhra block.
• macOS: Apple’s support page gives steps to remove the emSign ECC Root CA – G3, and optionally AAA Certificate Services, from /etc/ssl/cert.pem until its update arrives. It warns that tools using only that file may then fail to verify some other sites, and that a macOS update can replace the file.
• 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). It also 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. The same releases also fix the Node2Shell Brotli flaw, a separate issue.

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. Separately, while you are in those images, check Pillow too: the Pillow Ghostscript flaw CVE-2026-112900 and the Pillow FlashPix flaw CVE-2026-112398 are fixed only in Pillow 13.0.0.

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 in public.

On 22 October eMudhra announced its exit from the global SSL/TLS certificate business and said its G1 RSA roots keep serving customers during the transition. On 23 October the Chrome Root Program said eMudhra’s delayed responses were not acceptable, and Mozilla said eMudhra had not yet answered the questions it sent on 20 October.

On 26 October eMudhra’s leadership wrote on its status page that “the flaw was ours” and that a script error resulted in issuing CAs with weak keys. It says it will publish a full root cause analysis through the CCADB process and is commissioning an independent expert review.

On 28 October eMudhra said the roughly 30,800 certificates under the affected G3 hierarchies belong to a client ecosystem in the United States. That ecosystem now uses an alternate pathway through the G1 RSA root.

On 27 October the Chrome Root Program wrote in the Mozilla bug that its checks found no further weak CA keys. The checks covered the Chrome-trusted CA certificates it knows of, including those disclosed to the CCADB. It also said that eMudhra’s fourth application to add a root to the Chrome Root Store, pending when the weakness was found, has been denied.

The same day eMudhra wrote in the bug that it had answered Mozilla’s questions in direct correspondence and would work with the browser programs on what can be made public.

On 29 October eMudhra attached to the Mozilla bug its response to the Chrome Root Program’s questions. On 30 October it said on its status page that it had appointed KPMG as its independent external reviewer.

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