eMudhra’s Weak CA Keys Push Chrome to Drop a Root

Eight eMudhra intermediate certificates used private keys smaller than 256, and one of those keys was the number 4. A researcher known as Wayne recovered them from the public certificates on 17 October 2026 and proved it by signing “We have a problem here – Wayne” with each key. Chrome and Firefox blocked the certificates that same day.

The eight intermediates are the closed part of the story. Mozilla has already pulled the signing root from its trust store, Chrome will drop that root on 27 October, and language runtimes, container images and command-line tools that never read a browser blocklist still have to be patched one package at a time.

Eight Private Keys Sat in Public View

A private key of this type is meant to be a random P-384 number more than 100 digits long. Each of these eight was an integer smaller than 256, so anyone can find one by testing at most 256 values. Security researcher Scott Helme recovered all eight from the public certificates on a laptop in less than a second.

One of eMudhra’s certificate authority private keys is the number 4. Not a number that starts with 4, or the number 4 followed by a few hundred random digits, just, 4. Another one is 56, and another is 115. I know, because I recovered all of them from their public certificates on my laptop just now, and it took less than a second.

Scott Helme, security researcher

Helme later published the full set. The keys were public from the day the certificates existed, because the public half of each pair was enough to recover the private half. Nobody had to steal anything from a vault.

THE EIGHT WEAK KEYS

Each of those 8 keys also sat in a second certificate cross-signed by Sectigo’s AAA Certificate Services root, so 16 certificates carried the same eight secrets. Chrome’s block matched the public keys themselves, which covered both paths at once. Six of the intermediates were built to issue website certificates. Two were built to sign code and were trusted by Microsoft.

Dennis Jackson of Mozilla’s cryptography team wrote that the private keys were “effectively all-zeroes apart from the last byte” and could be recovered almost instantly. He posted a public checker at emudhra.we-have-a-problem.com so operators can see whether a client still accepts the chains. The company says on its website that it has issued more than 60 million digital certificates over its life. That lifetime total is not a count of certificates at risk in this incident.

A Ceremony Script Handed Staff the Wrong Keys

The eight intermediates came from a batch of 24 created at a key generation ceremony on 30 April 2025, on FIPS 140-2 Level 3 hardware security modules. eMudhra says the modules were in use and that the failure was in the ceremony procedure, not in the absence of hardware.

During the ceremony, a wrap/unwrap step produced a second, weak set of keys beside the strong set. Staff then published the weak set to browser root stores. In a later comment on Mozilla’s incident record, the company said similar key labels led people to pick the wrong pair when they prepared the certificate requests. It also said there were human errors at several steps, and that it would re-check every key ceremony it has carried out.

Sectigo cross-signed all eight in May 2025. The hierarchy entered browser trust lists in mid-2025 and then passed two independent audit cycles. CERT-In, India’s computer emergency team, notes that the global TLS business is subject to Web Trust audits by BDO International Limited. Those audits did not catch keys that a laptop recovered in under a second.

eMudhra says the issue went undetected for about 18 months, from the 30 April 2025 ceremony until the 17 October 2026 report. It is not aware of evidence that anyone recovered or used the keys before disclosure. CERT-In, in advisory CIAD-2026-0050 on 21 October, likewise said public disclosures as of that date do not establish confirmed malicious use. Certificate Transparency logs, which Chrome and other browsers require for publicly trusted website certificates, had no certificates from the six TLS intermediates before Chrome’s block, so those browsers could not have trusted a forged site certificate by default.

Firefox and Chrome Closed the Hole on 17 October

Wayne sent the signed proof to Apple, Google, Microsoft, Mozilla and eMudhra. The Chrome Root Program logged the report at 18:05 UTC on 17 October. Mozilla logged it at 20:06 UTC the same day, after Chrome forwarded it. Both recovered the keys on their own and treated the generation process as trivial to exploit.

THE FIRST FIVE DAYS

1. 17 October 2026, 18:05 UTC: Chrome Root Program receives Wayne’s report.
2. 17 October 2026, 19:45 UTC: Chrome ships a CRLSet update blocking the public keys, with no browser restart required.
3. 17 October 2026, 22:59 UTC: Mozilla’s OneCRL update reaches standard Firefox users, less than 3 hours after Mozilla received the report.
4. 18 October 2026, 09:24 to 09:38 UTC: eMudhra revokes the eight intermediates with the reason CA compromise.
5. 19 October 2026: Apple blocks the certificates. Sectigo revokes the eight AAA cross-signs at 10:35 UTC. Android devices receive an equivalent update through Google Play Services around 22:00 UTC.
6. 20 October 2026: Microsoft blocks the certificates. Mozilla and Chrome post in public. Firefox 158.0.1, Firefox ESR 115.43.1, Firefox ESR 153.5.1 and NSS 3.131.1 ship.
7. 21 October 2026, 08:29 UTC: Firefox for Android 158.0.2 fixes a startup bug that left some phones on the old OneCRL list.

Mozilla said the OneCRL distribution was complete for Firefox users with standard settings by 22:59 UTC on 17 October, without an update or restart. The packaged Firefox and ESR builds cover the minority whose custom settings block that remote list. NSS 3.131.1 goes further: it removes the root that signed the affected intermediates, which protects other applications that use Mozilla’s trust store and never see OneCRL.

Jackson’s concern, once the browsers had moved, was the rest of the internet. Devices and applications with no reliable way to learn that a certificate was revoked can still treat the chains as good. In his words, the impact of this incident could not be higher.

Legitimate Sites on That Root Have Until 27 October

Blocking eight intermediates is a containment step. Distrusting the root above them is a business event. Mozilla has already taken emSign ECC Root CA – G3 out of NSS. Google has removed emSign ECC Root CA – G3 from the Chrome Root Store so that consumers of that store which do not read CRLSet updates lose the root as well.

THE ROOT THAT FOLLOWS THE KEYS

• Chrome date: The root removal is due for all devices on the Chrome Root Store on Tuesday morning, 27 October 2026 PDT, and sooner on Canary and Beta.
• Customer pool: eMudhra has estimated about 30,000 certificates need to move, and in its 21 October statement described the affected TLS impact as one customer ecosystem in the United States.
• What breaks: Some legitimate certificates that chain to emSign ECC Root CA – G3 will stop working in Chrome unless operators install a certificate from another hierarchy in the Chrome Root Store.
• What is still open: The Chrome Root Program is investigating whether eMudhra’s remaining CA certificates stay in the store, and will post further updates on the Common CA Database public list.

Google’s security teams wrote that inclusion in the Chrome Root Store requires a CA owner to keep showing the technical competence needed to protect Chrome users. eMudhra has stopped issuing from intermediates under the G3 root and says it is moving the affected customer onto an alternate publicly trusted hierarchy. It also says the root itself was not weak: the failure was in the eight intermediates, and the root distrust is a precaution. To the best of the company’s knowledge, no other roots or intermediates were generated with the flawed process.

Seven of the eight intermediates were never used in production, eMudhra says, and the one that was in production issued no end-entity certificates. Empty Certificate Transparency records for those six TLS intermediates match that claim for website certificates. Code-signing certificates are not logged the same way, so the two code-signing intermediates do not have that public check.

A separate NSS change dropped two other eMudhra roots, emSign Root CA – C1 and emSign ECC Root CA – C3, after eMudhra asked for that on 19 October under an earlier transition plan. The company says that removal is not part of this incident.

What Still Trusts the Weak Keys

Browsers that enforce Certificate Transparency, and that ingested OneCRL or CRLSet on 17 October, are the easy case. The harder case is everything that ships its own copy of the public roots and never asks a browser whether a CA was pulled. curl on a server, a Go binary compiled last month, a Python virtualenv, a Docker base image and an old Android WebView can still accept a chain the desktop browser next to them would reject.

Helme has already shown how far that gap runs. A forged certificate for a well-known payments API was accepted by curl, Python and Node on Linux and macOS machines that had not yet replaced their root bundles. Jackson’s disclosure site tracks patched packages as maintainers catch up, and the list is long because every language and Linux distribution owns a copy of the same problem.

PATCHES THAT ARE NOT THE BROWSER

• Go: Rebuild with 1.27.3 or 1.26.10, which hard-code a public-key blocklist inside crypto/x509.
• Python: Upgrade certifi to 2026.10.19 inside every virtualenv, and pip to 26.2.2.
• Node.js: 22.23.4, 24.22.1 or 26.12.1.
• OS bundles: Ubuntu, Debian, Fedora, Alpine and Arch have shipped ca-certificates updates; NSS 3.131.1 is the Mozilla-derived store other apps inherit.
• macOS CLI: Safari is protected, but the built-in curl, git and python3 still verify against /etc/ssl/cert.pem, which had not been rewritten to drop the affected roots when the disclosure site published workarounds.

Android 13 and older do not receive Google Play system CA updates, so apps that use a raw WebView, where Certificate Transparency is off by default, can still trust the roots until someone turns emSign and Comodo AAA Services off in the device’s credential settings. Operators who rebuild container images without bumping ca-certificates will keep shipping the old trust list into production.

Cloudflare learned of the keys on 19 October at about 17:00 UTC and said an attacker can create a forged certificate for any domain and use it to impersonate servers to intercept or modify traffic. The company said its review had not found active exploitation on its own services, and it shipped updates for Cloudflare One clients, the 1.1.1.1 app and cloudflared while cutting in CDN and Zero Trust mitigations.

Following the discovery that eight eMudhra intermediate certificates use weak keys, Cloudflare is deploying mitigations and releasing client updates. We explain the impact, our response, and what customers and developers should do next. https://t.co/lYGxHb3PHS

— Cloudflare (@Cloudflare) October 20, 2026

That is the cleanup the browsers cannot finish. Revocation only helps a client that asks. A firmware image from 2025, a frozen CI runner and a language runtime that vendors its own roots will keep trusting a key that was never a secret.

India’s Digital Signature Business Runs on Other Roots

eMudhra Limited is a Bengaluru digital-trust company. Its global TLS intermediates under the ECC G3 root are the ones in this incident. Its Indian Digital Signature Certificate and eSign businesses, which issue signatures under the Controller of Certifying Authorities at the Ministry of Electronics and Information Technology, sit on separate infrastructure.

The company says there is no impact on those Indian services, or on emSigner, emCA, Privatrust and SecurePass. CERT-In’s 21 October advisory draws the same line: the notice covers the browser-trusted international certificates, and the regulated Indian eSign services are not impacted. The weakness, CERT-In added, is in how the keys were generated, not in the P-384 algorithm itself.

eMudhra’s 21 October update says the majority of TLS certificates it has issued chain to other trusted hierarchies and are unaffected, and that it is offering enterprise TLS customers certificates from an additional publicly trusted CA so they can switch if one hierarchy fails. It has not yet published a finished root-cause report. It says it will, and that it intends to add AI-based checks to future ceremonies.

Website operators with certificates that still chain to emSign ECC Root CA – G3 have until the morning of 27 October, Pacific time, to put a different trusted chain on those sites before Chrome stops accepting the old one.