The eMudhra CA Incident: Weak Keys, Revocation, and Your Trust Stores

On October 17, 2026, a researcher known as Wayne reported that the private keys of eight eMudhra intermediate CA certificates were compromised, with proof of key control. Mozilla's incident bug (Bugzilla 2083449) records the report arriving at 20:06 UTC, forwarded by the Chrome Root Program. eMudhra revoked all eight intermediates with reason caCompromise on October 18.

Six of the eight were TLS intermediates (DV, OV, and EV) chaining to emSign ECC Root CA - G3. Two were code-signing intermediates. All eight came from a key generation ceremony on April 30, 2025, and Sectigo had cross-signed them. Sectigo later reported that it had revoked its cross-signed copies.

The keys were not stolen. They were weak. Mozilla wrote that all eight keys "used integers less than 256", so the P-384 private keys could be recovered almost instantly from public data. BleepingComputer verified a key published on GitHub for one intermediate; its value was 4.

An ECDSA private key is a number, and the public key is that number multiplied by a fixed curve point. Going from public key back to private key is infeasible when the number is chosen at random from a range of roughly 2 to the power of 384. When the number is below 256, anyone can try every candidate in well under a second. Mozilla's bug records that the affected keys used integers below 256, which is why they were recovered trivially from the public certificates.

An intermediate CA key that anyone can compute is a key that anyone can sign with. A forged certificate for any domain, signed by one of these intermediates, would chain to a root that browsers trusted. That is the man-in-the-middle risk.

CAA records do not help here. CAA is checked by a CA before issuance. Someone holding the raw key never asks.

eMudhra says its infrastructure was not compromised and no data was breached. It says the keys were generated on FIPS 140-2 Level 3 HSMs, and that a key wrap and unwrap step in the ceremony produced a second, weak set of keys alongside the strong ones. BleepingComputer reported eMudhra's explanation that the weak keys were selected because their labels resembled the correct ones.

eMudhra says seven of the eight were never used in production, the eighth issued no certificates, and certificate transparency logs confirm no end-entity certificates were issued from any of them. eMudhra says the hierarchy passed two independent audit cycles, and that it has not yet confirmed the full root cause. The keys date from an April 2025 ceremony, so roughly eighteen months passed before the report.

No evidence of misuse before disclosure has been reported. The exposure window, though, runs from April 2025, and absence of evidence in CT logs only covers certificates someone chose to log.

If you browse with an updated mainstream browser, the practical answer is: protected. Mozilla distrusted the intermediates through OneCRL on the evening of the report, without a browser restart, and later shipped Firefox 158.0.1 for configurations that had blocked those updates. Chrome blocked the six TLS intermediates. Apple added protections on October 19, per BleepingComputer.

Mozilla went further and removed trust in emSign ECC Root CA - G3 from NSS, in coordination with other root program maintainers. eMudhra says browser root programs distrusted that root as a precaution.

The residual risk is everywhere a browser is not.

Many TLS clients never check revocation. They trust whatever is in their bundle. Language runtimes, package managers, CLI tools, containers, and embedded devices often ship their own CA bundle and update it on their own schedule.

Mozilla's Dennis Jackson warned that macOS's built-in /usr/bin/curl may continue trusting the compromised certificates, because its bundle does not check revocation information. The Go team released 1.27.3 and 1.26.10, tracked as CVE-2026-111943. BleepingComputer's table listed fixed releases for NSS 3.131.1, Python certifi 2026.10.19, pip, uv, rustls webpki-roots, Electron, Composer's ca-bundle, and several Linux distributions, with Node.js, Bun, Debian, and FreeBSD still pending at the time.

Removing the root closes the gap for any client that takes the updated bundle. It does nothing for the copy baked into an image last month.

Work through the trust stores you actually run, not just the ones you think of.

Every CA bundle in your fleet

Container images and appliances

Certificates you serve

Code signing and CT monitoring

A key ceremony is a production deployment of the most sensitive secret a CA owns, and this one shipped a defect that a trivial property check would have caught: is the private scalar in a plausible range? The same lesson applies to any team generating keys in scripts. Validate generated keys before they are used, record which key object was selected and why, and treat label similarity as a hazard. Audits that check procedure documentation did not surface this between the April 2025 ceremony and the October 2026 report.