Browsers Block eMudhra After Eight CA Keys Exposed
Eight eMudhra CA certificates were revoked after researchers found the private keys trivially recoverable. All major browsers have pushed revocation updates.
Dave "Kilobaud" FerrisThe trust chain that keeps HTTPS working depends on one assumption: that CA private keys are, in fact, private. For eight eMudhra intermediate certificate authority certificates, that assumption was wrong for roughly 18 months.
A researcher discovered in mid-October that eight eMudhra intermediate certificates carried P-384 private keys generated in April 2025 with values smaller than 256. One key had a value of 4. At that level, an attacker needs to test at most 256 numbers to recover the key outright. eMudhra attributed the problem to a script error that produced a weaker set of keys, which were then mistakenly selected for signing.
The eight certificates spanned TLS domain-validated, organization-validated, and extended-validation issuance, plus code signing. The specific intermediates included EM DV TLS CA - G3B and G3C, EM OV TLS CA - G3B and G3C, EM EV TLS CA - G3B and G3C, and EM OV CS CA - G3B and G3C.
What the browsers did
Chrome blocked six of the compromised intermediates via a CRLSet push at 19:45 UTC on October 17. Firefox’s OneCRL received its block the same day; Mozilla released Firefox 158.0.1 on October 20 addressing CVE-2026-113470. Apple added protections on October 19. Microsoft followed on October 20.
The coordinated speed is consistent with how browsers handled the Chrome CRLSet mechanism in recent high-severity certificate events. CRLSet allows Chrome to push revocation data without a browser update, which matters when the window between discovery and block needs to be tight.
Mozilla has also announced removal of the emSign ECC Root CA - G3 from NSS, which anchors the affected intermediates. Chrome plans to drop the same root in version 43. A root removal reaches further than an intermediate block: any certificate issued under that root that hasn’t been replaced will stop working once the removal ships.
What’s still unknown
Mozilla stated publicly that “it is not known how the keys left eMudhra, when, or whether anyone besides the researcher holds them.” The certificates were live since April 2025, so there is an 18-month period during which a sufficiently motivated party could have tested those key values independently. No evidence of active exploitation has been reported; most of the affected certificates were never used in production. But that absence of evidence is not the same as a clean bill of health, and it’s worth noting in the same breath.
There’s a version of this story that’s a cautionary note about automated key generation pipelines with insufficient validation, which is not a new failure mode. The specific parameters that make a P-384 key secure are well-documented. Tooling that can emit a private key with value 4 without raising an error is tooling that should have caught the error before a certificate ever got signed.
What admins need to do
Browser users: your browser handles revocation automatically via CRLSet or OneCRL updates. No action required if you’re on a current release.
Systems with independent trust stores require direct attention. Go programs compiled before version 1.27.3 or 1.26.10 carry stale root data and need to be rebuilt (CVE-2026-111943). Python’s certifi, Rust’s webpki-roots, Alpine Linux, and Ubuntu have all released corresponding updates. Any infrastructure running Go-based TLS or using a custom certificate bundle should treat this as a patch event, not a background update.
If your organization issued server certificates from eMudhra under the affected intermediates, check with your CA contact about replacement timelines before the root removal in Chrome 43 makes the question more urgent.
Sources: BleepingComputer, The Hacker News
Found this useful? Share it.
