eMudhra CA keys compromised: Go, Firefox, NSS ship fixes

The private keys behind eight intermediate certificates from eMudhra, an Indian certificate authority, were exposed, Mozilla and Google confirmed on October 20, 2026. Anyone holding those keys could issue HTTPS certificates that browsers would trust for sites they do not own. Browsers blocked the certificates within hours, but many apps outside the browser stay exposed until they are updated.

What happened to the eMudhra keys

A certificate authority, or CA, vouches for websites by signing their certificates. Large CAs sign through "intermediate" certificates that sit between their root and each website. If an intermediate's private key leaks, an attacker can mint a valid-looking certificate for any domain.

A researcher reported the eight keys to browser makers on Saturday, October 17. The researcher proved it by signing a message with each key: "We have a problem here - Wayne." Six of the intermediates issue website (TLS) certificates and two sign software code, The Hacker News reports.

The keys were also weak, according to security researcher Scott Helme. Each was a tiny number, and he recovered the private keys for all 16 related certificates in under a second. The intermediates date from April 2025, so anyone could have done the same for about 17 months. Helme cites eMudhra's explanation: a script bug created a second, weak key pair, and staff picked the wrong one because the names were similar.

The Hacker News says it is unknown how the keys left eMudhra and who else holds them. Helme's analysis adds that there is no way to know whether anyone recovered them before now.

On October 22, eMudhra said it would leave the global SSL/TLS certificate business altogether, as covered in eMudhra quits the global SSL/TLS certificate business after weak keys.

How fast each vendor moved

When (UTC)	Action
October 17, 18:05	Chrome's root program receives the report
October 17, 19:45	Chrome blocks the six TLS intermediates through CRLSet, its revocation list
October 17, 20:06	Mozilla receives the report
October 17, 22:59	Firefox's OneCRL block reaches users with standard settings
October 19	Apple blocks the certificates
October 20	Microsoft blocks them; Go, Firefox and NSS releases ship

Mozilla says Firefox needed no update or restart for the block. It also shipped Firefox 158.0.1, ESR 115.43.1 and ESR 153.5.1 for users whose custom settings stopped OneCRL updates. NSS 3.131.1, Mozilla's security library, removes the emSign ECC Root CA - G3 root that signed the intermediates. Chrome will drop the same root in Chrome Root Store version 43.

Chrome did not block the two code-signing intermediates, because its website checks never pass through them. Chrome also said it checked every other CA in its store and "found no other instances of this failure mode." No logged website certificates chained to the six TLS intermediates before Chrome's block, The Hacker News reports.

Why apps outside the browser are still at risk

Browsers receive block lists automatically. Most other software does not check revocation at all. It trusts a bundled list of CAs until someone ships a new one.

Helme tested this with a forged certificate for api.stripe.com. With default settings, curl, Python and Node accepted it on Linux and macOS. On Windows, the system crypto library accepted it unless revocation checking was turned on.

Go needed a code change for the same reason, Cyber Kendra explains. Its certificate checker does not read browser block lists, so Go programs trust the keys until they are rebuilt. These are the fixed versions named across the reports:

Software	Fixed version
Go	1.27.3 and 1.26.10 (CVE-2026-111943); 1.25 and older are out of support
Firefox	158.0.1, ESR 115.43.1, ESR 153.5.1
NSS	3.131.1
Python certifi	2026.10.19
Rust webpki-roots	1.0.10
Electron	44.9.1, 43.8.1, 42.11.16

What this means for developers

Browsers are covered. Your servers, build tools and containers probably are not, until you update them.

• Rebuild Go services. A Go binary carries its certificate checks inside it. Rebuild with Go 1.27.3 or 1.26.10 and redeploy; updating the machine's CA list alone does not help.
• Bump bundled CA lists. Update certifi in Python projects, webpki-roots in Rust and Electron in desktop apps. Rebuild container images so they pick up the new system bundle. Python's October 21 releases bundle the fix for new installs, as covered in Python 3.15.1, 3.14.9 and 3.13.17 ship pip 26.2.2.
• Search your own chains. If a vendor or internal service uses an eMudhra certificate, find out before the roots disappear. Paste a certificate into a certificate decoder and read its issuer field.
• Turn on revocation checks where you can. Helme's Windows test only caught the forged certificate with revocation checking enabled. Treat that setting as part of your TLS configuration, not an extra.