Eight private keys belonging to India's eMudhra certificate authority were weak enough to recover from public certificates. Within three days of the first report, Chrome, Firefox, Apple and Microsoft had moved to block the certificates those keys could sign. Some non-browser software is still catching up, which keeps the story active.
What happened to the eMudhra private keys
A researcher identified as Wayne reported the compromise of eight eMudhra intermediate certificate authority keys to root program teams on October 17, 2026. To prove control, Wayne signed a message with each of the eight private keys, according to Cybersecurity News and a community disclosure page.
The sources do not agree on the exact time of that report. Mozilla's account, as The Register relayed it, puts the community report at 20:06 UTC. Google's Chrome Root Program account gives 18:05 UTC, according to the Google Security Blog. Heise reports only "around 6 p.m. German time." The sources reviewed for this story do not reconcile those figures, so this article does not pick one.
Why weak certificate authority keys are a trust problem
A certificate authority vouches for websites. An intermediate CA signs the certificates that websites present, so anyone holding one of its keys could issue a certificate for any site a browser accepts, according to The Hacker News. That makes this a different kind of incident from a stolen-password breach. The attack class is impersonation.
Six of the eight intermediates issue TLS certificates for websites. The other two are used for code signing, according to Help Net Security. All eight came from a batch of 24 intermediates generated on April 30, 2025. eMudhra says it has issued more than 60 million digital certificates, as The Register reported.
Mozilla warned that network interceptors could use fraudulent certificates to impersonate trusted sites and read or alter user data, as CoinDesk reported. For someone on a hostile network, that is the scenario that matters most. The affected intermediates chain to roots trusted by Mozilla, Microsoft, Apple and Chrome, which is why the response reached operating systems as well as browsers.
The cost of a trust failure like this falls unevenly. Browser makers can push blocks through their own update channels. Developers and administrators whose tools pin their own trust stores have to find the problem themselves and fix it on their own schedules.
How the keys were recovered and what eMudhra says
Google's teams said on October 20 that the keys were generated with too little randomness, so anyone can compute them from public certificates. In that account, the keys were not stolen. Researcher Scott Helme said he recovered all eight private keys from the public certificates.
According to Help Net Security and SOCRadar, the keys can be recovered in under a second. Each is a P-384 value below 256, roughly eight bits of strength. Helme's description of one key was short. "One of eMudhra's certificate authority private keys is the number 4," he wrote, as CoinDesk quoted him. Other reported key values include 56, 115, 66, 155, 156, 230 and 237.
eMudhra offers its own explanation. On October 21 it said a flaw in the April 2025 key ceremony produced a second, weak set of keys, and that this weak set is what was published to root stores. That account has not been independently verified.
The wording is contested. CoinDesk's headline says the keys were "cracked," but Cybersecurity News writes that the public disclosures do not establish a seconds-long cracking method. For most readers the practical difference is small. The keys should be treated as public, and the fix is the same either way: remove trust in the certificates they can sign.
Which browsers and operating systems blocked the certificates
| Date (2026) | What happened |
|---|---|
| October 17 | Researcher reports the compromise to root program teams |
| Within hours | Chrome and Firefox block the eight certificates after Chrome verifies the findings |
| October 19 | Apple blocks the certificates |
| October 20 | Microsoft blocks the certificates; Google says the keys lacked randomness |
| October 21 | eMudhra attributes the weak set to a flaw in its 2025 key ceremony |
Chrome gave the most technical detail. It said no TLS certificate chaining to the six website-facing intermediates had been logged to Certificate Transparency before the block. That means none could have been trusted by default in Chrome or other browsers that require Certificate Transparency, according to The Hacker News.
Mozilla said its browsers would stop relying on the certificates, but that users may need to install an update first. That caveat is the reason the browser blocks are not the end of the story. eMudhra has revoked the intermediate certificates.
What US users and IT teams should do now
Most people running current Chrome, Firefox, Safari or Edge are protected by the browser blocks, according to the sources. The steps below are general guidance, not a checklist from any single advisory.
- Update Chrome, Firefox, Safari and Edge, and install pending operating system updates on Windows, macOS and Linux.
- Developers running Node.js should move to 22.23.4, 24.22.1 or 26.12.1, the fixed versions listed by SOCRadar, depending on their release line.
- Check whether Bun and FreeBSD have shipped fixes. Both were still pending as of October 21.
- Confirm that internal tools, build pipelines and container images use current root stores. Check whether anything in your stack accepts eMudhra-issued certificates.
- Verify that your software checks revocation lists. Revocation is the main remedy, and it only works where software checks it.
Linux administrators face the sharpest version of the revocation problem. Some Linux root stores are poorly maintained, so revocation may not reach applications there. Check whether your distribution's trust store package has been updated, and do not assume a browser block covers a command-line client or a script.
The timing also matters. Microsoft's record October Patch Tuesday fixed 1,413 flaws, according to The Hacker News. USA 24 has already covered Chrome 156's 353 security fixes and emergency PHP patches this month. IT teams triaging several patch waves should put certificate trust on the same list.
What remains unresolved and what comes next
Several points are still open. How the keys became weak has not been confirmed, and eMudhra's account has not been independently verified. eMudhra had not responded to The Register's inquiries at the time of that report. No confirmed malicious use had been reported as of October 21.
Three developments are worth watching. First, whether eMudhra publishes a fuller account of the April 2025 key ceremony and whether an outside auditor reviews it. Second, whether Bun and FreeBSD ship fixes, and how far non-browser software actually lags behind the browser blocks. Third, whether Linux distributions push root store updates quickly enough to close the gap.
The broader question for other certificate authorities is whether their own key generation has been checked this closely.
