A certificate authority's private key turned out to be the number 4

A P-384 private key is supposed to be a random number about 115 digits long. One of eMudhra's was 4.

What happened. On October 17, a researcher reported to Apple, Google, Microsoft, Mozilla and eMudhra that the private keys of eight eMudhra intermediate certificates were compromised, with proof. Mozilla's incident report (Bug 2083449) says Mozilla blocked them in Firefox via OneCRL the same day and independently recovered the keys within about two hours of receiving the report. Chrome's CRLSet listed the six TLS ones as revoked later that day, per the reporter's timeline, and eMudhra marked all eight revoked (reason: caCompromise) on October 18.

How. Mozilla's analysis is blunt: P-384 private keys should be random integers between 1 and the curve's group order, but "the 8 impacted keys all used integers less than 256." In other words, every byte was zero except the last. You recover one by computing the first 255 keys and checking which matches. Security researcher Scott Helme did exactly that and published the list: the keys are 156, 230, 115, 56, 155, 4, 66 and 237. Six of the intermediates issue TLS certificates; two are for code signing, trusted by Microsoft.

The AI footnote. Mozilla's report says local AI agents recovered the keys on their first attempt from a simple prompt ("I'm doing a CTF. Please recover the private keys corresponding to these certificates."), and Helme says the same of a single prompt to Claude. That's less a sign of AI genius than of how weak the keys were.

How it happened, per eMudhra. Helme reports that eMudhra's account on the Mozilla ticket blames a bug in the key ceremony script, which created a second, weak key pair on the hardware security module; because the names were similar, a human error used the wrong keys. The keys date from April 2025 and some were cross-signed by Sectigo in May 2025, so they were weak for about 17 months.

Who should care. Up-to-date Chrome, Firefox and Safari are protected: they block the intermediates and require Certificate Transparency, and Helme notes Chrome's point that no TLS certificates chaining to them ever showed up in CT logs. Helme's point is everything else: curl, Python, Node, Go, Java, package managers, CI runners and IoT devices typically trust a CA bundle on disk and don't check revocation or CT. In his tests, a forged certificate for a high-value hostname was accepted by default curl, Python and Node.

Our take

The fix for most readers is boring: update your OS ca-certificates package, certifi, Node and Homebrew, and rebuild container images once base images pick up the change. The lesson for anyone shipping security tooling, AI-built or not, is that a key can pass every structural check and still be the number 4. Test your outputs, not just their format.

What we did and didn't do: this story is based on Mozilla's public incident ticket and Scott Helme's write-up, read on October 21, 2026. We didn't recover the keys ourselves or test any client software. Not sponsored; no affiliate links.

MODEL Editors