On October 17, a security researcher reported to Apple, Google, Microsoft, Mozilla and eMudhra that eight intermediate certificate authority private keys had been compromised. The discovery revealed a critical flaw: the keys were not properly randomized.
According to security researcher Scott Helme’s analysis, eMudhra’s private keys for elliptic-curve P-384 certificates consisted of single bytes preceded by 47 bytes of zeros. One key was simply the number 4, another was 56, and another was 115. A properly generated P-384 private key should be a random 384-bit number, offering roughly 10^115 possibilities. Instead, each of eMudhra’s keys had only 256 possible values.
This meant anyone with access to the public certificates could recover the corresponding private keys in less than a second. Helme verified this by extracting all eight keys from the public certificates and brute-forcing them—a process that required at most 255 computational steps per key.
The eight compromised intermediates included six TLS-issuing CAs (for Domain Validation, Organization Validation, and Extended Validation, two generations each) and two code-signing CAs, all created in April 2025. All eight were also cross-signed by Sectigo’s AAA Certificate Services root in May 2025.
Browsers moved quickly to mitigate the issue. Chrome pushed a CRLSet update blocking the certificates on October 17, and Mozilla blocked them in Firefox via OneCRL hours later. By October 20, Mozilla announced the compromise publicly and shipped an update removing the eMudhra root from Firefox, while Chrome confirmed the root would be removed from Chrome Root Store v43.
However, the impact extends far beyond browsers. Most non-browser TLS clients—including curl, Python, Node, Go, Java, git, and package managers—do not check Certificate Transparency or revocation by default. According to Helme’s testing, software like curl and Python accepted forged certificates signed by the compromised intermediates when tested against a spoofed api.stripe.com domain.
The vulnerability particularly affects curl installers, CI/CD pipelines holding cloud keys and registry tokens, server-to-server API calls for payments and webhooks, IoT and embedded devices with frozen certificate bundles, and Windows code-signing trust chains. Helme notes that the compromise “cannot be contained” because the weak keys were effectively public from the moment the certificates existed in April 2025—a 17-month window during which anyone examining the certificates could have recovered the keys.
Key facts
- Eight eMudhra intermediate CA private keys were single-byte numbers (4, 56, 115, 155, 156, 230, 237, 66), making them trivial to crack in milliseconds
- A proper P-384 elliptic-curve private key should offer roughly 10^115 possibilities; eMudhra’s offered only 256
- The compromised intermediates included six TLS-issuing CAs and two code-signing CAs created in April 2025 and cross-signed by Sectigo in May 2025
- Non-browser TLS clients (curl, Python, Node, Go, Java, etc.) do not check Certificate Transparency or revocation by default, leaving them vulnerable to forged certificates
- The weak keys were effectively public from April 2025, creating a 17-month window during which anyone could have derived them