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

On October 19, 2026, we learned about eMudhra’s eight shockingly weak keys: where eMudhra was trusted to pick a 115-digit number for their virtual combination lock protecting the Internet, they picked the number 4. Not even four digits, just the number 4. The other seven keys were similarly weak: 56, 66, 115, 155, 156, 230 and 237.

The next day, we wrote a blog post on the immediate action we took to mitigate this leak, and what customers needed to do on their end to stay secure. Now, we are sharing a more in-depth follow up on the evidence we’ve seen of exploitation, and the progress seen on visitors patching their systems.

Let's start with the scale of the problem. A certificate authority (CA) with weak keys this serious is unprecedented, and the potential consequences are significant. While there have been plenty of compromised certification authorities in the past (such as DigiNotar, TÜRKTRUST, and TrustWave), access to their keys has always been contained to a degree; these incidents gave a limited set of attackers or organizations the ability to issue fraudulent certificates. The eMudhra incident is fundamentally different; the affected intermediate private keys could be recovered almost instantly by anyone from the public certificates themselves. Anyone can independently recover these same signing keys and create certificates for any domain that an unpatched client not enforcing Certificate Transparency would accept.

eMudhra announced they’re exiting the public CA business and have claimed a mistake in a key generation script, but have not yet shared the script. They signed a certificate revocation list (CRL) with what might’ve been a correctly generated key, and subsequently corrected it to be signed with the weak key.

How did that come to be and why didn’t that set off alarms? Much has to be cleared up, including the role of the auditors and cross signers. This blog proposes the fixes and next steps for organizations to ensure they are secure.

Patching Cloudflare

Our primary concern remains the security impact on Cloudflare, our customers, and the Internet as a whole. At the time of writing, all high priority Cloudflare systems have been patched. A small number of confirmed low impact tickets is being worked on.

We started patching high-impact systems immediately on October 19. These included customer origin-facing proxies using Pingora, responsible for most of our outbound connections. These were patched in hours to reject the vulnerable eMudhra keys. At the same time, we started an AI-assisted analysis of our source code to find all other systems that trust these weak keys. Within four hours we had a full analysis. We assigned a ticket with preliminary analysis for each system, and asked the team to confirm and/or adjust the analysis before the end of the day. Where high impact was identified, we asked to patch immediately, and for the lower impact, remediation was due at the end of last week.

Has Cloudflare seen exploitation across its network?

To track whenever a customer’s server (or attacker) presents a certificate signed by eMudhra’s weak keys, we added logging to Pingora. As this outbound service accounts for the vast majority of outgoing TLS connections from a Cloudflare machine, any attacker attempting to snoop using the eMudhra keys would trigger this logging. The logging finished rolling out October 21.

At the time of writing, a week later, we’ve seen about 22,000 attempted handshakes with the weak eMudhra keys. Two-thirds of the attempts were fetches of test sites such as emudhra.we-have-a-problem.com (which we mentioned in the developer guidance in our earlier post). Almost all of the remaining third went to origins who appeared to set up a certificate for themselves using the weak intermediate. Every handshake configured to verify the certificate was refused, as we already patched.

About 160 of these handshakes stood out: the certificates’ Subject Alternative Names (SANs) were naming other organizations’ domains, unrelated to the Server Name Indication (SNI) requested in the handshake. Some of those names were domains related to consumer IoT devices. We noticed as well that those forged certificates were made after the keys leaked and some were valid for over two years, longer than any public CA may issue. However, these certificates looked like the servers' own default certificates rather than part of an attempt to intercept our connections. They named domains other than the ones being connected to, so they would have failed hostname verification anyway. And in several cases, a server presented the same certificate to connections from many of our locations, which means it came from the server itself rather than from something on a single network path.

Thus while there is no evidence of the weak keys being used to intercept Cloudflare's connections so far, these keys appear to have been used to forge certificates within hours of the weakness becoming public: one of the forged certificates we saw was dated October 20 at 18:19 UTC, less than an hour after Mozilla's bug report was made public. This does not exclude carefully targeted interception. For that we have to rely on the usual indirect signals of system compromise — and so far, we have not seen any such signals.

How many visitors are still vulnerable?

So much about patching Cloudflare, but what about our visitors? We cannot directly test whether a visitor still trusts the weak keys without breaking connections, so we have to do something more indirect. For that we used our challenge pages:

We rolled out an update to send out two probe connections on a fraction of challenge pages: one probe to ca1.cloudflarecaptcha.com and one to ca2.cloudflarecaptcha.com. Initially we installed an eMudhra signed certificate on ca1.cloudflarecaptcha.com and a regularly signed certificate on ca2.cloudflarecaptcha.com as control. Then we record whether these probes succeeded. This allows us to see if visitors that are served a challenge page still trust the weak eMudhra keys.

What did we find? With 50 million probes over the last week, we see this:

Big caveat upfront: by design the traffic to these challenge pages is highly skewed. There are many (unconfirmed) bots in there. Also, only clients that execute JavaScript (like browsers) will send probes.

The jump in the data is due to the following changes—all times are UTC:

• October 23 15:30, we changed our control endpoint to also serve an eMudhra certificate, but this time without signed certificate timestamps (SCTs). There were some differences in acceptance, but not large. We could’ve added a new endpoint, but that would’ve required a slow release of our challenge platform. Changing the endpoint was easier.
• October 23 16:30, our challenge platform rolled back to a previous version because of an unrelated issue. The probes returned October 27 at 10:00.
• October 27 16:37, we noticed we did not send the G3 cross-sign, which not all clients knew about, and added it to both endpoints. We removed SCTs from both.
• October 27 16:49, we switched ca2 to chain up to the AAA Certificate Services root.
• October 27 18:18, we ramped up probes to be included from 1% to 10% of all challenge pages served on non-paying customer zones.

With those caveats out of the way: what do we notice? Up-to-date modern browsers are mostly patched, but bots and old browsers are not. Also embedded browsers, like Android WebView, lag behind patching with 30–40% still accepting. Over the first weekend (with the monitoring gap), we see clear evidence of patching, but afterwards we see little movement.

On October 29 around 18:00 UTC, we released a detection that caught a large influx of bot traffic identifying as Chrome 150-154 on macOS. This can look like patching in the top graph, but it is actually a change in traffic classification: the same user agents show a corresponding increase in acceptance among traffic with bot signals detected in the bottom graph.

Chrome 150-154 on Linux is the notable exception: its acceptance continues to decline, consistent with further patching in that cohort. Given the bot-heavy and changing traffic mix, that evidence is suggestive rather than conclusive. Otherwise, we still see little movement.

Breaking down by network (ASN) we see:

Across the large networks, more than half of probes still accept the compromised chain, both among traffic with no bot signals detected (top graph) and traffic with bot signals detected (bottom graph). Over the weekend we saw some patching, but afterwards the trend has been flat.

The big caveat still holds: traffic is skewed by (unconfirmed) bots. But bots are also just software that need security updates. And if they’re in any way representative of overall software updates, then the picture is quite dire indeed.

What can you do?

Patch! Dennis Jackson has a great crowdsourced website with instructions. Especially if you’re a developer on macOS, you want to follow these instructions. If you’re a Cloudflare customer, check out last week’s blog post on what needs to be done on your end when using certain products like WARP or Tunnel.

Looking ahead

At Cloudflare, we have a quick-revocation mechanism in place in some products. To bring it to more systems at Cloudflare and industry, we’re excited about projects like upki that understand a trust store can’t be a static list of root certificate authorities, but needs the ability to be quickly updated with information like revocation and certificate transparency keys. As vulnerabilities are discovered at a faster pace than ever, it is vital that they can be addressed quickly and effectively.