eMudhra CA keys compromised due to critically weak private key generation

On October 17, 2026, a security researcher reported to major technology companies that the private keys for eight eMudhra intermediate certificates had been compromised. The vulnerability stemmed from an extreme weakness in key generation, where the private keys were effectively single-byte integers. By October 20, Mozilla and Google had publicly announced the revocation of these certificates and removed trust for the associated root authorities.

What happened

The incident involves eight intermediate certificates issued by eMudhra, created in April 2025. These included six TLS issuing certificates for Domain Validation, Organization Validation, and Extended Validation, as well as two code-signing certificates. All eight intermediates were also cross-signed by Sectigo’s AAA Certificate Services root in May 2025. Upon receiving the report, Chrome deployed a CRLSet update to block the intermediates on the same day, while Mozilla blocked them in Firefox via OneCRL shortly after.

By Tuesday, October 20, Mozilla published a public announcement and shipped an NSS update that removed the eMudhra root entirely. Google confirmed that the eMudhra root would be removed from the Chrome Root Store in version 43. The core issue was not a theft of keys in the traditional sense, but a failure in the generation process that made the private keys trivially easy to derive from the public certificates.

The private keys for these certificates were found to be incredibly small numbers, such as 4, 56, and 115. In elliptic-curve cryptography, specifically on the P-384 curve used here, the private key is a large random number. The security of the system relies on this number being sufficiently large to make brute-forcing impossible. However, eMudhra’s keys consisted of mostly zeros followed by a single non-zero byte. This reduced the search space to just 256 possibilities, allowing anyone with access to the public certificate to recover the private key in milliseconds on standard hardware.

Key details

• Eight intermediate certificates were compromised, including six for TLS and two for code signing.
• The private keys were single-byte values, such as 4, 56, and 115, instead of the required 384-bit random numbers.
• Recovery of the private keys from public certificates took less than a second on commodity hardware.
• The affected certificates were created in April 2025 and cross-signed by Sectigo in May 2025.
• Major browsers like Chrome and Firefox have revoked trust, but many non-browser clients remain vulnerable.
• The window of exposure spans from April 2025 until the revocation in October 2026, with no way to determine if the keys were exploited.

Background

To understand the severity, it helps to know how elliptic-curve cryptography works. A private key is a secret number, often denoted as d. The public key, which is shared openly in certificates, is derived by multiplying this secret number by a fixed point on the curve. While calculating the public key from the private key is easy, reversing the process to find the private key from the public key is computationally infeasible if the private key is large and random.

For P-384 curves, the private key should be a 384-bit number, offering roughly 10¹¹⁵ possible combinations. This vast search space ensures security. However, if the private key is small, such as a single byte, there are only 256 possible values. An attacker can simply try each value until they find the one that matches the public key. This is what happened with eMudhra’s keys, rendering the cryptographic protection useless.

Why it matters

While modern browsers like Chrome, Firefox, and Safari are protected because they enforce Certificate Transparency and quickly update their blocklists, the broader ecosystem is at risk. Many non-browser applications, including command-line tools like curl, programming language runtimes like Python and Node.js, and package managers, do not check Certificate Transparency logs or revocation lists by default. They rely on local trust stores that may not be updated immediately.

This creates a significant risk for server-to-server communications, CI/CD pipelines, and IoT devices. For example, a script downloading updates over HTTPS using a stale certificate bundle could accept a forged certificate signed by the compromised eMudhra keys. This would allow an attacker to intercept traffic, inject malicious code, or steal sensitive data. Devices with frozen firmware, such as routers and smart appliances, may continue to trust these invalid certificates until their hardware is replaced or manually updated, potentially years from now.

What you can do

• Update the CA certificate bundles on all servers, workstations, and container images immediately.
• Check for updates to language runtimes like Python, Node.js, and Go, which often bundle their own certificate stores.
• Review CI/CD pipelines to ensure they use up-to-date base images and verify certificate validity strictly.
• Identify IoT and embedded devices that cannot be easily updated and assess the risk of them trusting compromised CAs.
• Enable strict certificate revocation checking where possible, though note that many clients do not support this by default.
• Monitor for any unusual activity in systems that rely on TLS connections to external services.