A 384-Bit Curve Where the Secret Was Just 4
On Saturday, October 17, 2026, researchers alerted Apple, Google, Microsoft, Mozilla, and Indian certificate authority eMudhra to an alarming discovery: private keys for eight intermediate CA certificates could be broken on a laptop in well under a second.
These certificates used the NIST P-384 elliptic curve. By specification, a private key should be a 384-bit random number chosen from roughly 10^115 possible values. What were the actual private keys? Forty-seven zero bytes followed by a single byte. The eight keys were 4, 56, 115, 155, 156, 230, 66, and 237. One of them was literally 4.
Cracking such keys takes at most 255 point additions on an elliptic curve—taking mere milliseconds on standard commodity hardware. From the 16 certificates attached to Mozilla’s disclosure, researchers reconstructed all eight private keys. In practice, these private keys had been effectively public ever since the certificates were minted in April 2025.
Image: A compromised padlock. Source: Ars Technica
Every Certificate Check Passed: So What Went Wrong?
An HTTPS chain of trust cascades downward from root certificates, with every stage subject to strict validation: compliant curves, valid ASN.1 encodings, and well-formed signature structures. eMudhra’s eight intermediates—six TLS issuing CAs (two generations each of DV, OV, and EV) and two code-signing CAs—were generated in April 2025 and cross-signed that May by Sectigo’s AAA Certificate Services root. Every single check passed.
None of those audits verify that the private key is genuinely random. Private key generation happens entirely within the CA’s custody; external parties only ever see the corresponding public key. The mathematical strength of P-384 guarantees 10^115 possibilities only if the secret is sampled uniformly at random across the field. eMudhra’s catastrophic failure occurred at the one boundary where no automated external test could audit them.
Community discussions suggested a few plausible root causes: a provisioning script passing arguments in the wrong positional order, or code where key[0] mistakenly picked up a single byte of an unwrapped key. Others pointed out a fundamental breach of protocol: keys were supposed to be generated inside a Hardware Security Module (HSM). If they could be generated externally and corrupted so blatantly, the procedural controls were compromised from day one.
Browsers Move Over the Weekend: Four Days of Fallout
On the night of October 17, Google pushed an out-of-band CRLSet update to block the eight certificates, and Mozilla followed hours later with an emergency OneCRL push. By October 20, Mozilla publicly disclosed the incident and stripped eMudhra’s root from the Network Security Services (NSS) bundle; Google confirmed the root’s removal in Chrome Root Store v43.
Why such swift, decisive action? Researcher Ian Carroll summed it up: “They’re essentially 1-byte keys that anyone can factor… the issue cannot be contained.” Because there was no specific breach timestamp, unauthorized parties could have generated fraudulent certificates at any point over the preceding 17 months without detection.
Chrome engineers highlighted an important caveat: these intermediate CAs had never logged issued certificates to Certificate Transparency (CT) logs, meaning rogue certificates would not be trusted by default in Chrome. While CT can detect misissuance, it cannot prevent the signing of forged certificates—and countless non-browser clients never check CT logs at all.
Image: Each tier of the trust chain depends on validation from above, but key entropy at the foundation goes unchecked. Source: Keytos
Why curl | sh Installers Top the Threat Vector List
Mainstream browser users remained largely shielded thanks to emergency revocation lists combined with mandatory CT enforcement. The real attack surface lies entirely outside the browser.
curl, Python, Node.js, Go, Java, git, and various system package managers rely by default on static CA trust stores on disk. Crucially, they routinely skip revocation checks (OCSP/CRL) and never validate CT logs. To these headless clients, revocation notices are ineffective: when reading eMudhra certificates embedded in standard trust bundles, those 8-bit intermediate CAs were still considered valid issuers.
The sharpest risks materialize in two critical environments: first, curl | sh piping installation scripts and auto-update mechanisms, where a spoofed certificate enables immediate arbitrary code execution with user or root privileges; second, CI/CD pipelines, whose build containers frequently hold cloud credentials, package registry tokens, and signing secrets. To pull off a man-in-the-middle attack against these clients, an attacker needed nothing more than a laptop and less than a second of compute.
eMudhra’s Defense and Strategic Exit
On October 22, eMudhra announced its complete withdrawal from the global SSL/TLS certificate market. The company cited three main reasons: global SSL/TLS accounted for roughly 1% of total revenue; compliance overhead and data sovereignty mandates were climbing while automated, free issuers dominated the ecosystem; and “the scrutiny from social media amplification around this incident was disproportionate to the role SSL/TLS plays in our business.” eMudhra maintained that it revoked the impacted intermediates within 14 hours, never issued end-entity certificates from them, and suffered no infrastructure breaches.
The technical community rejected the “disproportionate scrutiny” framing. Observers asked how 17 months could pass without any internal sanity checks noticing the keys lacked entropy. The counterargument circled back to basic operational posture: cryptographic keys should have been minted inside an HSM. Being able to extract them—or botch generation outside hardware—revealed that standard safeguards were ignored from the very beginning.
The Last Line of Defense Is Human—With Zero Automated Safety Nets
Not a single cryptographic algorithm broke down. The curves were sound, the encodings were standard, the data structures were compliant, and the cross-signatures came from trusted giants like Sectigo. Eight certificates survived 17 months of automated conformance tests because no machine check, and no standard compliance audit, ever asked the simplest question: did anyone verify whether the 384-bit private key was actually an 8-bit integer?
The HTTPS chain of trust anchors modern internet security, but verifying the private key quality of intermediate authorities requires deducing it from public keys—which, in eMudhra’s case, took 17 months and an alert external researcher. The security perimeter of PKI ultimately rests on human discipline and verifiable processes, which cannot be audited with a one-line curl command. eMudhra exited the SSL/TLS business to close the chapter, but the next time someone asks “who watches the watchers,” the offending authority might not have the luxury of sacrificing a mere 1% of its revenue.
References:
- Mozilla Bugzilla disclosure and NSS release notes
- Chrome Root Store v43 announcement
- eMudhra global SSL/TLS exit statement
- Commentary by Ian Carroll
- Hacker News discussion (item?id=50177916)
