Cloudflare reports 22,000 attempted handshakes involving eMudhra’s weak keys - Internet, networks and telecom

Cloudflare says it has patched all high-priority systems against eMudhra certificates generated with eight exceptionally weak private keys. The company found signs that forged certificates were created soon after the issue became public, but no evidence so far that the keys were used to intercept its connections.

Cloudflare has published an update on the exploitation and remediation of eight eMudhra intermediate private keys that could be recovered from public certificates. The keys included values such as 4, 56, 66 and 115, making it possible for anyone to derive the corresponding signing keys and create certificates that vulnerable clients might accept.

The company says all high-priority Cloudflare systems have now been patched. Its customer origin-facing proxies, which handle most outbound connections, were updated within hours of the issue being identified on October 19, 2026. Cloudflare then used an AI-assisted review of its source code to locate other systems that trusted the weak keys and assigned remediation work based on their potential impact.

To monitor possible abuse, Cloudflare added logging to its Pingora outbound service. During the week after the logging rollout, it recorded about 22,000 attempted TLS handshakes involving certificates signed with the affected eMudhra keys. Around two-thirds involved test sites, including emudhra.we-have-a-problem.com. Most of the remaining attempts came from origins that appeared to have configured certificates signed by the weak intermediate.

Approximately 160 handshakes involved certificates whose Subject Alternative Names referred to domains unrelated to the requested Server Name Indication. Some were associated with consumer Internet of Things devices. Cloudflare said these certificates appeared to have been created after the weakness became public, with at least one dated October 20 at 18:19 UTC, less than an hour after Mozilla’s report was published.

However, the company said the evidence does not currently indicate that the certificates were used to intercept Cloudflare connections. The certificates often appeared to be servers’ own default certificates, used names that would not have passed hostname verification, and in several cases were presented from multiple Cloudflare locations. Cloudflare also reported no indirect signs of a targeted interception campaign.

The company separately measured how many visitors still trusted the compromised certificate chain. It used two probe connections on a portion of its challenge pages: one endpoint served an eMudhra-signed certificate and the other initially acted as a control with a regularly signed certificate. Over the following week, Cloudflare collected 50 million probes, while warning that the results were affected by bot traffic and included only clients capable of executing JavaScript.

The measurements indicated that current mainstream browsers were largely patched, while older browsers and embedded browsers remained more exposed. Cloudflare estimated that 30% to 40% of Android WebView traffic still accepted the affected chain. More than half of the probes from several large networks continued to accept it, although the company noted that the traffic mix was heavily influenced by unconfirmed bots and that the data should be treated as suggestive rather than conclusive.

Cloudflare urged users and developers to install the relevant updates, with particular attention for developers using macOS. The company also pointed customers to guidance for products such as WARP and Tunnel. Looking forward, Cloudflare said it wants faster mechanisms for updating trust decisions, including broader use of systems that can distribute revocation and Certificate Transparency information without relying on static trust stores.

Sources: Cloudflare Blog.