Cloudflare: eMudhra's weak keys used to forge certificates within an hour of disclosure

Eight keys anyone could recover

According to Cloudflare's blog, on October 19, 2026 the company learned that eMudhra, a publicly trusted certificate authority, had eight intermediate keys so weak that anyone could recover the private keys almost instantly from the public certificates themselves. Where a CA is expected to choose a random 115-digit number, Cloudflare says eMudhra's keys were the integers 4, 56, 66, 115, 155, 156, 230 and 237.

Cloudflare describes weak keys this serious at a CA as unprecedented, and argues the incident is fundamentally different from earlier CA compromises such as DigiNotar, TÜRKTRUST and TrustWave, where access to the keys was at least partly contained. Here, anyone could independently recover the signing keys and mint certificates for any domain, which an unpatched client not enforcing Certificate Transparency would accept.

eMudhra has announced it is exiting the public CA business and has blamed a mistake in a key-generation script, but Cloudflare notes the script has not been shared. Cloudflare also highlights that a certificate revocation list was first signed with what may have been a correctly generated key and then corrected to use the weak key, and says the roles of the auditors and cross-signers still need examination.

Forged certificates within an hour

To spot use of the weak keys, Cloudflare added logging to Pingora, the proxy behind most outbound TLS connections from its machines; the logging finished rolling out on October 21. Over about a week it recorded roughly 22,000 attempted handshakes using the weak eMudhra keys. Two-thirds were fetches of test sites, and almost all of the remainder came from origins that appeared to have installed their own certificates under the weak intermediate. Every handshake configured to verify certificates was refused, since Cloudflare had already patched.

About 160 handshakes stood out: their certificates' Subject Alternative Names listed other organizations' domains, some tied to consumer IoT, unrelated to the Server Name Indication requested. Some were created after the leak and were valid for over two years, beyond what any public CA is allowed to issue. Cloudflare concluded these looked like servers' own default certificates rather than interception attempts: they would have failed hostname verification anyway, and in several cases the same certificate reached connections from many Cloudflare locations, meaning it originated on the server itself rather than on a network path.

Forging nevertheless began immediately. One forged certificate Cloudflare observed was dated October 20 at 18:19 UTC, within an hour of Mozilla's bug report becoming public. Cloudflare reports no evidence of the keys being used to intercept its connections and no indirect signals of system compromise so far, but says carefully targeted interception cannot be ruled out.

Cloudflare's own patching

Cloudflare started patching high-impact systems on October 19, beginning with the Pingora origin-facing proxies, updated within hours to reject the vulnerable keys. In parallel it ran an AI-assisted analysis of its source code to locate every other system that trusted the keys, completing the full analysis within four hours. Teams confirmed or adjusted their tickets the same day; high-impact systems were patched immediately and lower-impact ones were due by the end of the week. At the time of writing, all high-priority systems are patched, with a small number of confirmed low-impact tickets still being worked on.

Measuring how many clients still trust the keys

Cloudflare cannot test visitors directly without breaking connections, so it instrumented its challenge pages with two probes: one endpoint serving an eMudhra-signed certificate and one control, recording whether each succeeds. Across 50 million probes over the week, it found that up-to-date modern browsers are mostly patched, bots and old browsers are not, and embedded browsers such as Android WebView lag badly, with 30–40% still accepting. Caveats apply: challenge traffic is heavily skewed toward bots, and only clients running JavaScript send probes. Patching progress was visible over the first weekend, then largely stalled. A shift around October 29 was not patching but a new detection rule catching bot traffic identifying as Chrome 150–154 on macOS, which changed traffic classification rather than client behaviour.

Why it matters

The incident is a rare, measurable case of a public web PKI failure exploitable by anyone, not just well-resourced attackers. Hostname verification and Certificate Transparency enforcement would blunt the forged certificates Cloudflare observed, but the measurements show a long tail of embedded and outdated clients — a third or more of Android WebView in the sample — still trusting the keys, leaving them open to interception. The episode also leaves unresolved questions about CA auditing and cross-signing oversight, since trivially weak keys reached production and stayed trusted until an external report surfaced them.