Eight intermediate certificates from eMudhra, an Indian certificate authority listed on the National Stock Exchange and the Bombay Stock Exchange, carried private keys so weak that anyone could recover them in under a second. The discovery has set off a clean-up across browsers, operating systems, cloud services and software packages.
eMudhra certificates are digital and electronic identity credentials issued by eMudhra, a licensed Certifying Authority (CA) in India.
The eight certificates were created on 30 April 2025 at a key generation ceremony. Six were TLS issuing certificates, split between eMudhra BV in the Netherlands and eMudhra Inc in the United States, and two issued code-signing certificates. All eight were cross-signed by Sectigo. eMudhra revoked them on 18 October with the reason "cACompromise", and Sectigo revoked its cross-signed copies a day later on the same ground.
A private key on the P-384 elliptic curve should be a random 384-bit number, which gives 2^384 possibilities. Security researcher Scott Helme found the eight keys instead held single-byte values: 4, 56, 66, 115, 155, 156, 230 and 237. "I recovered all of them from their public certificates on my laptop just now, and it took less than a second," he wrote.
A researcher credited by Mozilla only as Wayne reported the issue to the root programmes on 17 October. He signed the message "We have a problem here - Wayne" with each key to show that he held them. Chrome blocked the six website-issuing intermediates through a CRLSet update by 19:45 UTC the same day, and Mozilla pushed a OneCRL block to Firefox by 22:59 UTC. Neither needed a user update or restart. Apple blocked the certificates on 19 October and Microsoft on 20 October.
In an update on Tuesday, eMudhra said it was investigating an incident involving intermediate CA certificates created at a key generation ceremony in April 2025. The company said the incident did not affect its root CA private keys or other intermediate CAs. None of the affected intermediates was deployed in production except one, it said, and none of them, including the one deployed, had issued an end-entity certificate. It said public certificate transparency records corroborated that finding.
BleepingComputer reported that eMudhra had blamed an error in the script used to generate the certificates. The script produced a second set of weaker keys, which were selected because their labels resembled the intended ones. The Chrome Root Program said no certificate chaining to the six TLS intermediates had reached public certificate transparency logs before its block. Browsers that require such logging could therefore not have accepted a forged certificate.
The clean-up is far from finished. Go released versions 1.27.3 and 1.26.10 on 19 October, tracked as CVE-2026-111943, with the eight keys written into the software as distrusted. Firefox 158.0.1, Firefox ESR 115.43.1 and Firefox ESR 153.5.1 remove the signing root, and Mozilla's NSS 3.131.1 does the same for other programmes that draw on its trust store.
Filippo Valsorda, a cryptography engineer who maintains cryptography code for the Go language, told Ars Technica that the job would be the largest of its kind. "This will be a massive cleanup job, bigger than Heartbleed," he said. Linux distributions were still rolling out updates, he added, and older systems, containers and devices carrying their own copies of trusted certificates would take much longer.
Cloudflare said it learnt of the compromise on 19 October and found no active exploitation of the issue on its services. It released updates for its 1.1.1.1 and WARP clients and for Cloudflare Tunnel. It advised developers not to clear certificate errors by switching off verification, because that removes the protection the updates restore.
Using the keys would require an attacker to sit between a user and a server and relay their traffic. Ars Technica reported that anyone controlling a local network, such as one at a coffee shop or a university, faces far less difficulty. It said the most immediate exposure was for people using VPNs.