---
title: "eMudhra CA Key Compromise: Update Non-Browser TLS Clients"
url: https://erroneo.us/security/briefs/emudhra-emsign-intermediate-ca-key-compromise/
description: "Eight eMudhra intermediate CA keys are recoverable by anyone. Browsers are safe; update pip 26.2.2, certifi, uv, Go, Java, Node and OS CA bundles this week."
type: security-brief
section: "Security Digest"
date_published: 2026-10-20
date_modified: 2026-10-21
publisher: erroneo.us
author: erroneo.us Security Desk
verdict: "Patch this week"
cves: ["CVE-2026-111943", "CVE-2026-91403"]
severity: "high"
exploited: "none-known"
kev: false
license: All rights reserved. Quote with attribution and a link.
---

# eMudhra CA Key Compromise: Update Non-Browser TLS Clients

**Verdict: Patch this week.** Anyone can mint certificates from these broken CA keys, but only clients that skip Certificate Transparency and still trust the emSign root are exposed, and only to an on-path attacker: update those trust bundles this week, build machines first.

- **Who must act:** Teams running Python (pip, certifi, requests, uv), Go, Java, Node.js, Rust rustls or distro CA bundles in servers, containers and CI, plus macOS users of the built-in curl, git and python3.
- **Who can relax:** Browser users: Chrome, Firefox, Safari and Edge blocked the certificates by October 20 and enforce Certificate Transparency, where no certificate from these intermediates was logged before the block.
- **Affected:** certifi before 2026.10.19 (GitHub advisory range); pip before 26.2.2 (vendored certifi); uv before 0.13.4; Go before 1.27.3 and 1.26.10; OpenJDK 27.0.1, 25.0.5, 21.0.13, 17.0.21, 11.0.33, 8u512 and earlier (per OpenJDK); Node.js before 22.23.4, 24.22.1 and 26.12.1; rustls webpki-roots / webpki-root-certs before 1.0.10; OS ca-certificates packages and macOS /etc/ssl/cert.pem not yet updated
- **Fixed:** certifi 2026.10.19; pip 26.2.2; uv 0.13.4; Go 1.27.3, 1.26.10; Node.js 22.23.4, 24.22.1, 26.12.1; webpki-roots / webpki-root-certs 1.0.10, rustls-webpki 0.103.16; Updated ca-certificates: Debian 20250419~deb12u2 / 20250419+deb13u1, Alpine 20261020-r0, Ubuntu 20260816ubuntu0.* builds; OpenJDK: see the October 21 advisory for CVE-2026-91403
- **CVEs:** CVE-2026-111943, CVE-2026-91403
- **CISA KEV:** no · **Exploitation:** No known exploitation

## What to do

1. Upgrade pip to 26.2.2 first (install the wheel by checksum as the Python announcement shows), then certifi to 2026.10.19 and uv to 0.13.4.
2. Update the OS CA bundle (apt-get install --only-upgrade ca-certificates, apk upgrade ca-certificates, dnf update ca-certificates) and rebuild images on refreshed base images.
3. Move Go to 1.27.3 or 1.26.10, Node.js to 22.23.4, 24.22.1 or 26.12.1, and rustls webpki-roots to 1.0.10, then rebuild binaries that embed them.
4. Apply OpenJDK's fix for CVE-2026-91403, or add the eight intermediates to the JDK's blocked.certs.
5. On macOS, apply the disclosure site's /etc/ssl/cert.pem workaround for the built-in curl, git and python3, or use tools with updated bundles.
6. Check whether your own servers' certificates chain to emSign ECC Root CA - G3; clients that update will reject them.

### How to check if you are affected

- From each runtime, request https://dv-g3b-emudhra.we-have-a-problem.com/ (for example with curl or python -c "import requests; requests.get('https://dv-g3b-emudhra.we-have-a-problem.com/')"); a certificate error means the client is fixed.
- Inventory versions in every image and CI runner: pip --version, pip show certifi, uv --version, go version, node -v, java -version.
- Run grep -c 'emSign ECC Root CA - G3' "$(python -m certifi)"; any count above 0 means the old certifi bundle is still in use.
- Search TLS inspection or Zeek x509 logs for issuers named EM DV, OV or EV TLS CA - G3B or G3C.

## What happened

On October 17, 2026, a researcher reported that the private keys of eight intermediate certificate authorities run by eMudhra, an Indian CA, could be recovered by anyone. Six of the eight issue TLS certificates and two issue code-signing certificates. Mozilla's analysis in [bug 2083449](https://bugzilla.mozilla.org/show_bug.cgi?id=2083449) found that all eight P-384 keys "used integers less than 256," so the key can be read straight off the public certificate. eMudhra says a code flaw during an April 30, 2025 key ceremony created a second, weaker key pair, and those keys were used "by mistake to create the csr (because the key labels were similar)." Mozilla wrote that "the impact of this incident could not be higher" and that multiple people had recovered the keys independently.

With one of these keys, an attacker can issue a certificate for any hostname. The intermediates chain through Sectigo cross-signs and the **emSign ECC Root CA - G3** root to the Mozilla, Apple, Microsoft and Chrome trust stores, and to the many bundles copied from them. Mozilla, Chrome and others made the details public on October 20 in a [dev-security-policy thread](https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE/m/0XofdebrAAAJ) and on a community [disclosure site](https://emudhra.we-have-a-problem.com).

## Who is affected

**Not browsers.** Chrome blocked the TLS intermediates by SPKI hash through CRLSets on October 17, and Firefox blocked them through OneCRL that evening. Apple followed on October 19 and Microsoft on October 20. Chrome adds that no TLS certificate chaining to these CAs was logged to Certificate Transparency before the block, so CT-enforcing browsers could not have accepted a forged one.

**Everything that ships its own copy of the roots and skips CT or revocation checks.** That is most developer tooling:

- **Python:** [certifi](https://github.com/certifi/python-certifi/security/advisories/GHSA-6q48-6c7w-9gw2) (behind requests, urllib3 and the python.org macOS installer) before 2026.10.19. Christian Heimes notes in the [Python announcement](https://discuss.python.org/t/information-for-python-users-regarding-emudhra-emsign-ca-certificate-security-incident/109576) that pip always loads its vendored certifi in addition to the system store, so fixing the OS is not enough below [pip 26.2.2](https://github.com/pypa/pip/releases/tag/26.2.2). uv before 0.13.4 is affected through its vendored webpki roots ([GHSA-hq85-5cpj-mr62](https://github.com/advisories/GHSA-hq85-5cpj-mr62)).
- **Go:** [Go 1.27.3 and 1.26.10](https://groups.google.com/g/golang-announce/c/66pojueaQek) make crypto/x509 filter out chains containing these intermediates (CVE-2026-111943).
- **Java:** [OpenJDK's October 21 advisory](https://openjdk.org/groups/vulnerability/advisories/2026-10-21) (CVE-2026-91403, CVSS 9.1) lists 27.0.1, 25.0.5, 21.0.13, 17.0.21, 11.0.33, 8u512 and earlier as affected.
- **Node.js, Rust and others:** the disclosure site's patch table lists Node.js 22.23.4, 24.22.1 and 26.12.1, rustls webpki-roots 1.0.10, Deno 2.9.8, Electron 44.9.1, Composer ca-bundle 1.4.16 and many more.
- **Operating systems:** distro `ca-certificates` packages (Debian, Ubuntu, Alpine, Fedora, Arch and others have shipped updates), and on macOS the built-in curl, git and python3, which read `/etc/ssl/cert.pem` without checking revocation. Apple had not updated that file at the time of the disclosure.

## Do you really need to act?

**Yes, but this week, not tonight.** To exploit this, an attacker must be on the network path: hostile Wi-Fi, a compromised router or proxy, DNS hijacking, or a foothold in your cloud network. If they are, an unpatched `pip install` or Go service will accept a forged certificate for any host. That turns network position into tampered packages or stolen API tokens. No attacks are known, but the disclosure site says plainly that nobody knows whether anyone exploited the flaw against non-CT clients since April 2025. Prioritize build machines, CI runners and anything that installs packages or handles credentials over shared networks.

There is a second, operational risk. Mozilla and Chrome are removing trust in **emSign ECC Root CA - G3** altogether. eMudhra estimates "about 30,000 certs that require migration." If your own services use certificates from that hierarchy, updated clients will start refusing to connect.

## What to do now

1. Python: upgrade pip first. The announcement shows installing the 26.2.2 wheel by URL with a pinned SHA-256, so the upgrade itself doesn't depend on the old bundle. Then run `python -m pip install -U 'certifi>=2026.10.19'`, update uv to 0.13.4 (`UV_SYSTEM_CERTS=true uv self update` on a patched OS), and bump certifi in lockfiles.
2. Update OS bundles (`apt-get install --only-upgrade ca-certificates`, `apk upgrade ca-certificates`, `dnf update ca-certificates`), then rebuild container images on refreshed bases. The Python thread notes that the official Python Docker images still shipped pip 26.2.1 on October 21.
3. Roll Go, Node.js and Java to the fixed releases and rebuild statically linked binaries. For JDKs you can't update yet, OpenJDK says to block the certificates in `blocked.certs`.
4. On macOS and Linux hosts that can't be updated yet, the disclosure site documents commands that distrust the affected roots in the system store.
5. Check the issuer chain of your own public certificates, for example with `openssl s_client -connect host:443 -showcerts`, and migrate any that chain to emSign ECC Root CA - G3.

## How to tell if you were hit

First, find out whether each client is still exposed: `curl https://dv-g3b-emudhra.we-have-a-problem.com/` succeeds only if the client still trusts the compromised chain, and a certificate error means it is fixed. Run the same request from Python, Go or Java inside your images, not just from your shell. To look for actual misuse, search TLS inspection proxies and Zeek `x509.log` for certificates issued by "EM DV/OV/EV TLS CA - G3B" or "G3C". eMudhra says almost no end-entity certificates were issued from these intermediates, so any hit deserves investigation.

## Timeline

- Apr 30, 2025 — eMudhra's key ceremony produces the flawed keys.
- Oct 17, 2026 — The flawed keys are found and reported to the root programs at 18:05 UTC. Chrome ships a CRLSet block at 19:45 UTC, and Mozilla's OneCRL block completes at 22:59 UTC.
- Oct 18, 2026 — eMudhra revokes the eight intermediates.
- Oct 19, 2026 — Downstream trust stores are notified, Sectigo's cross-signs are revoked, Apple blocks the certificates, and Go 1.27.3 and 1.26.10 ship.
- Oct 20, 2026 — Public disclosure. Microsoft blocks the certificates, Mozilla removes the root from NSS, and pip 26.2.2, uv 0.13.4 and certifi 2026.10.19 advisories land.
- Oct 21, 2026 — Node.js security releases and the OpenJDK advisory ship. Fixes for Bun and Erlang certifi are still pending.

## Sources

1. [Mozilla dev-security-policy — Compromised eMudhra Intermediate Certificates](https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE/m/0XofdebrAAAJ)
2. [Mozilla Bugzilla — eMudhra: Private key compromise of Intermediate Certificates (bug 2083449)](https://bugzilla.mozilla.org/show_bug.cgi?id=2083449)
3. [certifi — GHSA-6q48-6c7w-9gw2: Removal of emSign root certificate](https://github.com/certifi/python-certifi/security/advisories/GHSA-6q48-6c7w-9gw2)
4. [GitHub Advisory Database — GHSA-hq85-5cpj-mr62: uv bundled CA store trusts compromised emSign root](https://github.com/advisories/GHSA-hq85-5cpj-mr62)
5. [Go — Go 1.27.3 and Go 1.26.10 are released (CVE-2026-111943)](https://groups.google.com/g/golang-announce/c/66pojueaQek)
6. [OpenJDK Vulnerability Group — Advisory 2026-10-21 (CVE-2026-91403)](https://openjdk.org/groups/vulnerability/advisories/2026-10-21)
7. [pip — Release 26.2.2](https://github.com/pypa/pip/releases/tag/26.2.2)
8. [eMudhra Intermediate CA Compromise — disclosure site, checker and patch table](https://emudhra.we-have-a-problem.com)
9. [Python Discourse — Information for Python users regarding the eMudhra / emSign CA incident](https://discuss.python.org/t/information-for-python-users-regarding-emudhra-emsign-ca-certificate-security-incident/109576)

---
Source page: https://erroneo.us/security/briefs/emudhra-emsign-intermediate-ca-key-compromise/ · Security Digest: https://erroneo.us/security/ · More: https://erroneo.us/llms.txt