Eight intermediate certificate-authority keys belonging to eMudhra, an Indian certificate authority trusted by every major browser, turned out to hold private-key values of 4, 56, 66, 115, 155, 156, 230 and 237. A correctly generated NIST P-384 elliptic-curve key is a random 384-bit integer: one of roughly 2^384 possibilities. These had 47 bytes of zeros followed by one real byte, cutting the search space to 2^8, or 256 guesses. Security researcher Scott Helme recovered all eight from their public certificates on his laptop, he wrote, in under a second apiece. Anyone holding one could mint a certificate for any website, any bank, any software update server that a browser would accept without complaint, as Ars Technica’s Dan Goodin reported.
An intermediate CA is the certificate a browser actually checks when it verifies a website: the browser trusts a small set of root certificates baked into its code or operating system, the root signs an intermediate, and the intermediate signs the certificate a server presents. Compromise the intermediate’s private key and you can sign a certificate for any domain, and every browser trusting the root accepts it as genuine.
The eight keys — six for TLS website certificates and two for code signing — were generated in a single ceremony on April 30, 2025, on Utimaco hardware security modules rated FIPS 140-2 Level 3. eMudhra told Mozilla the ceremony used an approved deviation to test exporting keys for EU/US data-sovereignty purposes, and a flaw in the generation script caused the HSM to produce a second, far weaker keypair alongside the correct one. Because the weak keys carried labels similar to the real ones, they were mistakenly signed into the certificate request. Two weeks later, Sectigo cross-signed all eight under its AAA Certificate Services root, bringing the total number of live certificates to sixteen.
The flaw surfaced because a researcher using the handle Wayne was testing scanning tooling against the CCADB corpus — the public registry every root program uses to track every certificate authority’s certificates — and hit a break in the elliptic-curve keys at 16:27 UTC on October 17. By 18:05 UTC, Wayne had signed the message “We have a problem here — Wayne” with each of the eight recovered keys and emailed the proof to Apple, Google, Microsoft, Mozilla and eMudhra simultaneously, according to Mozilla’s incident bug. Chrome’s CRLSet blocked the six TLS keys by 19:45 UTC. Mozilla acknowledged the report by 20:08 UTC, independently recovered the same keys by 21:48 UTC without being told Wayne’s method, and had Firefox’s OneCRL revocation list distributed by 22:59 UTC — under three hours from report to fix, Mozilla’s security blog wrote. eMudhra revoked all eight certificates the next morning. Sectigo followed October 19; Apple and Microsoft began blocking that weekend. Go’s maintainers, assigned CVE-2026-111943, shipped Go 1.27.3 and 1.26.10 with roughly 30 lines that hard-reject any certificate chain containing one of the eight key hashes — no opt-out.
How practical the attack was is not hypothetical. Helme used one recovered key, value 4, belonging to “EM OV TLS CA - G3C”, to forge a certificate for api.stripe.com and tested it against default-configured curl, Python and Node on Linux and macOS, plus Windows’s CryptoAPI. All accepted the forged chain unless revocation checking was explicitly on, and even then Windows caught it only some of the time. One code-signing intermediate is trusted directly by Windows for executables, so software signed with that key would have displayed as legitimate from a verified publisher. Helme also reproduced the recovery with a single prompt to an AI coding agent pointed at the public certificate.
The silver lining: Certificate Transparency, the public log system that Chrome, Firefox, Edge and Safari require before trusting a web certificate, shows zero entries ever logged against any of the eight CAs across roughly 18 months, according to an independent technical write-up. No CT-enforcing browser could have been attacked through ordinary website TLS. That says nothing about software that does not enforce CT: curl-piped installers, CI/CD pipelines, server-to-server API calls, embedded devices with frozen firmware. As Helme put it, the private key was “effectively public from the day the certificate existed” — anyone who inspected the certificate could have derived it, and no log would show whether anyone did.
The fact that multiple unrelated people recovered the same keys within days — Flüpke, another researcher, published the value-4 key on GitHub — pushed Mozilla and Chrome past simple revocation. Both are removing the entire root underneath these intermediates, “emSign ECC Root CA - G3”, rather than trusting eMudhra to keep it clean. eMudhra says that forces roughly 30,000 certificates still chaining to that root to migrate to its RSA-based “emSign Root CA - G1” chain; about 97% were issued via the automated ACME protocol, leaving roughly 900 needing manual reissue.
None of eMudhra, Mozilla, Sectigo or Chrome had published a formal root-cause incident report three days after revocation — the ceremony detail came out piecemeal in eMudhra’s comments on Mozilla’s bug tracker. The same write-up flagged that eMudhra had filed close to ten incident reports with root programs since mid-September 2026 and disclosed seven previously unreported subordinate CAs, part of why Mozilla had already moved from a gradual phase-out of eMudhra’s roots to outright removal, independent of this key failure.
Filippo Valsorda, who maintains Go’s cryptography code and worked on its emergency patch, told Ars Technica this would be “a massive cleanup job, bigger than Heartbleed.” That comparison deserves pressure-testing. Heartbleed, the 2014 OpenSSL bug, affected roughly 500,000 of the internet’s secure web servers — about 17% of all TLS-certified servers at the time — and recovery stretched over months. On raw count, eMudhra’s incident is smaller by five orders of magnitude: eight keys against half a million servers. What makes Valsorda’s claim plausible is who must act. Heartbleed required server operators to patch. This requires every piece of client software keeping its own list of trusted roots to update it — browsers, language runtimes, container base images, embedded firmware — while affected server operators do nothing. “Every time you need a lot of different people in different contexts to do something, it will take a long time,” Valsorda said. “This time it’s worse because there’s more contexts, more people, and more heterogeneity.” He described Linux distributions’ root-certificate handling bluntly: “a pile of PEM files behind a dumpster.”
As of the community-run patch tracker, most major ecosystems have shipped fixes: Go, Python’s certifi and pip, NSS, curl’s CA bundle, Rust’s webpki-roots, Electron and the Ubuntu, Debian, Arch, Fedora, Gentoo, Alpine and Chainguard distributions. FreeBSD’s ca_root_nss package, Node.js and Bun remained unpatched as of October 21. Valsorda’s worry is the untracked tail: “IoT devices, Docker containers, forgotten Linux machines, unmaintained CLI tools that shipped their own copy of the roots” — routine in ecosystems like Python’s, where vendoring a certificate bundle inside an application is standard. That tail is why Cloudflare warned customers against simply disabling certificate verification when software throws errors over the distrusted roots.
The industry spent the past year moving opposite to this failure mode: shorter-lived certificates mean less time for any one bad key to matter, part of the logic behind Let’s Encrypt’s 64-day certificates starting in February. None of that helps when the weak key sits one level up, in an intermediate CA meant to last until 2040. CT logs, scanned continuously, have shown nothing yet. Whether that remains true after eighteen more months, or after someone checks firmware on industrial sensors not updated until the 2030s, is the number nobody can currently put on this incident.