Cloudflare Tracks eMudhra Weak Keys: About 22,000 Handshake Attempts, No Evidence Its Connections Were Intercepted

Cloudflare published a follow-up on October 30, 2026, to the eMudhra certificate-authority incident it disclosed earlier in October. The affected eight intermediate signing keys were so weak that anyone could recover them from public certificates; Cloudflare illustrates the problem with one key whose private value was 4 rather than an unpredictable 115-digit number. This update distinguishes forged certificates, attempted TLS handshakes and demonstrated interception. Those are different observations and must not be counted as four actual attacks because of the post's rhetorical title, “4 real?”

Cloudflare says it began patching its own high-impact systems on October 19. Pingora, which handles most outbound connections to customer origins, was updated within hours to reject chains using the weak keys. An AI-assisted code review identified other systems in four hours; owners then confirmed impact and patched high-priority paths. At publication all high-priority Cloudflare systems were patched, while a small number of confirmed lower-impact tickets remained. That is a statement about Cloudflare's systems, not proof that every client on the Internet had updated its trust store.

Logging on Pingora finished rolling out October 21. In the following week, Cloudflare observed roughly 22,000 attempted handshakes involving the weak eMudhra keys. Around two-thirds were accesses to test sites that the company itself had mentioned; nearly all of the rest involved origins apparently serving certificates they had set up themselves. Every handshake in this set that was configured to verify the certificate was refused by Cloudflare's patched systems. The number is an attempted-handshake count, not a count of victims, unique sites or successful attacks.

About 160 handshakes stood out because the forged certificates' Subject Alternative Names listed other organizations' domains that did not match the requested Server Name Indication. Some certificates were made after disclosure and lasted longer than the maximum permitted for public-CA certificates. Cloudflare says these looked like servers' own default certificates: the mismatched names would fail hostname verification, and some servers presented the same certificate to Cloudflare locations on different networks. One forged certificate was dated October 20 at 18:19 UTC, less than an hour after Mozilla's public bug report. This shows rapid forgery, but Cloudflare reports no evidence that the weak keys intercepted its connections and says targeted interception cannot be ruled out.

To estimate how many visitors might still trust the bad chain, Cloudflare put two probe connections on a fraction of challenge pages and measured whether they succeeded. It reports about 50 million probes over a week. This is a selected, JavaScript-running and bot-heavy challenge-page sample, not a representative survey of all Internet users. The probe design also changed: the control certificate, certificate-transparency timestamps, a G3 cross-sign and root chain were adjusted on different days; probes disappeared during an unrelated platform rollback and returned October 27; and exposure increased from 1% to 10% of eligible challenge pages. These changes can create graph jumps independently of client patching.

Within that sample, Cloudflare says current mainstream browsers were mostly patched, while older browsers, bots and embedded browsers lagged. It reports that roughly 30–40% of Android WebView probes still accepted the compromised chain. Among large networks, more than half of the probes in the displayed breakdown still accepted it, including traffic with and without bot signals. A classification change for traffic claiming Chrome 150–154 on macOS on October 29 made a plotted decline look like patching; a corresponding increase appeared in the bot-signal group. The Linux cohort's decline is consistent with patching, but the shifting mix prevents a causal population estimate. Cloudflare urges affected users and customers to update their trust stores and products, and calls for faster revocation mechanisms. The follow-up is an incident observation and guidance, not an independent measurement of the whole Web.