Cloudflare tracks eMudhra weak-key exploitation and uneven patching

Cloudflare has published a follow-up on the eMudhra weak-key incident, saying all high priority Cloudflare systems are patched and that it logged about 22,000 attempted handshakes involving the weak keys. Visitor patching is uneven, with modern browsers mostly updated while bots, old browsers and embedded browsers lag. Cloudflare has not seen evidence of the weak keys being used to intercept its connections so far, though it noted carefully targeted interception cannot be excluded.

Tracked exploitation

Cloudflare added logging to Pingora, its customer origin-facing proxy service, to record when a server or attacker presents a certificate signed by eMudhra's weak keys. Logging finished on October 21. A week later, Cloudflare had seen about 22,000 attempted handshakes. Two-thirds were fetches of test sites such as emudhra.we-have-a-problem.com. Almost all of the rest went to origins that appeared to set up a certificate for themselves using the weak intermediate. Every verifying handshake was refused because Cloudflare had patched.

About 160 handshakes stood out because the certificates' Subject Alternative Names named other organizations' domains unrelated to the Server Name Indication requested in the handshake. Cloudflare said those forged certificates were made after the keys leaked and some were valid for over two years, longer than any public CA may issue. They looked like servers' own default certificates rather than an attempt to intercept Cloudflare's connections and would have failed hostname verification. One was dated October 20 at 18:19 UTC, less than an hour after Mozilla's bug report was made public. Cloudflare said this does not exclude carefully targeted interception but it has not seen usual indirect signals of system compromise.

Patching and eMudhra response

Cloudflare started patching high-impact systems immediately on October 19. Pingora proxies were patched in hours to reject the vulnerable keys. An AI-assisted source code analysis was complete within four hours. At the time of writing, all high priority Cloudflare systems were patched and a small number of confirmed low impact tickets was being worked on. Cloudflare said eMudhra is exiting the public CA business and claimed a key generation script mistake but has not shared the script. Cloudflare said much remains to be cleared up, including the role of auditors and cross signers.

Visitor probe results

Cloudflare used challenge pages to probe whether visitors still trust the weak keys without breaking connections. With 50 million probes over the last week, it said up-to-date modern browsers are mostly patched, but bots and old browsers are not. Embedded browsers such as Android WebView lag, with 30 to 40 percent still accepting. Across large networks, more than half of probes still accepted the compromised chain, including traffic with and without detected bot signals. Cloudflare said the traffic is highly skewed by unconfirmed bots and only clients that execute JavaScript send probes, so the evidence is suggestive rather than conclusive. It noted some patching over the first weekend but little movement afterward.

Cloudflare's guidance is to patch. It pointed to a crowdsourced website with instructions by Dennis Jackson, especially for macOS developers, and to its earlier blog post for Cloudflare customers using WARP or Tunnel. Cloudflare also said it has a quick-revocation mechanism in some products and is interested in upki, which treats a trust store as something that can be quickly updated with revocation and certificate transparency information rather than a static list of root certificate authorities.

Earlier coverage: eMudhra exits global TLS certificate business after weak intermediate keys · Eight eMudhra CA Private Keys Compromised, Triggering Emergency Browser Blocks

Sources: Cloudflare