eMudhra Intermediate CA Keys Compromised

On 17 October 2026 at 20:06 UTC, Mozilla received a report that private keys for eight eMudhra intermediate certificates had been compromised. Dennis Jackson recorded that intake in Mozilla bug 2083449. The reporter, credited as Wayne, had emailed Apple, Chrome, Microsoft, Mozilla, and eMudhra at 18:05 UTC the same day, with signed proof of key control for all eight. Mozilla acknowledged at 20:08 UTC. By 21:48 UTC, Mozilla engineers had recovered the private keys independently, without the reporter’s method.

eMudhra did respond. Its incident page was first published on 20 October 2026 and last updated on 21 October 2026, marked “Investigation ongoing.” A press release the same day draws a narrow perimeter around “select Global TLS Intermediate and one Root CA.” The bug, the disclosure site published by Dennis Jackson, and that vendor text do not describe the same clock, the same scope, or the same set of clients.

Key Takeaways:

• Mozilla bug 2083449 records a Wayne report, forwarded by the Chrome Root Program, received at 20:06 UTC on 17 October 2026, covering eight eMudhra intermediate CA certificates.
• The disclosure says the private keys were incorrectly generated, are recoverable from the certificates, and date to April 2025, with no certificate transparency entries for that period.
• Jackson’s bug comment says eMudhra marked eight certificates revoked at 09:38 UTC on 18 October with reason caCompromise. eMudhra’s 21 October update says it revoked them the following day.
• Mozilla’s OneCRL block and Chrome’s CRLSet block of the six TLS intermediates are confirmed by those programs. Apple-since-19-October and Microsoft-since-20-October are the disclosure’s claims, not notices from Apple or Microsoft.
• No active exploitation is publicly known. Clients outside CT-enforcing browsers may still trust the intermediates until their trust store or runtime is updated.

What was disclosed, and what eMudhra said

The public page that collects the finding, the proof method, and the client-check hosts is Jackson’s disclosure site. The intake record is Mozilla bug 2083449, titled “Private key compromise of eMudhra Intermediate Certificates.” Wayne’s message, quoted on the disclosure site, was “We have problem here – Wayne,” signed with each intermediate key. This account does not republish those signatures, the proof archives, or the keys.

On 18 October 2026, keys of eight (out of several) eMudhra Global TLS intermediate Certificate Authorities (CAs) were found to be cryptographically weak, and all eight intermediates were revoked the following day. The keys “were generated on FIPS 140-2 Level 3 certified Hardware Security Modules” and “a flaw in one step of the ceremony procedure” produced “a second, weak set of keys alongside the original strong keys.” eMudhra also said: “We are not aware of any evidence that weak keys were recovered or exploited by anyone before issue was disclosed.”

A separate press release the same day is titled “eMudhra Statement on distrust of select Global TLS Intermediate and one Root CA” and carries the subhead “India DSC and eSign businesses unaffected; no infrastructure compromise or data breach.” In that release the company says the affected global TLS business “accounts for around 1% of company’s revenue.” Those sentences are the vendor’s claims. They are not an audit of every client that still trusts the chain.

Recoverable private keys from an April 2025 ceremony

The disclosure site states the cause in one sentence: the private keys “were incorrectly generated by the CA” and “anyone can recover them from the certificates.” That recovery has been possible since the certificates were created in April 2025. eMudhra’s 21 October update pins the ceremony to 30 April 2025. The failure was a bad generation step whose output was published inside certificates that root programs already trusted.

Mozilla’s incident description lists eight certificates. Six are TLS intermediates issued by emSign Root TLS CA – G3: EM EV TLS CA – G3B and EM EV TLS CA – G3C, EM OV TLS CA – G3B and EM OV TLS CA – G3C, and EM DV TLS CA – G3B and EM DV TLS CA – G3C. Two are code-signing intermediates issued by emSign Root CS CA – G3: EM OV CS CA – G3B and EM OV CS CA – G3C. The G3B names are associated with eMudhra BV. The G3C names are associated with eMudhra Inc. According to the disclosure, each of the eight also exists as a Sectigo cross-sign under the AAA Certificate Services root. The six TLS certificates chain onward to emSign ECC Root CA – G3.

BleepingComputer, citing Mozilla bug 2083449, reported that all eight used P-384 private keys generated in April 2025 with values smaller than 256, so recovery meant testing 256 candidates. The Register reported that one of those keys was the number 4, on EM OV TLS CA – G3C. Jackson wrote on the bug that the private keys “are effectively all-zeroes apart from the last byte” and “can be recovered near instantly.” An intermediate with a recoverable key can sign a certificate for any name a relying party will accept under that intermediate. That is the blast radius. It does not require the root private key.

The disclosure site says there are no certificate transparency entries for these intermediates in the period since April 2025, “indicating that CT-enforcing clients like Firefox, Chrome, Edge and Safari could not have been attacked.” That sentence is the disclosure’s claim about browsers that enforce certificate transparency. It is not a finding that every client was safe. The Hacker News, citing the Chrome Root Program, said no TLS certificate chaining to the six website intermediates had been logged to Certificate Transparency before Chrome’s block, so none could have been trusted by default in Chrome or another browser that requires CT logging.

Clients outside that set do not enforce certificate transparency. The disclosure says plainly: “We do not know if attackers exploited flawed key generation to target these clients.” No active exploitation is publicly known. Cloudflare’s security review “has not identified active exploitation of this issue on Cloudflare services.” eMudhra says it is not aware of evidence that the weak keys were recovered or exploited before disclosure. That vendor sentence covers the period before the report. It does not cover what happened after several parties recovered the keys.

Revocation is not a client update

Jackson recorded the revocation on Mozilla bug 2083449: “18th October @ 09:38 UTC: eMudhra marked 8 impacted certificates as revoked (reason: caCompromise).” Wayne’s timeline on the same bug uses the same clock time and the same reason string, and adds that “revocation time varies per-cert.” That is the record in the bug. It is not the date in the company’s later public post.

Update 3 says, “We revoked all eight intermediates following day,” after describing awareness on 18 October. Following day from 18 October is 19 October. The bug comment places the CRL mark on 18 October at 09:38 UTC, with a reason of caCompromise. Both statements are in the public record. They do not describe the same clock time. A count of sixteen revoked certificates has circulated in secondary writeups. The comments fetched from the bug confirm eight eMudhra-issued certificates marked on the CRL, not a sixteen-certificate CT census, so this account does not repeat that count.

Wayne’s comment, written later on 18 October, also said the eight Sectigo cross-signed copies were still unrevoked at that moment, and that CCADB was still showing the eMudhra-issued copies as unrevoked. A later confirmation that Sectigo revoked those cross-signs is not in the comments used here. Treat the cross-sign status as something to check on the CRL, not as a closed fact.

The disclosure site says the CA has revoked the compromised intermediate certificates, and that many other clients do not consume revocation information. They need a software update before they stop trusting the intermediates. A CRL entry with reason caCompromise does not rewrite a trust store that never fetches that CRL. Go 1.27.3 and Go 1.26.10, released 19 October 2026, make crypto/x509 reject chains that contain the eight intermediates. The Go issue carries CVE-2026-111943. The filter has no documented switch to turn it off, and a binary picks it up only after a rebuild.

Node.js shipped the same class of fix on 21 October 2026 in 22.23.4, 24.22.1, and 26.12.1. The project lists “ca-cert (eMudhra Intermediate CA Compromise)” among the dependency updates in that security release. Python certifi 2026.10.19 drops emSign ECC Root CA – G3 from its bundle. Rust rustls-webpki 0.103.16 and webpki-roots 1.0.10 are the patched releases listed on the disclosure site. The curl CA bundle dated 2026-10-20 is the extract listed there. NSS 3.131.1 removes the root that signed the affected intermediates, which matters for any application that uses Mozilla’s trust store and does not receive OneCRL.

Distro ca-certificates packages on the same list include Ubuntu builds 20260816ubuntu0.22.04.1, 20260816ubuntu0.24.04.1, 20260816ubuntu0.26.04.1, and 20260816ubuntu0.26.10.1; Debian 20250419~deb12u2, 20250419+deb13u1, and 20260816+nmu1; Fedora 2026.2.92_v9.0.319; and Alpine 20261020-r0. Cloudflare learned of the weak keys on 19 October 2026 at about 17:00 UTC and said the cleanup reaches origin servers, API clients, and bundled trust stores, not only browsers. Filippo Valsorda told Ars Technica, in a line carried by The Next Web, that this “will be a massive cleanup job, bigger than Heartbleed,” aimed at the non-browser clients that do not pick up a CRLSet. iTnews reported the same Cloudflare warning: fixing the certificates goes beyond browsers. Those are third-party characterizations of scope. They are not eMudhra’s.

Root-program actions, confirmed and claimed

Mozilla’s own blog is the cleanest root-program primary source. On 17 October at 20:06 UTC it received the report. Engineers blocked the certificates in Firefox through OneCRL. By 22:59 UTC the same day, in less than three hours, the OneCRL distribution was complete for Firefox users with standard settings, without an update or a restart. On 20 October Mozilla released Firefox 158.0.1 for desktop and Android, Firefox ESR 115.43.1, and Firefox ESR 153.5.1, for the minority of users whose settings blocked the OneCRL push. NSS 3.131.1 removes the signing root for other applications on Mozilla’s trust store. On 21 October at 08:29 UTC, Firefox for Android 158.0.2 fixed a case where some clients were not applying the bundled OneCRL blocklist immediately after startup.

Chrome’s actions are confirmed by the Chrome Root Program’s own comments and by Google’s 20 October security post, as reported by The Hacker News and SecurityWeek. The program received the report at 18:05 UTC on 17 October. A CRLSet update, sequence 10843 in Wayne’s timeline, contained the six TLS keys by 22:46 UTC that night. The Hacker News, citing the program, says the CRLSet block of the six TLS intermediates was in place by 19:45 UTC. Chrome did not need to block the two code-signing certificates for website TLS, because its TLS verifier will not build a path through an intermediate restricted to code signing. Google also said it would remove emSign ECC Root CA – G3 from the Chrome Root Store, with the removal scheduled to reach Chrome Root Store users on 27 October 2026.

Mint, summarizing CERT-In advisory CIAD-2026-0050, reports that date as the point at which the root leaves the living Chrome store, to cover consumers of that store that do not consume CRLSet updates. Google has said some legitimate certificates chaining to this root will stop working in Chrome as a result. That 27 October break is a root-removal side effect, not evidence that those sites were issued by the eight weak intermediates. Economic Times flagged the same date as the point after which some legitimate sites may stop working.

Apple and Microsoft are a different category. The disclosure site says the certificates have been blocked on Apple devices since 19 October and on Microsoft platforms since 20 October. The Hacker News attributes those two dates to Jackson’s site, and notes that Apple and Microsoft had not published their own notices in the accounts it checked. Until Apple or Microsoft publishes a notice, treat the 19 October and 20 October platform dates as the disclosure’s claims, not as vendor-confirmed root-program actions. The disclosure also says downstream trust stores were notified on 19 October. That notification date is the site’s claim. Mozilla’s public confirmation post is dated 20 October.

CERT-In advisory CIAD-2026-0050, issued 21 October 2026 and reported by Mint, warned that eight eMudhra intermediate CA certificates were compromised because the private keys were generated with insufficient randomness. The advisory, as summarized there, says Mozilla blocked six affected TLS intermediates through OneCRL and that Google blocked the public keys of the affected TLS intermediates through a CRLSet update. Mint’s summary also lists Firefox ESR 115.45.1, which does not match Mozilla’s own release note of ESR 115.43.1. Use Mozilla’s number for the ESR build.

Reading the 21 October press release

eMudhra’s Update 2, published 20 October, says the incident “is limited to these specific intermediate CA certificates and does not affect eMudhra’s root CA private keys or other intermediate CAs.” It says none of the affected intermediates were deployed in production except one, and that none, including the one in production, “have issued any end-entity certificates,” a claim it says is corroborated by crt.sh. Update 3 repeats the production claim and adds that browser root programs “have also distrusted that one ECC root” as a precaution. The press release says infrastructure “was not compromised,” “no data was breached,” and “all physical and logical security controls remained intact.” It also says the India DSC and eSign businesses have “no connection” with the incident because global TLS “runs on infrastructure that is completely separate.”

Read as scope language, those sentences draw a perimeter around eight intermediates, one ECC root now distrusted by root programs, and a TLS business the company says is about 1 percent of revenue. They do not say that every client which trusted emSign ECC Root CA – G3, emSign Root CS CA – G3, or the AAA Certificate Services cross-signs has been updated. They do not resolve the 18 October versus 19 October revocation clock. They do not, on their own, establish that no client outside a CT-enforcing browser was ever presented with a certificate from these keys. The disclosure does not claim that either. It says the attack was not available to CT-enforcing browsers in the April 2025 to disclosure window, and that the status for other clients is unknown.

The “no infrastructure compromise or data breach” line answers a different question from the one the bug answers. The bug answers whether eight published intermediate keys were recoverable. eMudhra’s answer, that HSMs were used and a wrap/unwrap step published the weak copy, is compatible with a recoverable key and with an intact data center. Compatible is not the same as exhaustive. The company says it has not confirmed the exact root cause and will publish it when the investigation ends. Until that writeup exists, the wrap/unwrap account is the vendor’s working description, not a finished postmortem.

What is not publicly known

A defensive check that does not require the private keys is on the disclosure site. A certificate error from these two requests means the client does not trust the compromised intermediates: curl https://dv-g3b-emudhra.we-have-a-problem.com/ and curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/. A successful TLS handshake shows the client still trusts the chain. That is the result that needs a patch, not a reason to disable verification. The site also lists twelve hosts and an offline chain bundle for trust-store checks. Do not download proof archives or published private keys to confirm the issue. The signatures on the disclosure site and the Mozilla bug are enough to establish key control.

No active exploitation is publicly known. That sentence has a boundary. It means no vendor, root program, or Cloudflare review cited here has published evidence of a forged certificate used in an attack. It does not mean every non-browser client was checked. Open questions that the 21 October statement does not close: whether the Sectigo cross-signs have since been revoked, which customer certificates chain to emSign ECC Root CA – G3 and will break on the 27 October Chrome root removal, and what the confirmed root cause of the wrap/unwrap step was.

Administrators can apply a short audit without treating the disclosure as a census of every client:

• Run the two curl checks above. A clean handshake means that client still trusts a compromised intermediate.
• Rebuild Go services on 1.27.3 or 1.26.10. Move Node.js services to 22.23.4, 24.22.1, or 26.12.1.
• Update Python certifi to 2026.10.19, rustls-webpki to 0.103.16, webpki-roots to 1.0.10, the curl CA extract dated 2026-10-20, and NSS to 3.131.1 or the distro ca-certificates build that pulls that NSS store.
• Confirm Firefox is on 158.0.1 or later, or that OneCRL has applied. Plan for the 27 October Chrome root removal if any certificate still chains to emSign ECC Root CA – G3.
• Do not disable certificate verification to clear the resulting errors. Do not treat “DSC and eSign unaffected” as a finding about TLS clients. That line is the company’s scope claim. The client question is whether the process still trusts one of the eight intermediates.

Related Reading

More in-depth coverage from this blog on closely related topics:

• PHP core RCE: CVE-2026-109618

Sources and References

Sources cited while researching and writing this article:

• eMudhra Intermediate CA Compromise
• 2083449 – Private key compromise of eMudhra Intermediate Certificates
• eMudhra Statement on Recent Certificate Security Incident | eMudhra
• eMudhra Statement on distrust of select Global TLS Intermediate and one Root CA
• Mozilla, Google, Apple block compromised eMudhra CA certificates
• Indian certification authority eMudhra’s private keys compromised – one of them was the number ‘4’
• Eight eMudhra CA Keys Compromised, Triggering Emergency Fixes Across Browsers and Software
• 8 eMudhra certificates are compromised. Here’s what you need to know
• Node.js , Wednesday, October 21, 2026 Security Releases
• Cloudflare warns fixing botched eMudhra certs goes beyond browsers – iTnews
• Browsers Block eMudhra Intermediate CAs Over Recoverable Private Keys
• eMudhra intermediate CA certificates compromised: What happened, who is …