4 real? Tracking exploitation and patching of eMudhra's weak keys

Hi everyone, it's Shii-chan! Today I'm covering a surprising certificate investigation from the Cloudflare Blog. It's a technical one.

Cloudflare Blog blog.cloudflare.com

What was announced?

The Cloudflare Blog published a write-up on eMudhra's weak keys: how Cloudflare patched, what evidence it sees of attempted exploitation, and how much of the rest of the Internet remains exposed.

Why it matters

On October 19, 2026, researchers found eight weak eMudhra keys. The affected key was the number 4, out of a 115-digit value that should have been random. The other seven were 56, 66, 115, 155, 156, 230, and 237.

The affected intermediate private keys could be recovered from public certificates almost instantly, so anyone could forge certificates for any domain that an unpatched client not enforcing Certificate Transparency would accept. eMudhra said it is exiting the public CA business and blamed a mistake in a key generation script, which it has not published.

What changes

Patching clients is the most important action. Dennis Jackson's crowdsourced site provides instructions, and macOS developers are directed to specific guidance. Cloudflare customers using WARP or Tunnel should follow the steps in an earlier post.

Dive Deep

Cloudflare's patching:

• Patching of high-impact systems began October 19, and origin-facing Pingora proxies were patched within hours
• An AI-assisted source code analysis finished within four hours and identified other systems trusting the weak keys; high-impact items were patched immediately and lower-impact ones were due by the end of the following week
• As of writing, all high-priority systems are patched, with a small number of low-impact tickets remaining

Evidence of exploitation:

• Pingora logging, rolled out by October 21, recorded about 22,000 handshakes using the weak keys over roughly a week
• About two-thirds were fetches of test sites, and nearly all the rest were origins using self-issued certificates under the weak intermediate; every handshake that verified the certificate was refused
• About 160 handshakes had certificates naming other organizations' domains, some tied to consumer IoT devices; they were created after the leak, some valid for over two years, and looked like servers' default certificates, with several served identically from many Cloudflare locations, so they did not look like interception
• One forged certificate was dated October 20 at 18:19 UTC, less than an hour after Mozilla's bug report became public
• Cloudflare found no evidence the keys were used to intercept its own connections, though it notes targeted interception would not necessarily be visible

Visitor exposure was measured by sending probes from challenge pages to one endpoint with an eMudhra certificate and one with a valid control certificate. About 50 million probes were recorded in the week measured, but results are skewed by likely bots, and only JavaScript-capable clients send probes.

• Modern up-to-date browsers are mostly patched; bots and older browsers are not
• Embedded browsers such as Android WebView still accept the chain at roughly 30 to 40%
• Chrome 150 to 154 on Linux is the one cohort showing a steady decline in acceptance
• Across large networks, more than half of probes still accepted the compromised chain; some patching occurred over the first weekend, but the trend has been flat since
• A new detection on October 29 flagged bot traffic claiming Chrome 150 to 154 on macOS, which shifted classification and made the trend look like patching when it was not

Longer term, Cloudflare points to projects like upki, which would let trust stores be updated quickly with revocation and Certificate Transparency information.

Wrap-up

• eMudhra's intermediate key used the value 4, so private keys could be recovered instantly
• Cloudflare patched high-impact systems within hours and saw about 22,000 handshakes; all that verified the certificate were refused
• No interception evidence was found, but many bots, older browsers, and WebViews remain unpatched
• The fix is to patch clients

This one is for security teams and anyone with embedded browsers or older clients to look after!