Eight Compromised eMudhra CA Keys Could Let Anyone Forge HTTPS for Any Site

The private keys behind eight certificate authority intermediates were generated with so little randomness that recovering them takes under a second. Every major browser blocked them. The long tail of devices and apps that ship their own trust stores has not caught up.

State of Surveillance

TL;DR: A security researcher credited as Wayne found eight intermediate certificate keys issued by Indian certificate authority eMudhra that were generated with so little randomness that the private keys are whole numbers smaller than 256. One of them was the number 4. Anyone who could try 256 numbers held HTTPS trust for any website on earth. Mozilla, Google Chrome, Apple, Microsoft, the Go programming language, and a long list of Linux distributions blocked the affected certificates between October 17 and October 20. The work is not finished: Node.js, Bun, FreeBSD, Debian, and the version of curl bundled with macOS have not shipped fixes yet.

How Weak the Keys Were

The keys in question were eight intermediate certificates eMudhra had chained under its emSign and AAA Certificate Services roots. The corresponding private keys were generated during a ceremony on April 30, 2025 using FIPS 140-2 Level 3 hardware security modules, the kind of equipment that is supposed to make this kind of failure impossible. Per the incident write-up that BleepingComputer attributed to Mozilla, the eight P-384 private keys "had values smaller than 256," and security researcher Scott Helme said he recovered all eight private keys on his laptop "in under a second." BleepingComputer's Lawrence Abrams reported that one key was the number 4, and that another researcher, Flüpke, had published one of the keys on GitHub; BleepingComputer independently verified that the published key matched one of the revoked certificates [2][3].

The mechanism is what should worry people who do not work in cryptography. TLS, the protocol that puts the padlock in your browser bar, only works because the certificate authority vouching for a website has a private key nobody else can guess. If an attacker can guess the private key, they can sign a certificate that says "yes, this really is your-bank.com" for a site they actually own. Your browser sees a certificate signed by a trusted authority and shows you the padlock. The connection is then not encrypted against the attacker, it is encrypted for them. Anyone able to intercept a connection in the middle could impersonate a site and "potentially read or modify traffic" [1][2].

eMudhra told reporters that the issue came from an error in the script that generated certificates during the April 30, 2025 ceremony, which "produced a second set of weaker keys that were mistakenly selected due to similar labels." The weak set is what shipped to browser root stores. The strong set, the ones that should have shipped, were the ones sitting next to them [2].

What the Browsers Did in Three Days

The browser-side response is the part of this story that worked. Mozilla learned of the compromise on October 17 at 20:06 UTC and pushed the affected certificates into OneCRL, Firefox's centralized revocation list, by 22:59 UTC. That is "in less than 3 hours," with no browser update or restart needed for Firefox users with standard settings. On October 20 Mozilla released Firefox 158.0.1 for desktop and Android, plus ESR 115.43.1 and ESR 153.5.1, to cover the minority of users whose custom configurations might have blocked the OneCRL update. Mozilla also shipped NSS 3.131.1 to remove the emSign ECC Root CA - G3 root that signed the affected intermediates, so applications using Mozilla's trust store are protected even if they cannot receive OneCRL pushes [1].

Google Chrome pushed the six TLS intermediates that were authorized to issue certificates into its CRLSet block by 19:45 UTC on October 17, and plans to remove emSign ECC Root CA - G3 from the Chrome Root Store in version 43, which BleepingComputer said is scheduled to reach devices "on the morning of Tuesday, October 27, Pacific time." Apple blocked the affected intermediates on October 19. Microsoft did the same on October 20. The Go programming language treated the issue as urgent, with Go security team member Roland Shoemaker saying the team learned of the problem on October 19 and "kept the release notes deliberately vague," releasing Go 1.27.3 and 1.26.10 to fix CVE-2026-111943. Go's filter in the standard library rejects any chain containing the compromised keys, with no setting to turn it off, and Go 1.25 and older are unsupported [2][3].

That left a long list of software stacks the affected roots had propagated into: Ubuntu (ca-certificates 20260816 patches across 22.04, 24.04, 26.04, and 26.10), Arch Linux (ca-certificates-mozilla 3.131.1-1), Gentoo (20260816.3.125), Alpine (20261020-r0), Chainguard, Python certifi 2026.10.19, Composer ca-bundle 1.6.0, Electron 44.9.1, the curl CA bundle dated 2026-10-20, Rust webpki-roots 1.0.10, and Homebrew ca-certificates 2026-09-25_1, all shipping or having shipped during the three-day window. Cloudflare fixed WARP, the 1.1.1.1 client, and cloudflared in version 2026.10.2 [2][3].

The Long Tail That Did Not Catch Up

The browser side is largely closed. The trust store side is not. Dennis Jackson, the Mozilla cryptography engineer who runs the incident tracking site emudhra.we-have-a-problem.com, is still tracking open issues, and the list of software that has not caught up is longer than the list of software that has. Node.js was pending a draft pull request (PR #66871) as of October 20. Bun and FreeBSD's ca_root_nss were pending. Debian ca-certificates was pending. Dennis Jackson also warned that macOS's built-in /usr/bin/curl "does not check revocation information," so Apple has not pushed a fix that updates the underlying certificate bundle file macOS's curl consults. Filippo Valsorda, the Go cryptography maintainer, made the structural point bluntly: "Linux root stores are too poorly maintained for revocation to reach applications," which is why his team filtered the keys in code rather than trusting downstream stores to catch up [2][3].

This is the part of the story that turns a keygen bug into a surveillance story. A padlock in your browser bar means two things: that the certificate presented by the server is trusted, and that no authority on earth would sign such a certificate for the wrong site. Both held because certificate authorities protected their private keys. Eight of those keys were not protected, and the protection gap lasted from April 30, 2025 until October 17, 2026, when Wayne reported the issue. For more than a year, anyone who could guess numbers below 256 could have minted a trusted certificate for your bank, your email provider, your VPN endpoint, anything reachable over HTTPS. The keys did not need to leave eMudhra's network. The keys "were generated with so little randomness" that nobody needed to steal them [2].

Chrome's response, and Mozilla's, blocks the immediate danger for browser users. It does not close the gap for the IoT devices, point-of-sale terminals, industrial controllers, and embedded routers that ship with a baked-in trust store and never hear from a certificate revocation list. Those devices are now operating against a trust root whose private keys had a year of being effectively public. No Certificate Transparency log has surfaced a malicious certificate issued under the affected keys, which is what researchers want to see, but absence of evidence is not evidence of absence for a key that took under a second to recover [2].

What This Means for the Web

eMudhra said in its October 21 BSE filing that the global TLS business "accounts for around 1% of the company's revenue," with a stock drop of about 20% in Mumbai following the disclosure. The company has revoked the eight certificates, stopped issuing under its G3 root while the ceremony script is being fixed, and given replacement certificates to affected customers. Mozilla does not believe other CAs are affected. Chrome "checked every other CA certificate" and found no others with the same failure mode, which limits the blast radius to this one ceremony [2].

The structural lesson is not about eMudhra. It is that the entire web's encrypted-by-default posture rests on a small number of private keys held by a long tail of certificate authorities, and the trust assumption collapses in a useful way only when the affected organization admits the problem, the browsers ship the revocation, and every application trust store catches up. The eMudhra case is what a fast, well-coordinated response looks like. The slow version, where a CA hid a key compromise for months or years, is the version in which encrypted web traffic becomes silently readable to whoever got the keys first. The trust recovery plan for browsers took three days. The trust recovery plan for the long tail of software packages and devices that need their own bundles and updates is going to take considerably longer.

This fits a pattern we have been tracking in the Chrome zero-day pipeline and in the browser-trust gatekeeping issue: a small number of decisions made by a small number of vendors determine whether the browser in your hand tells you the truth about the site on the other end. When that decision system breaks, the failure is silent, total, and only visible when somebody like Wayne points it out.

What to Watch

The Chrome Root Store 43 cutover on October 27. That is when the root that signed the compromised intermediates gets pulled from Chrome's embedded store, which is the moment that closes the gap for Chrome users who did not pick up the CRLSet push. Anything relying on its own trust store will not be covered.

macOS curl in particular. The /usr/bin/curl binary in macOS still trusts the affected intermediates. Apple has not shipped a fix for the bundle file macOS curl reads. Apple users running scripted HTTPS jobs have not been protected even if their browser was.

The pending Linux trust stores. Debian, FreeBSD, Bun, and Node.js were pending fixes as of the Mozilla write-up. Each is its own ecosystem with its own update cadence, and the applications pulling from those stores inherit whatever is in them.

Whether anyone else has the same key-ceremony failure. Chrome says it audited every other CA certificate and found nothing. That audit is the kind of work that should keep happening, because if one script written for one ceremony produced this failure, the same pattern can exist elsewhere.

Sources

  1. Mozilla Security Blog, Firefox Security Team - Protecting Firefox users following the compromise of eMudhra intermediate certificates (October 20, 2026). https://blog.mozilla.org/security/2026/10/20/protecting-firefox-users-following-the-compromise-of-emudhra-intermediate-certificates/
  2. BleepingComputer, Lawrence Abrams - Mozilla, Google, Apple block compromised eMudhra CA certificates (October 20, 2026). https://www.bleepingcomputer.com/news/security/mozilla-google-apple-block-compromised-emudhra-ca-certificates/
  3. The Hacker News - Eight eMudhra CA Keys Compromised, Triggering Mass Browser Blocking (October 20, 2026). https://thehackernews.com/2026/10/eight-emudhra-ca-keys-compromised.html