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.

The keys did not have to be stolen. They were generated with too little randomness, so anyone can compute them from the public certificates, Google's security teams said on October 20. eMudhra said on October 21 that a flaw in the April 2025 ceremony that created the certificates produced a second, weak set of keys alongside the intended ones, and that the weak set is what was published to the browser root stores.

Mozilla recovered the keys on its own within two hours of receiving the report, and researchers have since published them. Whether anyone exploited the flaw since the certificates were created is not known.

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. Android devices received an equivalent block through Google Play Services at about 22:00 UTC on October 19, Google said.

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:

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.

Jackson's site tracks a longer list, including the ca-certificates packages of Ubuntu, Debian, Fedora, Arch, Alpine and Gentoo, curl's CA bundle, pip, uv and Electron, with FreeBSD and Bun still pending, and it warns that the curl built into macOS still accepts the chain because it checks against a bundle file that Apple has not updated.

Cloudflare, which learned of the problem on October 19, has released fixed WARP and 1.1.1.1 clients and cloudflared 2026.10.2, and said customers who run their own origin servers, mutual TLS or containers may need to update trust stores themselves.

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. The removal is expected to reach every device that relies on the Chrome Root Store on the morning of Tuesday, October 27, Pacific time, and earlier on Chrome Canary and Beta, Google said, so website operators with certificates chaining to that root must install a certificate from another hierarchy before then to avoid breakage. eMudhra has committed to moving those customers off the root, Google said.

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. The company posted a statement on its corporate site that day and issued a press release on October 21, covered in the update below.

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.

Roland Shoemaker of the Go security team later wrote on the issue that the team learned of the underlying problem on October 19 and kept the release notes deliberately vague, because the flaw was easy to exploit and the team expected it to become public that day. It became widely known only on October 20, he wrote.

Update: eMudhra Blames Flaw in April 2025 Key Ceremony

eMudhra Limited said in a press release filed with the BSE stock exchange on October 21 that the eight intermediates were created under its ECC root in a key generation ceremony on April 30, 2025, using hardware security modules certified to FIPS 140-2 Level 3, and that a flaw in that ceremony caused a key wrap and unwrap step, which packages a key for transfer and unpacks it again, to produce a second set of weak keys alongside the original strong keys. The weak keys were the ones published to the browser root stores, the company said, and it is still working to establish the root cause.

The company said an independent researcher found over the weekend of October 17 that the weak keys could be reverse-engineered, "possibly with AI-assisted techniques", and reported this to Apple, Google, Microsoft and Mozilla.

Scott Helme, a security researcher, wrote that he recovered all eight private keys from the public certificates on his laptop in under a second, that one of them is the number 4 and the rest are also whole numbers below 256, and that an AI agent did the same from a single prompt.

eMudhra said its infrastructure was not compromised, no data was breached and its physical and logical security controls remained intact. It said the roots and issuing CAs had passed independent audits two years in a row and had been in browser trust lists since mid 2025, and that the incident has no connection with its Indian digital signature certificate and eSign businesses, which run on separate infrastructure.

The global TLS business accounts for around 1% of the company's revenue, it said, while acknowledging a reputational risk it cannot quantify. It is giving affected customers replacement certificates and is continuing its root-cause investigation with the root programs.

In the statement on its website, dated October 20, eMudhra said the incident does not affect its root CA private keys or its other intermediate CAs, that only one of the eight intermediates had been deployed in production, and that none of the eight, including that one, had issued any end-entity certificate.

eMudhra's shares fell 20% in Mumbai on October 21, Business Standard reported.

(Corrected on October 21: an earlier version said it was not known how the keys left eMudhra. The keys did not need to leave the company, because they were generated with so little randomness that anyone can compute them from the public certificates. The passages on the cause have been revised.)