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

What it is

Cloudflare's follow-up of about 28 October 2026 on eMudhra's eight weak intermediate CA keys. The keys are the numbers 4, 56, 66, 115, 155, 156, 230 and 237, used where a 115-digit number was expected. Anyone can recover the private keys from the public certificates. Any client that trusts the chain and does not enforce Certificate Transparency will accept a forged certificate for any domain.

The page separates this from earlier CA failures (DigiNotar, TÜRKTRUST, TrustWave), where key access was limited to a few parties.

How it works

Cloudflare added logging to Pingora, its outbound proxy, finishing rollout on 21 October. It counted handshakes where the origin presented a certificate signed by a weak key. It measured client trust separately, using two probe endpoints on challenge pages: ca1.cloudflarecaptcha.com with an eMudhra-signed certificate, and ca2.cloudflarecaptcha.com as a control with a normally signed one. Only clients that run JavaScript send probes.

Probe changes during the test:

• 23 October: the control also served an eMudhra certificate without SCTs.
• 27 October: the G3 cross-sign was added to both endpoints and SCTs removed. ca2 was switched to chain up to the AAA Certificate Services root.
• 27 October: sampling rose from 1% to 10% of challenge pages on non-paying zones.
• 23 to 27 October: a platform rollback left a gap in the data.

Preconditions / Affected

• Clients that still trust the eMudhra chain and do not require Certificate Transparency.
• Android WebView and other embedded browsers: 30 to 40% still accept the chain.
• Bots and old browsers.
• Across large networks (ASNs), more than half of probes still accept the chain, both with and without bot signals. Acceptance has been flat since the first weekend.
• Developers on macOS are singled out as needing to patch.

What to do

• Patch client trust stores. Dennis Jackson's crowdsourced site has per-platform instructions.
• Cloudflare customers using products such as WARP or Tunnel should follow the previous week's Cloudflare post.
• Origin-side or client code that makes outbound TLS can reject these keys, as Pingora did within hours on 19 October.
• To find systems that trust the keys, Cloudflare ran an AI-assisted source analysis that took four hours. It then ticketed each system, with high-impact ones patched at once and the rest due by the end of the following week.

Caveats

• Of about 22,000 weak-key handshakes seen by 28 October, two-thirds were fetches of test sites such as emudhra.we-have-a-problem.com. Most of the rest went to origins that appear to have issued themselves certificates from the weak intermediate. Every handshake set to verify was refused.
• About 160 handshakes carried forged certificates naming unrelated domains, some IoT-related, some valid over two years. One was dated 20 October at 18:19 UTC, under an hour after Mozilla's bug report became public. Cloudflare judges these to be servers' own default certificates, not interception. They would have failed hostname verification, and several were served identically from many Cloudflare locations. Targeted interception is not ruled out, and no compromise signals have been seen.
• Probe traffic is skewed by unconfirmed bots. A detection released 29 October around 18:00 UTC caught a bot influx posing as Chrome 150 to 154 on macOS, which mimics patching in the top graph. Chrome 150 to 154 on Linux is the exception, with falling acceptance, which Cloudflare calls suggestive rather than conclusive.
• eMudhra says a key generation script had a mistake but has not shared it. It is exiting the public CA business. It signed a CRL with what may have been a correct key, then corrected it to the weak key. The roles of auditors and cross-signers remain unexplained.
• Cloudflare points to upki as a way to update trust stores quickly with revocation and CT keys.