Cloudflare published a follow-up on October 30, 2026 detailing exploitation and patching after it learned on October 19 of eight weak keys belonging to the certificate authority eMudhra (Cloudflare). The company reported about 22,000 attempted handshakes using the keys and found no evidence so far of them being used to intercept its connections (Cloudflare). It also reported that at least one forged certificate appeared within hours of the weakness becoming public (Cloudflare).
Key Facts
| Item | Detail | Source |
|---|---|---|
| Weak keys | Eight keys, using the numbers 4, 56, 66, 115, 155, 156, 230 and 237 | Cloudflare |
| Handshakes logged | About 22,000 attempts with the weak keys | Cloudflare |
| Unusual certificates | About 160 handshakes named unrelated domains | Cloudflare |
| Cloudflare patching | All high-priority systems patched | Cloudflare |
| eMudhra status | Exiting the public CA business | Cloudflare |
Timeline
- 2026-10-19: Cloudflare learned of the weak keys and began patching high-impact systems (Cloudflare).
- 2026-10-20: A forged certificate was dated 18:19 UTC, less than an hour after Mozilla’s bug report was made public (Cloudflare).
- 2026-10-21: Logging for eMudhra-signed certificates finished rolling out in Pingora (Cloudflare).
- 2026-10-23: Cloudflare changed its control endpoint to also serve an eMudhra certificate, this time without signed certificate timestamps (Cloudflare).
- 2026-10-30: Cloudflare published its follow-up on exploitation and patching (Cloudflare).
Details (as Reported)
Cloudflare described the weakness as unprecedented for a certificate authority, because the affected intermediate private keys could be recovered almost instantly by anyone from the public certificates themselves (Cloudflare). Where eMudhra was trusted to pick a 115-digit number, it picked the number 4 (Cloudflare). Any unpatched client that does not enforce Certificate Transparency would accept certificates for any domain created with the recovered keys (Cloudflare).
On its own systems, Cloudflare patched customer origin-facing proxies using Pingora within hours to reject the vulnerable keys (Cloudflare). An AI-assisted analysis of its source code found all other systems trusting the weak keys within four hours, and lower-impact remediation was due at the end of last week (Cloudflare). A small number of confirmed low-impact tickets are still being worked on (Cloudflare).
Two-thirds of the logged handshakes were fetches of test sites, and almost all of the rest went to origins that appeared to have set up a certificate for themselves using the weak intermediate (Cloudflare). Every handshake configured to verify the certificate was refused (Cloudflare). About 160 handshakes carried certificates naming other organizations’ domains, some related to consumer IoT devices, and some were valid for over two years, longer than any public CA may issue (Cloudflare). Cloudflare judged that these looked like the servers’ own default certificates and would have failed hostname verification anyway (Cloudflare).
To gauge how many visitors still trust the weak keys, Cloudflare sent two probe connections on a fraction of its challenge pages and recorded 50 million probes over a week (Cloudflare). It cautioned that the traffic is skewed, contains many unconfirmed bots, and only includes clients that run JavaScript (Cloudflare).
eMudhra announced it is exiting the public CA business and attributed the problem to a mistake in a key generation script (Cloudflare). It signed a certificate revocation list with what might have been a correctly generated key, then corrected it to be signed with the weak key (Cloudflare).
What Is Not Yet Confirmed
- eMudhra has not yet shared the key generation script (Cloudflare).
- The role of the auditors and cross signers remains to be cleared up (Cloudflare).
- Cloudflare noted that the absence of evidence does not exclude carefully targeted interception (Cloudflare).
- Cloudflare cannot directly test whether a visitor still trusts the weak keys without breaking connections (Cloudflare).