eMudhra's CA keys were eight bits: what broke, what to update

Eight certificate authority keys that browsers and operating systems trusted turned out to be single-byte numbers. One of them is the number 4. If you run software outside the browser that fetches things over HTTPS, such as installers, build pipelines, server-to-server calls and devices, check that its CA bundle has been updated. We read Scott Helme’s analysis in full, and Mozilla’s incident ticket, its public announcement and the researcher’s announcement. This article covers what broke, how browsers responded, who is still exposed and what remains open.

What happened to eMudhra’s CA keys?

The private keys of eight intermediate certificates were trivially recoverable. A researcher identified as “Wayne” reported on Saturday, October 17 that the keys were compromised, according to the researcher’s announcement. Mozilla’s ticket says the report included proof of key control, and Mozilla confirmed it that evening. The eight intermediates are six TLS issuing CAs (DV, OV and EV, in two generations) and two code-signing CAs. Mozilla traces them to a batch of 24 intermediates generated on April 30, 2025, and says all eight affected keys are P-384 keys whose private values were integers below 256. Mozilla’s description: “effectively all-zeroes apart from the last byte.”

How can a CA key be that weak?

Because a private key is just a number, and these numbers were tiny. Helme explains that an elliptic-curve public key is the private number multiplied by a fixed point on the curve. Recovering the private number from the public key is considered impractical only if the number is huge, around 2^384 possibilities for P-384. With a one-byte value there are at most 256, so a search is at most about 255 steps. Helme recovered all 16 keys (eight keys, each in two certificates) from the public certificates on a laptop in under a second:

Nothing about the certificates looks wrong, Helme says: a public key derived from 4 is a valid point, the encoding is correct and structural checks pass. “The only way to find out is to try.” He also notes nobody had to steal the keys. They were effectively public from the day the certificates existed, a window of about 17 months.

What did eMudhra say went wrong?

A flawed key ceremony. In Mozilla’s ticket, eMudhra says the keys were generated on its hardware security modules, and that an approved deviation to test key wrapping created a second key pair onboard, and a code flaw made that pair weaker. Similar key labels led staff to use the weaker keys for the certificate signing request, which the root signed and sent to Sectigo for cross-signing. eMudhra said there were “human errors in multiple steps of the process”, that its RSA issuers followed a different path and are not affected, and that only one of the affected intermediates entered production. The researcher disputes part of that: Mozilla’s summary says eMudhra stated no end-entity certificates were issued from two of the intermediates, but the researcher reported that one DV intermediate was live until it was disabled on October 17. eMudhra also promised to re-verify every key ceremony it has run, and said it verified its other issuers “primarily using mathematical models facilitated by AI.”

What did browsers and trust stores do?

They blocked the intermediates within hours and are removing the root. According to Mozilla’s ticket and announcement:

• Mozilla confirmed the proof at 20:08 UTC on October 17 and blocked the certificates in Firefox through OneCRL at 22:59 UTC. It shipped an NSS update on October 20 removing the root, which protects other users of its trust store, and decided with other root programs to remove trust in emSign ECC Root CA - G3. A Firefox Android issue left some profiles without the updated blocklist, fixed in 158.0.2.
• Chrome blocked six TLS intermediates by SPKI hash through CRLSet the same day. Helme says Chrome confirmed the root will be removed in Chrome Root Store v43.
• Apple blocked the certificates on October 19 and Microsoft on October 20, according to the researcher’s announcement.
• eMudhra revoked all eight intermediates on October 18 with reason “caCompromise”. Sectigo, which had cross-signed several of them, later reported completing revocation of those cross-signs.

eMudhra has stopped issuing from all intermediates under G3. Mozilla’s ticket says about 30,000 certificates need to move, roughly 97% of them issued through ACME, and subscribers are being moved to G1 (RSA) chains, which Mozilla is not removing at this time.

Who is still exposed?

Mostly software that is not a browser. Chrome noted that no TLS certificates chaining to these CAs appeared in Certificate Transparency logs, so browsers that enforce CT would not have trusted forged ones by default. Helme stresses that CT detects misissuance and does not prevent it, and that many clients do not check CT or revocation. He tested a forged certificate for a hostname he controls on his own machines through a local server: curl, Python and Node accepted it with default settings on every Linux and macOS machine he tried, and Windows’ CryptoAPI accepted it unless revocation checking was enabled. His list of exposure includes installers that fetch scripts over HTTPS, CI/CD pipelines, server-to-server API calls, IoT and embedded devices whose CA bundles are frozen until the certificates expire in July 2039, and Windows code signing, where Windows trusts the eMudhra code-signing root directly.

What should you update?

Anything that ships its own CA bundle, and rebuild images once their base layers pick up the change. Helme’s advice is to update the OS ca-certificates package, certifi, Node, Homebrew and similar, then rebuild container images. The researcher’s page lists patched releases for several Linux distributions, Node.js, Go, certifi and curl, with some still pending, and gives manual distrust commands for macOS and Linux that it calls expert-only and not recommended for ordinary users. Check the page for current status before acting. Devices that cannot be updated are the hard part.

What is still unknown?

• Whether anyone exploited the keys. Nobody had to steal them, and Helme says there is no way to know.
• Whether other eMudhra keys are affected. Mozilla could not recover the P-384 keys of two older series and had not examined the RSA keys, and eMudhra’s fuller root-cause analysis was still pending.
• The CRL anomalies. Mozilla’s ticket links the case to invalid signatures on eMudhra’s revocation lists, and the relationship is unresolved.
• How other trust stores will move. Some are removing the root, and the effect on non-Firefox users depends on how quickly sites migrate chains.

What to keep in mind

These are our observations:

• The failure was in key generation, not in the algorithm. P-384 is fine. The keys were not random.
• Revocation does not reach everything. Browser blocklists worked within hours, but non-browser software relies on bundles on disk.
• The AI detail is one person’s account. Helme says that “Claude was able to recover the private keys with a single prompt.” It is his statement in an update to his article, and we did not reproduce it. Given that these values can be found by trying at most 255 possibilities, the finding does not require AI, and the point is the speed with which tools can now check such things.
• It echoes our earlier analysis. See the NIST curve seeds analysis for another case of cryptographic parameters worth checking, and the PHP vulnerability published the same day.

Editorial review: October 21, 2026 (AI). Prepared from Scott Helme’s article (full text, opened in a browser), and from Mozilla’s Bugzilla ticket 2083449, Mozilla’s dev-security-policy announcement and the researcher’s announcement page, each read through a summarizing fetch. We did not open the proof files or the lists of impacted intermediates, test any client, or contact eMudhra, Mozilla or Chrome. Details of the ticket may have changed after our reading.