Summary: On October 19, 2026, Cloudflare disclosed that eMudhra had signed certificates with trivially weak keys — one of them literally the number 4. A week later, its follow-up post measures both exploitation and patching. The short version: forged certificates appeared within an hour of the leak, and a large slice of client software still accepts the compromised chain.
Why this incident is different
Compromised certificate authorities have happened before — DigiNotar, TÜRKTRUST, TrustWave — but in those cases the damage was limited to whoever held the keys. Here, the affected eMudhra intermediate private keys could be recovered almost instantly by anyone, straight from public certificates. Anyone can regenerate these signing keys and mint certificates for any domain that an unpatched client not enforcing Certificate Transparency would accept.
eMudhra has announced it is exiting the public CA business and blamed a mistake in a key generation script, but has not published the script. Cloudflare also notes a curious detail: eMudhra signed a revocation list with what looked like a correctly generated key, then corrected it to use the weak one. The roles of auditors and cross signers remain unclear.
What the exploitation data shows
Cloudflare added logging to Pingora, its outbound proxy that handles most of the company’s outgoing TLS connections. Since October 21 it has recorded roughly 22,000 attempted handshakes using the weak keys. About two-thirds were fetches of test sites; almost all of the rest were origins that had set up their own certificates with the weak intermediate. Every handshake configured to verify was refused.
Around 160 handshakes stood out: certificates whose Subject Alternative Names named other organizations’ domains, including consumer IoT names. Some were valid for over two years — longer than any public CA may issue. Cloudflare’s analysis suggests these were servers’ default certificates rather than interception attempts, since they would fail hostname verification and the same certificate appeared across many Cloudflare locations. Still, one forged certificate was dated October 20 at 18:19 UTC, less than an hour after Mozilla’s bug report went public. Targeted interception can’t be ruled out; so far Cloudflare reports no indirect signals of compromise.
The patching picture is uneven
You can’t directly probe visitors without breaking connections, so Cloudflare used challenge pages to send paired test connections — one bearing an eMudhra-signed certificate, one serving as a control. With 50 million probes over the week, the pattern:
- Up-to-date modern browsers are mostly patched.
- Embedded browsers lag badly: Android WebView still accepts the chain 30–40% of the time.
- Bots and old browsers are largely unpatched, and acceptance rates have been flat since the first weekend.
- Chrome 150–154 on Linux is the one cohort whose acceptance keeps declining, though Cloudflare calls that suggestive rather than conclusive given bot-heavy traffic.
One measurement lesson worth stealing: Cloudflare initially mistook a spike of bot traffic identifying as Chrome 150–154 on macOS for patching progress. It was a traffic-classification shift, not updates — the same user agents showed rising acceptance in bot-flagged traffic.
What builders should do
Patch, and not just your laptop. Dennis Jackson maintains a crowdsourced site with per-platform instructions, and macOS developers need explicit steps because the system trust store is involved. If you run Cloudflare products like WARP or Tunnel, their earlier post lists customer actions.
Cloudflare itself finished patching all high-priority systems, having identified every key-trusting system via AI-assisted source code analysis within four hours of disclosure — a template worth copying for your own trust-store inventory. Longer term, they point to projects like upki that treat trust stores as quickly updatable data rather than static root lists.
The uncomfortable takeaway: this is a real test of whether your fleet can revoke trust fast. Embedded browsers and headless bots are the blind spots, and as I covered in the earlier eMudhra builder guide, your dependency chain almost certainly includes software you can’t patch on demand. Check where your outbound TLS verification actually comes from before the next CA incident, not after.