A correctly generated NIST P-384 private key has vastly more than billions of possible values. These eight had effective security of just 3 to 8 bits, meaning a brute-force attack could exhaust every possibility by testing fewer than 256 values. Eight intermediate certificates issued by India-based certificate authority eMudhra were generated with private key values ranging from 4 to 237, according to reporting by medianama.com.
Intermediate certificates sit between a root CA and the websites your browser trusts. When one is compromised, an attacker who controls the corresponding private key can issue certificates that appear valid for domains within that trust chain, then use them to intercept your traffic and decrypt it without triggering a browser warning.
What Went Wrong
eMudhra attributed the problem to a defect in a wrap/unwrap step during a key-generation ceremony conducted on April 30, 2025. The eight published key values (4, 56, 66, 115, 155, 156, 230, and 237) represent effective security of just 3 to 8 bits, according to medianama.com reporting. A correctly generated P-384 key uses a 384-bit key, making the gap between expected and actual protection almost incomprehensible.
Someone already demonstrated control of at least one key. A public advisory was digitally signed using one of the compromised private keys, according to the GitHub advisory repository, demonstrating control of at least one corresponding private key. eMudhra stated in its incident post that its root CA private keys and other intermediate CAs were not affected, and the company said none of the affected intermediate CAs had issued end-entity certificates, with only one deployed in production.
Who Has Blocked the Certificates
Per the GitHub advisory repository and secondary reporting, the response unfolded as follows:
- Mozilla blocked all eight via Firefox’s OneCRL centralized revocation mechanism.
- Google Chrome distributed blocks around October 17.
- Apple platforms followed around October 19.
- Microsoft completed its block around October 20.
- eMudhra revoked all eight affected intermediate certificates.
“We have a problem here” – Wayne.
Software that embeds its own certificate bundle rather than relying on the operating system’s trust store may not reflect these blocks until it receives a separate update.
Why Your Devices May Still Be at Risk
Linux distributions, containers, VPN clients, IoT devices, and embedded systems often maintain independent trust stores and update on their own schedules. For some unsupported or infrequently updated devices, remediation could take months or longer. Think of it less like pushing a single software patch and more like replacing locks across a building where each floor operates under a different maintenance contract.
Exploitation is not passive. An attacker needs an adversary-in-the-middle position, intercepting traffic, presenting a fraudulent certificate, and re-encrypting the connection before it reaches you. That risk may be greater where an attacker can control or intercept traffic, such as on public Wi-Fi, organizational networks, or state-controlled telecommunications infrastructure.
Signal, WhatsApp, and WireGuard are not affected by this specific eMudhra TLS certificate-chain issue, according to mezha.net reporting, because they use different security architectures that do not rely on TLS for confidentiality in the same way. No evidence of malicious certificates issued with the compromised keys had appeared in certificate-transparency logs at the time of available reporting.
The remediation scope is substantial. Heartbleed, for context, was a 2014 memory-disclosure flaw in OpenSSL that required years of patching across internet infrastructure. This incident involves a different failure: defective key generation rather than a software bug. The cleanup challenge across fragmented, slow-updating systems is nonetheless comparable in organizational complexity.
What to Do Now
If your browser already reflects the blocks from Mozilla, Google, Apple, or Microsoft, your day-to-day browsing is substantially protected. Administrators carry the heavier burden: audit software in your environment that ships its own CA bundle rather than relying on the operating system’s trust store. Review container base images, firmware, and vendor appliances separately, and monitor vendor advisories and certificate-transparency logs for subsequent evidence of misuse. Consider also reviewing how password vaults and credential tools in your environment handle certificate trust.
This incident illustrates what happens when decentralized trust infrastructure fails at a single point. One defective key-generation process, eight certificates, and a remediation effort that could extend well beyond any browser patch cycle.
