Browsers block 8 compromised eMudhra intermediate CA keys

The private keys for eight eMudhra intermediate CA certificates are compromised, and every major trust store has moved to block them within three days of the report. A researcher demonstrated possession by signing a distinct message with each of the eight keys; Mozilla and Google's Chrome Root Program confirmed the compromise publicly on 20 October 2026. No fraudulent certificate has been found in the wild so far, but any software that keeps trusting these intermediates is now trusting keys that are known to be in someone else's hands.

The primary record is the Mozilla dev-security-policy thread "Compromised eMudhra Intermediate Certificates," where Mozilla cryptography engineer Dennis Jackson published the researcher's signatures and the certificate list. The detail below is drawn from that thread and from The Hacker News.

What was compromised

• Six TLS intermediates — domain-validated, organisation-validated and extended-validation, each in a G3B and a G3C variant — all chaining to the emSign ECC Root CA - G3 root. Each also exists as a Sectigo cross-signed copy.
• Two code-signing intermediates (EM OV CS CA - G3B and - G3C).

The researcher reported the compromise to the root programs on the evening of 17 October. Root cause is unknown: it is not known how the keys left eMudhra, when, or whether anyone besides the researcher holds them.

Vendor response timeline (UTC)

• 17 Oct 18:05 — Chrome Root Program receives the report.
• 17 Oct 19:45 — Chrome has a CRLSet block in place for the six TLS intermediates, matching on public key (which also catches the Sectigo cross-signed copies).
• 17 Oct 20:06 → 22:59 — Mozilla receives the report and finishes pushing a OneCRL block to Firefox installs on standard settings.
• 19 Oct — Apple blocks the certificates.
• 20 Oct — Microsoft blocks them; Mozilla and Chrome confirm publicly; Mozilla removes emSign ECC Root CA - G3 from NSS; Go ships releases 1.27.3 and 1.26.10, which reject any chain containing one of the eight keys (tracked as CVE-2026-111943, per Go's release notes).

Because no certificate chaining to the six TLS intermediates had been logged to Certificate Transparency before the blocks, none could have been trusted by default in Chrome or other CT-requiring browsers. Chrome says it checked every other CA in its store and found no further instances.

Who is still exposed

Browsers receive revocation pushes automatically. The risk sits with software that does not check revocation and keeps trusting a chain until its code or root bundle changes — Mozilla explicitly names Go binaries and anything using Python's certifi bundle. eMudhra has revoked the eight certificates, but as of 20 October its trust-services repository carried no public notice.

Action checklist

1. Determine whether any certificate you rely on chains to emSign ECC Root CA - G3 or to an eMudhra intermediate. If so, plan migration to a different CA now — those roots are being distrusted and legitimate certificates under them will stop validating.
2. Rebuild Go binaries against 1.27.3 or 1.26.10 (or later); the fix cannot be disabled and only takes effect on a rebuild. Go 1.25 and older receive no fix.
3. Update trust bundles that lag browser revocation: certifi, Rust webpki-roots, Homebrew ca-certificates have already removed the roots; Node.js and Composer updates were pending at publication.
4. If you operate a trust store and can block individual intermediates, block the eight keys now rather than waiting on a root removal.

Context

The speed here is the story: report to multi-vendor block in under three days, driven by a researcher who proved the compromise rather than merely alleging it. This is a cleaner outcome than most CA incidents, but the long tail — static Go binaries, pinned bundles, embedded devices — will trust these keys for as long as nobody rebuilds them. A key compromise is only "contained" for software that checks revocation.