The private keys of eight eMudhra intermediate certificate authority (CA) certificates are compromised, Mozilla and Google’s Chrome Root Program confirms on October 20.
An intermediate CA signs the certificates that websites present, so anyone holding one of these keys could issue a certificate for any website that a browser would accept.
A researcher reported the compromise to the root programs on the evening of October 17, and Chrome and Firefox blocked the eight certificates within hours, after Chrome verified the findings.
No TLS certificate chaining to the six intermediates used for websites had been logged to Certificate Transparency (CT) before Chrome’s block, so none could have been trusted by default in Chrome or any other browser that requires CT logging, the Chrome Root Program said.
It is not known how the keys left eMudhra, when, or whether anyone besides the researcher holds them.
The keys are the ones Go blocked in its October 20 security releases without naming the CA, as The Hacker News reported earlier. The eight hash values in Go’s code match the eight certificates. Go handled the fix on its URGENT track, which its security policy reserves for threats to the ecosystem’s integrity or flaws being exploited in the wild, and neither the issue nor the release notes say which applied.
What Was Compromised
eMudhra is an Indian CA that sells certificates under the emSign brand through companies in India, the United States, and the Netherlands, and it has roots in the Mozilla, Chrome, and Apple root stores. The eight compromised certificates are:
- TLS, domain validated: EM DV TLS CA – G3B (eMudhra BV, Netherlands) and EM DV TLS CA – G3C (eMudhra Inc, United States)
- TLS, organization validated: EM OV TLS CA – G3B and EM OV TLS CA – G3C
- TLS, extended validation: EM EV TLS CA – G3B and EM EV TLS CA – G3C
- Code signing: EM OV CS CA – G3B and EM OV CS CA – G3C
The six TLS certificates were issued by emSign Root TLS CA – G3 and chain to emSign ECC Root CA – G3, a root in the Chrome and Apple stores and, until October 20, in Mozilla’s.
Each of the eight also exists as a second certificate with the same public key, cross-signed by Sectigo under its AAA Certificate Services root, according to a certificate list published by Dennis Jackson, a Mozilla cryptography engineer.
Chrome did not need to block the two code-signing certificates, because its TLS verifier will not build a path through an intermediate restricted to code signing, the Chrome Root Program said.
Who Is Protected, and How
The Chrome Root Program received the report at 18:05 UTC on October 17 and had a CRLSet update blocking the six TLS intermediates in place by 19:45 UTC.
Mozilla received it at 20:06 UTC and finished pushing a OneCRL block to Firefox installations with standard settings at 22:59 UTC. CRLSets and OneCRL are revocation lists that the two browsers fetch on their own, so neither needed an update or a restart.
Chrome’s block matches the public key rather than the certificate, so it also catches the Sectigo cross-signed copies. It is the same mechanism Chrome used earlier this month against rogue certificates for Google domains.
The researcher, credited by Mozilla only as Wayne, signed the message “We have a problem here – Wayne” with each of the eight keys and sent it to the root programs that day, according to Jackson, who published the signatures and certificates on a one-page site.
eMudhra has revoked the eight certificates. Apple blocked them on October 19, Microsoft on October 20, and other trust stores were notified on October 19, according to Jackson’s site.
The cross-signed copies did not widen the risk in Chrome or Firefox. Both stopped trusting Sectigo’s AAA Certificate Services root for websites in April 2025, and Chrome’s root store file does not carry it. Apple’s root list for iOS 26 and macOS 26, published in December 2025, includes it.
Mozilla does not believe, for now, that the problem affects other CAs, Jackson wrote on Mozilla’s policy list, and Chrome said it checked every other CA certificate in its store and “found no other instances of this failure mode.”
What to Update
Browsers get revocation pushed to them. Many other programs that check TLS certificates, from Go binaries to anything using Python’s certifi bundle, do not check revocation data and keep trusting a chain until their code or their root bundle changes.
Mozilla’s advice to anyone who runs a trust store: nothing is needed where clients reliably check revocation and refuse connections when they cannot check, the eight intermediates should be blocked now where the software can block individual intermediates; and otherwise the operator should consider removing trust in the roots that signed them.
The fixes published so far, and what each one does:
add border:
| Software | Fixed in | What it does | Status |
|---|---|---|---|
| Go |
1.27.3 and 1.26.10 |
Rejects any chain containing one of the eight keys (CVE-2026-111943) | Released October 20, rebuild required |
| Firefox |
158.0.1 , ESR 115.43.1 and ESR 153.5.1 |
Carries the OneCRL block for installations that cannot receive Remote Settings ( CVE-2026-113470 ) |
Released October 20 |
| NSS |
3.131.1 |
Removes emSign ECC Root CA – G3 from the trusted list | Released October 20 |
| Python certifi |
2026.10.19 |
Drops emSign ECC Root CA – G3 from the bundle | Released |
| Rust webpki-roots |
1.0.10 |
Drops emSign ECC Root CA – G3 | Released |
| Homebrew ca-certificates |
2026-09-25_1 |
Excludes emSign ECC Root CA – G3, emSign Root TLS CA – G3 and AAA Certificate Services by public key | Released |
| Node.js | None yet |
A draft change would block the eight keys |
Pending |
| Composer ca-bundle | None yet |
An open change would remove emSign ECC Root CA – G3 |
Pending |
Go’s filter sits in the standard library and rejects any chain containing one of the eight keys, on Go’s own verifier and on the macOS and Windows system-verifier paths, and the change adds no setting to turn it off. A program picks it up only when rebuilt with the new release; Go 1.25 and older are out of support and get no fixes.
Three of the fixes work by removing roots rather than blocking the keys. certifi, webpki-roots, and Homebrew’s ca-certificates drop emSign ECC Root CA – G3 from their bundles, and Homebrew also drops Sectigo’s AAA Certificate Services root and emSign Root TLS CA – G3.
That also cuts off every legitimate certificate that chains to those roots. Mozilla, which made the same change to NSS, said some servers will become unavailable to non-Firefox users of its trust list until those servers move to new certificate chains.
Firefox needs nothing unless Remote Settings is disabled by policy or blocked on the network. The October 20 releases carry the block list for those installations.
None of the sources provide a way to detect past misuse of the keys beyond Chrome’s CT search, which covers only logged certificates.
What Happens to eMudhra
Mozilla removed emSign ECC Root CA – G3 from NSS on October 20. Chrome will remove the same root in version 43 of its root store and is reviewing the status of eMudhra’s other root in its store, emSign Root CA – G1, the Chrome Root Program said, citing the seriousness of the incident.
How the keys left eMudhra and when remain open questions. Mozilla said it is working with the CA, other root programs and downstream trust stores on the root cause and will post more when it can. eMudhra’s trust-services repository carried no notice about the incident as of October 20.
Go has not named the CA on its issue, where its release notes cite “specific security concerns around their operation”, and a commenter asked for the hashes in the patch to be explained.
Filippo Valsorda, who maintains the cryptography packages in Go’s standard library, replied that the keys are compromised and the certificates revoked, that Linux root stores are too poorly maintained for revocation to reach applications, and that putting the keys in code is the only option for now.
