One of the private keys that secured an intermediate certificate from the Indian certificate authority eMudhra was the number 4. Not a number that started with 4, not the digit 4 followed by several hundred random digits. Just: 4.
Security researcher Scott Helme recovered all eight compromised keys from their public certificates on his laptop in under a second. A P-384 private key should be a random 384-bit number, leaving roughly 10115 possibilities. The values Helme and others found were 4, 56, 66, 115, 155, 156, 230 and 237. The strongest was eight bits.
Mozilla received a report about the compromise on Saturday, October 17, at 20:06 UTC, from a researcher identified only as Wayne. To prove the keys were recoverable, Wayne signed a message reading "We have a problem here – Wayne" with each of the eight keys. Mozilla's engineers independently recovered the keys within two hours.
How the keys got that way
eMudhra is a Bengaluru-headquartered digital trust company, publicly traded on India's NSE and BSE exchanges, that has issued more than 60 million digital certificates. It is one of only a handful of Indian certificate authorities trusted by Chrome, Firefox, Safari and Windows.
The company said in a statement that a flaw in an April 2025 key generation ceremony caused a wrap/unwrap step to produce a second set of weak keys alongside the correctly generated ones. The weak keys were the ones published to browser root stores. The hardware security modules used in the ceremony, made by Utimaco and independently certified to a high security standard, were not at fault. This was a scripting and process error layered on top of functional hardware.
An intermediate CA signs the certificates that websites present to browsers. Anyone holding one of these keys could issue a certificate for any domain that a browser would accept. Combined with the ability to intercept traffic, that means impersonation of legitimate sites and decryption of encrypted communications. No certificate transparency logs showed the keys being used maliciously before the block went into effect, according to Ars Technica.
The response
Chrome received its own report at 18:05 UTC and pushed a CRLSet update blocking all six TLS keys by 19:45 UTC. Mozilla's OneCRL update reached Firefox users with standard settings by 22:59 UTC the same day. Apple and Microsoft also moved to block the certificates. Google has removed emSign ECC Root CA - G3 from the Chrome Root Store, a change expected to reach devices on October 27.
The browser response was fast. The harder problem is everything else. Filippo Valsorda, who maintains the cryptography packages in Go's standard library, told Ars Technica: "This will be a massive cleanup job, bigger than Heartbleed."
Linux distributions, containerized applications, command-line tools, IoT devices and software that bundles its own certificate store do not receive browser-level revocation updates. Dennis Jackson, a member of Mozilla's cryptography engineering team, maintains a disclosure site listing patched versions of Go, Python's certifi, pip, uv, Electron, and the ca-certificates packages of Ubuntu, Debian, Fedora, Arch and Alpine. Node.js, Bun and FreeBSD were still pending as of Tuesday.
India's Computer Emergency Response Team (CERT-In) issued an advisory warning that the compromised keys could be used to impersonate websites and intercept or alter online communications.
VPNs and the long tail
At this early stage, the most immediate threat appears to be for users relying on VPNs, especially in countries where governments might maliciously intercept traffic. Signal, WhatsApp and WireGuard do not rely on TLS for confidentiality and are not affected. End users of many other non-browser applications have no recourse other than to hold off until they receive assurances that updates are in place.
Helme tested a fake certificate he built for Stripe's payments API and found that curl, Python and Node accepted it on every Linux and macOS machine he tried. Separately, he noted that Anthropic's Claude recovered the keys from a single prompt.
eMudhra says the incident is limited to the eight intermediate certificates and does not affect its root CA private keys or any other intermediates. The company has stopped issuing certificates from the affected root and says roughly 30,000 live website certificates will need to be reissued from a different hierarchy. The weak keys sat unnoticed in the wild for about 18 months, and there is no way to determine whether anyone used them against software that skips certificate transparency checks.
