EN PT-BR
← Voltar ao feed
critical technology telecommunications

eMudhra weak CA keys (e.g. the number 4) enable forged certificates; Cloudflare sees 22,000 handshakes and widespread unpatched clients

1 fonte(s) · 1 atualização(ões) · publicado 30/10/2026 14:38 · coletado há 2 dias

Cloudflare reports on the eMudhra incident disclosed on October 19, 2026. Eight intermediate CA private keys were generated with trivially weak values (4, 56, 66, 115, 155, 156, 230, 237), so anyone can recover them from the public certificates and forge certificates for any domain accepted by unpatched clients that do not enforce Certificate Transparency. Cloudflare logged about 22,000 handshakes using the weak keys in the week after October 21. About 160 carried forged certificates naming unrelated domains, one dated October 20 at 18:19 UTC, less than an hour after the Mozilla bug report went public. Cloudflare found no evidence of interception of its own connections and says its high-priority systems are patched. Challenge-page probes show that many bots, old browsers and embedded browsers (30-40% of Android WebView) still trust the weak keys. More than half of probes from large networks still accept the compromised chain.

Detalhes técnicos

  • eMudhra says a key generation script was faulty but has not shared it. It is exiting the public CA business. It signed a CRL with what may have been a correctly generated key, then corrected it to be signed with the weak key.
  • Cloudflare added logging to Pingora, which handles most outbound TLS connections, with the rollout finished on October 21. Every handshake configured to verify certificates was refused.
  • About two-thirds of the roughly 22,000 handshakes targeted test sites such as emudhra.we-have-a-problem.com. Most of the rest went to origins that appeared to have issued their own certificates from the weak intermediate.
  • The ~160 anomalous certificates had SANs naming unrelated organizations, some tied to consumer IoT devices, and some were valid for more than two years. They looked like servers' default certificates, not interception attempts: they would fail hostname verification, and the same certificate was served to many Cloudflare locations.
  • Client trust was measured with probes from challenge pages (50 million probes) to ca1.cloudflarecaptcha.com and ca2.cloudflarecaptcha.com. The data is skewed by bot traffic and only covers clients that execute JavaScript. Modern browsers are mostly patched, while bots and old browsers are not. Chrome 150-154 on Linux continues to patch, and a bot classification change on October 29 distorted the macOS data.
  • Cloudflare used AI-assisted source code analysis to find every system trusting the weak keys, with a full analysis within four hours. High-impact systems were patched on October 19, and a few low-impact tickets remain.

Remediação

  • Patch clients and trust stores to distrust the eMudhra keys. Dennis Jackson's crowdsourced website has instructions, and macOS developers are called out in particular.
  • Cloudflare customers using products such as WARP or Tunnel should follow Cloudflare's earlier guidance.
  • Enforce Certificate Transparency and support fast trust store updates for revocation, as in projects like upki.

Linha do tempo

  1. blog.cloudflare.com ↗ · pub. 30/10/2026 14:38 · coletado 30/10 15:00 primeiro registro

    eMudhra weak CA keys (e.g. the number 4) enable forged certificates; Cloudflare sees 22,000 handshakes and widespread unpatched clients

    ler a análise desta fonte

    Cloudflare reports on the eMudhra incident disclosed on October 19, 2026. Eight intermediate CA private keys were generated with trivially weak values (4, 56, 66, 115, 155, 156, 230, 237), so anyone can recover them from the public certificates and forge certificates for any domain accepted by unpatched clients that do not enforce Certificate Transparency. Cloudflare logged about 22,000 handshakes using the weak keys in the week after October 21. About 160 carried forged certificates naming unrelated domains, one dated October 20 at 18:19 UTC, less than an hour after the Mozilla bug report went public. Cloudflare found no evidence of interception of its own connections and says its high-priority systems are patched. Challenge-page probes show that many bots, old browsers and embedded browsers (30-40% of Android WebView) still trust the weak keys. More than half of probes from large networks still accept the compromised chain.

    Technical Details

    • eMudhra says a key generation script was faulty but has not shared it. It is exiting the public CA business. It signed a CRL with what may have been a correctly generated key, then corrected it to be signed with the weak key.
    • Cloudflare added logging to Pingora, which handles most outbound TLS connections, with the rollout finished on October 21. Every handshake configured to verify certificates was refused.
    • About two-thirds of the roughly 22,000 handshakes targeted test sites such as emudhra.we-have-a-problem.com. Most of the rest went to origins that appeared to have issued their own certificates from the weak intermediate.
    • The ~160 anomalous certificates had SANs naming unrelated organizations, some tied to consumer IoT devices, and some were valid for more than two years. They looked like servers' default certificates, not interception attempts: they would fail hostname verification, and the same certificate was served to many Cloudflare locations.
    • Client trust was measured with probes from challenge pages (50 million probes) to ca1.cloudflarecaptcha.com and ca2.cloudflarecaptcha.com. The data is skewed by bot traffic and only covers clients that execute JavaScript. Modern browsers are mostly patched, while bots and old browsers are not. Chrome 150-154 on Linux continues to patch, and a bot classification change on October 29 distorted the macOS data.
    • Cloudflare used AI-assisted source code analysis to find every system trusting the weak keys, with a full analysis within four hours. High-impact systems were patched on October 19, and a few low-impact tickets remain.

    Remediation

    • Patch clients and trust stores to distrust the eMudhra keys. Dennis Jackson's crowdsourced website has instructions, and macOS developers are called out in particular.
    • Cloudflare customers using products such as WARP or Tunnel should follow Cloudflare's earlier guidance.
    • Enforce Certificate Transparency and support fast trust store updates for revocation, as in projects like upki.