Key generation failure and scope
The eight intermediate keys that eMudhra generated were effectively guessable: where a CA is expected to select a 115-digit value, eMudhra chose 4, 56, 66, 115, 155, 156, 230 and 237. Because the private keys can be recovered from the public certificates themselves, the exposure differs from earlier CA incidents such as DigiNotar, TÜRKTRUST and TrustWave, where access was contained to a limited set of attackers. Here anyone can recover the signing keys and mint certificates for any domain that an unpatched client without Certificate Transparency enforcement would accept.
eMudhra has said it is leaving the public CA business and attributes the keys to a mistake in a key generation script, which it has not published. The company also signed a CRL with what may have been a correctly generated key and later corrected it to use the weak key. Questions remain open, including the role of auditors and cross signers.
Cloudflare remediation
Patching began on October 19. Customer origin-facing proxies built on Pingora, which carry most outbound connections, were updated within hours to reject the affected keys. An AI-assisted review of source code located every other system trusting the weak keys, producing a full analysis in four hours. Each system received a ticket with preliminary analysis for the team to confirm or adjust, with immediate patching for high-impact findings. All high-priority systems are now patched, and a small number of confirmed low-impact tickets remain in progress.
Exploitation observed in outbound TLS
Logging added to Pingora, fully rolled out October 21, flags any server presenting a certificate signed by the weak keys. About a week later, roughly 22,000 attempted handshakes had been recorded. Two-thirds were fetches of test sites such as emudhra.we-have-a-problem.com; nearly all of the rest went to origins that appeared to have issued certificates for themselves with the weak intermediate. Every handshake that verified the certificate was refused.
Around 160 handshakes stood out: their SANs named domains belonging to other organizations, some tied to consumer IoT devices, and unrelated to the requested SNI. These certificates were forged after the keys leaked, and some were valid for more than two years, longer than any public CA may issue. They still looked like the servers' own default certificates rather than interception attempts — they would fail hostname verification anyway, and several servers presented the same certificate to connections from many Cloudflare locations, indicating the certificate came from the server, not from a network path.
No interception of Cloudflare's connections has been observed. The keys were nonetheless used to forge certificates within hours of publication: one was dated October 20 at 18:19 UTC, less than an hour after Mozilla's bug report became public. Targeted interception cannot be ruled out; the usual indirect compromise signals have not appeared.
Measuring visitor exposure with challenge probes
Whether a visitor still trusts the weak keys cannot be tested directly without breaking connections, so Cloudflare used its challenge pages:
A fraction of challenge pages send two probes, one to ca1.cloudflarecaptcha.com and one to ca2.cloudflarecaptcha.com. Initially ca1 served an eMudhra-signed certificate and ca2 a regularly signed one as control, and probe success was recorded. Over the past week, 50 million probes produced these results:
The traffic is heavily skewed: challenge pages contain many unconfirmed bots, and only JavaScript-capable clients send probes at all. Changes during the window, all UTC:
- October 23 15:30 — the control endpoint began serving an eMudhra certificate as well, but without SCTs; acceptance differed somewhat. A new endpoint was avoided because it would have required a slow challenge-platform release.
- October 23 16:30 — an unrelated issue caused a rollback of the challenge platform; probes resumed October 27 at 10:00.
- October 27 16:37 — the G3 cross-sign, unknown to some clients, was missing and was added to both endpoints; SCTs were removed from both.
- October 27 16:49 — ca2 switched to chaining up to the AAA Certificate Services root.
- October 27 18:18 — probe coverage rose from 1% to 10% of challenge pages on non-paying customer zones.
Modern, up-to-date browsers are mostly patched; bots and old browsers are not. Embedded browsers such as Android WebView lag, with 30–40% still accepting. Clear patching is visible over the first weekend, the monitoring gap included, but movement afterwards is minimal. On October 29 around 18:00 UTC, a detection caught a large influx of bots identifying as Chrome 150-154 on macOS; this can look like patching in the top graph, but reflects traffic reclassification, with a matching rise in acceptance among bot-signalled traffic in the bottom graph. Chrome 150-154 on Linux declines steadily, consistent with continued patching in that cohort — suggestive rather than conclusive. Network-level results:
At large networks, more than half of probes still accept the compromised chain, both in traffic with no bot signals (top graph) and with bot signals (bottom graph). Some patching occurred over the weekend; the trend is flat since. Bots are also software that needs security updates, and insofar as they reflect overall update behaviour, the picture is poor.
Remediation guidance
Patch. Dennis Jackson maintains a crowdsourced site with instructions at emudhra.we-have-a-problem.com, and macOS developers should follow the Apple-specific page. Cloudflare customers should review the earlier post for the steps required with products such as WARP and Tunnel.
Faster trust updates ahead
Cloudflare already has a quick-revocation mechanism in some products and wants to extend it internally and across the industry. Projects such as upki treat the trust store as more than a static root list, supporting rapid updates with revocation and Certificate Transparency key information. As vulnerabilities surface faster, quick and effective remediation becomes essential.
