eMudhra CA Key Compromise: Update Non-Browser TLS Clients

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 or compromised

• 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 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 and on a community disclosure site.

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 (behind requests, urllib3 and the python.org macOS installer) before 2026.10.19. Christian Heimes notes in the Python announcement 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. uv before 0.13.4 is affected through its vendored webpki roots (GHSA-hq85-5cpj-mr62).
• Go: Go 1.27.3 and 1.26.10 make crypto/x509 filter out chains containing these intermediates (CVE-2026-111943).
• Java: OpenJDK's October 21 advisory (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.

Vulnerability records

• CVE-2026-111943 · On most platforms, Go uses the given system root certificates.
• CVE-2026-91403 · Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JSSE).

Sources

Original sources first: vendor and project advisories, CVE and government records, the discoverers’ write-ups. Every claim above links to one of these. See how the Security Desk works.

Original and primary sources

1. Mozilla dev-security-policy — Compromised eMudhra Intermediate Certificates groups.google.com
2. Mozilla Bugzilla — eMudhra: Private key compromise of Intermediate Certificates (bug 2083449) bugzilla.mozilla.org
3. certifi — GHSA-6q48-6c7w-9gw2: Removal of emSign root certificate github.com
4. GitHub Advisory Database — GHSA-hq85-5cpj-mr62: uv bundled CA store trusts compromised emSign root github.com
5. Go — Go 1.27.3 and Go 1.26.10 are released (CVE-2026-111943) groups.google.com
6. OpenJDK Vulnerability Group — Advisory 2026-10-21 (CVE-2026-91403) openjdk.org
7. pip — Release 26.2.2 github.com
8. eMudhra Intermediate CA Compromise — disclosure site, checker and patch table emudhra.we-have-a-problem.com
9. Python Discourse — Information for Python users regarding the eMudhra / emSign CA incident discuss.python.org