Key “4”: Cloudflare measures how much of the Internet still trusts eMudhra’s weak keys

On October 19, 2026, the world learned about eight astonishingly weak keys belonging to the certificate authority eMudhra. Where a 115-digit number was needed for the "combination lock" protecting the Internet, eMudhra picked the number 4. Not four digits — just the number four. The other seven keys were no better: 56, 66, 115, 155, 156, 230 and 237.

The next day Cloudflare described its immediate mitigation and what customers needed to do. Now the company has published a detailed follow-up: what evidence of exploitation it found and how quickly users are patching.

An unprecedented case

Certificate authorities have been compromised before: DigiNotar, TÜRKTRUST, TrustWave. But in those cases key access was limited to a certain set of attackers or organizations. eMudhra is fundamentally different: anyone can recover the intermediate private keys almost instantly from the public certificates themselves. With them, one can mint a certificate for any domain, and any unpatched client that does not enforce Certificate Transparency will accept it.

eMudhra has announced it is leaving the public CA business and blamed a bug in a key generation script, but has not yet shared the script. It also signed a certificate revocation list (CRL) with what may have been a correctly generated key, then "corrected" it by re-signing with the weak key. Plenty remains to be cleared up, including the role of auditors and cross-signers.

Patching Cloudflare

Within hours on October 19, the company patched its Pingora-based proxies, which handle most outbound connections to customer origins, to reject the vulnerable keys. In parallel it ran an AI-assisted analysis of its source code to find every other system trusting those keys, completing it in four hours. At the time of writing, all high-priority systems are patched; the remaining work concerns low-impact systems.

Signs of exploitation

By October 21, logging had been added to Pingora. Over a week it recorded about 22,000 handshake attempts with the weak eMudhra keys. Two-thirds targeted test sites; nearly all the rest went to origins that apparently issued themselves certificates from the compromised intermediate. Every connection set to verify certificates was refused.

About 160 handshakes stood out: their certificates named other organizations' domains, some tied to consumer IoT devices. They were created after the leak, and some were valid for over two years — longer than any public CA may issue. Still, they looked more like servers' default certificates than interception attempts. One forged certificate was dated October 20 at 18:19 UTC, less than an hour after Mozilla's bug report went public. Cloudflare has seen no evidence of its connections being intercepted, though carefully targeted attacks cannot be ruled out.

How many clients are exposed

To test visitors, Cloudflare added probe requests to a fraction of its challenge pages, hitting two domains: one with an eMudhra certificate, the other with a regular one as a control. About 50 million probes were sent over the week. The company cautions that this traffic is heavily skewed by bots, and only clients that run JavaScript send probes.

The findings: up-to-date browsers are mostly patched, while bots and old browsers are not. Embedded browsers such as Android WebView lag behind, with 30–40% still accepting the compromised chain. On large networks, more than half of probes accept it. Patching was visible over the first weekend, then largely stalled. The exception is Chrome 150–154 on Linux, where acceptance keeps falling. As the authors note, bots are just software that needs updates too — and if they are at all representative, the picture is dire.

What to do

Patch. Instructions are collected on Dennis Jackson's crowdsourced website; developers on macOS should pay particular attention. Looking ahead, Cloudflare is pinning hopes on projects like upki: a trust store must be able to receive revocation data and Certificate Transparency keys quickly rather than remain a static list of root CAs.

Source: Cloudflare Blog