1 NOV 2026 — Forged web certificates made with eMudhra's weak signing keys appear to have been in use within hours of the flaw becoming public, Cloudflare said on 30 October, and many devices still trust the compromised chain. The Indian certificate authority has now admitted the mistake was its own and has appointed KPMG to review the incident. In mid-October a researcher showed that eight of eMudhra's intermediate signing keys could be recovered by anyone, and the major browsers withdrew trust within days.
Both companies are careful to separate forgery from attack. Cloudflare says it has found no evidence that the keys were used to intercept its own connections. eMudhra says it is "not aware of any evidence that the weak keys were recovered or exploited by anyone before the issue was disclosed". The forgeries Cloudflare saw were all made after that disclosure.
How eight keys became public property
A certificate authority vouches for websites by signing their certificates, and browsers accept anything that chains back to a key they trust. Each of the eight affected eMudhra keys should have been a random number below the order of the P-384 curve. Instead, Mozilla wrote in its incident bug, "The 8 impacted keys all used integers less than 256." By Cloudflare's list the smallest was 4 and the largest 237; the others were 56, 66, 115, 155, 156 and 230.
We checked the scale of that gap ourselves. The P-384 group order published in the SEC 2 curve standard is a 116-digit number when written out in decimal, so about three in four properly chosen keys would also run to 116 digits. Cloudflare's post describes the proper choice as a 115-digit number. Either way, the real keys had at most three digits.
Mozilla received the report at 04:06 on 18 October, Singapore time, and had blocked the certificates for standard Firefox installations by 06:59. At 21:06 on 20 October it announced the emergency removal of the eMudhra root above them, after learning that several people had recovered the keys independently. Chrome said the same day that it would follow.
What Cloudflare saw on its network
Cloudflare added logging to Pingora, the proxy that makes most of its outbound connections, and finished rolling it out on 21 October. In the week that followed it counted about 22,000 attempted handshakes using the weak keys. Two-thirds were fetches of test sites. Most of the rest went to servers whose owners seemed to have issued themselves certificates from the weak intermediates.
About 160 stood out because the certificates named other organisations' domains. By our arithmetic, that is roughly 0.7% of the total (160 divided by 22,000). Some were valid for more than two years, longer than any public authority may issue. One was dated 18:19 UTC on 20 October, or 02:19 on 21 October in Singapore, which Cloudflare says was less than an hour after Mozilla's bug became public.
Cloudflare does not read those 160 as an attack on itself. The certificates looked like servers' own defaults and named the wrong domains, so they would have failed hostname checks. In several cases, one server showed the same certificate to many Cloudflare locations. "This does not exclude carefully targeted interception," the company adds, though it has seen no signs of compromise.
Too many clients have not patched
The harder finding concerns visitors. Cloudflare sent about 50 million test connections from its challenge pages over a week, pointing one at a server carrying an eMudhra-signed certificate. "Up-to-date modern browsers are mostly patched, but bots and old browsers are not," it reports. Embedded browsers lag: 30–40% of Android WebView clients still accepted the chain. On the large networks, over half the probes still accepted it, and after some patching over the first weekend the trend went flat.
eMudhra admits fault and appoints KPMG
In a leadership note dated 26 October on its incident page, eMudhra wrote: "The flaw was ours." It blamed an error in a script, apologised to customers and promised a full root-cause analysis, to be filed through the CCADB process the root programs share. Its earlier account, on 21 October, had placed the problem in a key wrap and unwrap step of the generation ceremony. Cloudflare notes that the script itself has not been shared.
On 28 October the company said the roughly 30,800 certificates under the affected G3 hierarchies belong to one client ecosystem, now moved to its G1 root, and that it will end G1 TLS issuance after that. On 30 October it named KPMG as "independent external reviewer". In eMudhra's words, the review is meant to "bring clarity on the incident". It has not yet reported any findings.
Chrome calls its block emergency containment
On 27 October, at 23:16 Singapore time, the Chrome Root Program wrote that its block was "emergency containment, not the end of our work". Its regular scans had missed the keys because those tools did not then test for very small curve keys, and because the intermediates had never issued a certificate logged to Certificate Transparency. Chrome has since added those checks. Because Chrome requires such logging, it says, the keys could not have been used against its users "covertly without entering CT monitoring pipelines". It also said a pending eMudhra application for a new root has been denied.
What readers should do
Update your browser, and on Android also update Android System WebView, since Cloudflare found embedded browsers such as WebView lagging behind. Its sample is skewed towards bots, which it notes need updates too. Its data points to old browsers and bots as the likeliest software to still trust the keys. eMudhra says its digital-signature and eSign services were not affected.
View author profile → · Editorial policy
