On October 19, 2026, the technology world learned that eMudhra, a trusted certificate authority, had generated eight extraordinarily weak private keys. Instead of the expected 115-digit number for their cryptographic signing keys, eMudhra produced: 4, 56, 66, 115, 155, 156, 230, and 237. The severity of this flaw cannot be overstated—anyone with access to the public certificates could instantly recover these signing keys and forge certificates for any domain.
The incident differs fundamentally from past certificate authority compromises such as DigiNotar, TÜRKTRUST, and TrustWave, where attackers gained limited access to keys. Here, the intermediate private keys were recoverable almost instantly by the public, meaning any attacker could create fraudulent certificates that unpatched clients would accept. eMudhra has announced its exit from the public CA business and attributed the problem to a mistake in a key generation script, though the script itself has not been released.
Cloudflare's Immediate Response
Cloudflare began patching high-impact systems on October 19 itself. The company's customer origin-facing proxies, built on Pingora and responsible for most outbound connections, were updated within hours to reject the vulnerable eMudhra keys. Simultaneously, Cloudflare deployed AI-assisted analysis of its source code to identify all systems trusting these weak keys. Within four hours, the company had completed a full analysis and assigned preliminary tickets to each affected team, requesting confirmation and remediation by day's end for high-impact systems and by the end of the following week for lower-impact ones.
At the time of writing, all high-priority Cloudflare systems had been patched, with only a small number of confirmed low-impact tickets remaining in progress.
Evidence of Exploitation in the Wild
To detect any attempts to use eMudhra's weak keys against its network, Cloudflare added logging to Pingora, which handles the vast majority of outgoing TLS connections from Cloudflare machines. The logging rolled out on October 21. Within a week, Cloudflare observed approximately 22,000 attempted handshakes using the weak eMudhra keys.
Two-thirds of these attempts involved test sites such as emudhra.we-have-a-problem.com, mentioned in Cloudflare's developer guidance. Nearly all remaining attempts came from origins that had created certificates for themselves using the weak intermediate. Every handshake configured to verify the certificate was rejected, as Cloudflare had already patched.
About 160 handshakes stood out: the certificates' Subject Alternative Names (SANs) referenced domains unrelated to the Server Name Indication (SNI) requested. Some of these names belonged to consumer IoT device domains. These forged certificates were created after the keys leaked and carried validity periods exceeding two years—longer than any public CA is permitted to issue. However, they appeared to be servers' own default certificates rather than interception attempts. They named domains different from those being connected to, which would have failed hostname verification. In several cases, the same certificate was presented to connections from multiple Cloudflare locations, indicating it originated from the server itself rather than from a network path.
While no evidence emerged of the weak keys being used to intercept Cloudflare's connections, the keys were used to forge certificates within hours of the weakness becoming public. One forged certificate was dated October 20 at 18:19 UTC, less than an hour after Mozilla's bug report became public. This does not rule out carefully targeted interception, which would require reliance on indirect signals of system compromise—signals Cloudflare has not yet observed.
Measuring Visitor Vulnerability
Cloudflare cannot directly test whether visitors still trust the weak keys without disrupting connections, so the company employed an indirect method. It rolled out probe connections on a fraction of challenge pages: one to ca1.cloudflarecaptcha.com (initially with an eMudhra-signed certificate) and one to ca2.cloudflarecaptcha.com (with a regularly signed certificate as control). By recording whether these probes succeeded, Cloudflare could determine if visitors still accepted the weak eMudhra keys.
Over the first week, Cloudflare sent 50 million probes. The results revealed a troubling picture: up-to-date modern browsers are mostly patched, but bots and older browsers remain vulnerable. Embedded browsers, particularly Android WebView, lag significantly behind with 30–40% still accepting the weak keys. While clear evidence of patching appeared over the first weekend, movement has been minimal since then.
A significant caveat applies to this data: traffic to challenge pages is heavily skewed toward unconfirmed bots, and only clients executing JavaScript send probes. On October 29 around 18:00 UTC, Cloudflare detected a large influx of bot traffic identifying as Chrome 150-154 on macOS, which could appear as patching in aggregate graphs but actually represents a change in traffic classification. Chrome 150-154 on Linux showed continued acceptance decline, consistent with further patching in that cohort.
Across large networks, more than half of probes still accept the compromised chain, both among traffic with no bot signals and traffic with bot signals detected. Weekend patching occurred, but the trend has remained flat since. Given the bot-heavy and shifting traffic mix, this evidence is suggestive rather than conclusive. However, if bots are representative of overall software update patterns, the picture is dire.
What Organizations Should Do
The primary action is to patch. Dennis Jackson maintains a crowdsourced website with patching instructions, particularly valuable for developers on macOS. Cloudflare customers should review the company's previous blog post on required actions when using products like WARP or Tunnel.
Future Improvements
Cloudflare has implemented quick-revocation mechanisms in some products and plans to expand them across more systems and the broader industry. The company is enthusiastic about projects like upki that recognize trust stores cannot remain static lists of root certificate authorities but must support rapid updates with revocation information and certificate transparency keys. As vulnerabilities emerge at an accelerating pace, the ability to address them quickly and effectively has become essential.