Skip to content

Vulnerabilities & Patches

Cloudflare learned of eMudhra’s weak keys on October 19, 2026

Cloudflare began patching high-impact systems the day it learned of the weak eMudhra keys.

https://breach-signal.com/vulnerabilities/cloudflare-patches-emudhra-weak-ca-keys/

Share

Key facts

  • The weak private keys were 4, 56, 66, 115, 155, 156, 230 and 237 instead of random 384-bit numbers.
  • Cloudflare learned about eMudhra's weak keys on October 19, 2026.
  • Eight eMudhra intermediate certificates had private keys so weak that anyone could recover them from the public certificates themselves.
  • Security researcher Scott Helme pulled all eight keys from public certificates in less than a second using his laptop.

Cloudflare detected eight eMudhra intermediate certificates whose private keys were so weak that anyone could recover them from the public certificates themselves, and the company began patching high-impact systems immediately after learning of the flaw on October 19, 2026.

eMudhra is a certificate authority based in India. The eight intermediate certificates held private keys that were not random 384-bit numbers but the values 4, 56, 66, 115, 155, 156, 230 and 237. Security researcher Scott Helme pulled all eight keys from public certificates in less than a second using his laptop. A researcher credited only as Wayne reported the problem to browser root programs on Saturday, 17 October, and signed each key with a message identifying himself as proof.

The company said the eight certificates were created during a key generation ceremony on 30 April 2025. eMudhra said a flaw in the ceremony caused a wrap or unwrap step to produce weak keys alongside strong keys, and that the weak keys were the ones published to browser root stores. Google said eMudhra created the keys using too little randomness.

Chrome blocked six website certificates at 19:45 UTC after receiving the report at 18:05 UTC, requiring no user update or restart. Mozilla finished pushing a block to Firefox users at 22:59 UTC after receiving the report at 20:06 UTC, also requiring no user update or restart. Apple blocked the certificates on 19 October and Microsoft blocked them on 20 October. Chrome will drop emSign ECC Root CA – G3 on 27 October, and Mozilla removed the same root from its NSS trust list on 20 October.

Cloudflare learned about eMudhra’s weak keys on October 19, 2026, and started patching high-impact systems immediately. The company first patched customer origin-facing proxies that use Pingora and handle most outbound connections so they block the vulnerable eMudhra keys. On October 30, 2026, Cloudflare had patched every high priority system, while the confirmed low impact tickets that remained open were small in number.

Cloudflare completed an AI-assisted analysis of its source code to find all systems trusting the weak keys within four hours. The company added logging to Pingora to track certificates signed by eMudhra’s weak keys, and the logging finished rolling out on October 21. Cloudflare released updated WARP, 1.1.1.1 and cloudflared clients after learning of the problem on 19 October.

Cloudflare urges administrators to install cloudflared version 2026.10.2 or newer to neutralize risks from the leaked eMudhra intermediate certificate authority private keys. Older cloudflared daemon versions continue to trust the compromised chains blindly, letting adversaries with the private keys forge certificates and impersonate legitimate upstream endpoints. The cloudflared update revokes trust in the tainted intermediate authorities across local and remote tunnel configurations, and dashboard changes cannot substitute for upgrading the daemon binary.

Cloudflare observed about 22,000 attempted handshakes with the weak eMudhra keys. Two-thirds of the handshake attempts were fetches of test sites such as emudhra.we-have-a-problem.com. About 160 handshakes used certificates whose Subject Alternative Names named unrelated organizations’ domains, including some related to consumer IoT devices. Cloudflare saw a forged certificate dated October 20 at 18:19 UTC, less than an hour after Mozilla’s bug report became public.

Cloudflare observed forged certificates valid for more than two years, exceeding the maximum validity a public CA may issue. The company found no evidence that the weak keys were used to intercept its connections and had seen no signals of compromise for targeted interception. As of late morning Tuesday, October 20, no certificate transparency logs showed the compromised keys being used maliciously.

Close-up of metal keys on a keyring under dramatic blue lighting on a wooden surface.
A close-up of metal keys on a ring, symbolizing the weak cryptographic keys at the center of the security issue. Photo by Alan Mok on Wikimedia Commons

Cloudflare used challenge page probes to ca1.cloudflarecaptcha.com and ca2.cloudflarecaptcha.com to test whether visitors still trust the weak keys. The company ran 50 million such probes over the last week. Modern browsers that are up to date are mostly patched, yet 30–40% of embedded browsers such as Android WebView still accept the compromised chain. Probes across large networks still accept the compromised chain with and without bot signals in more than half of cases, and Android devices received the block through Google Play Services on 19 October.

Many non-browser programs skip revocation-list and Certificate Transparency checks, trusting the certificates until updates reach software or bundled root lists. eMudhra signed a certificate revocation list with what might have been a correctly generated key, then corrected it to use the weak key.

An attacker who recovers these signing keys can issue certificates for any domain an unpatched client that does not enforce Certificate Transparency will accept. Filippo Valsorda, a cryptography maintainer for Go, said the cleanup will be massive and bigger than Heartbleed. Valsorda cited a long tail involving IoT devices, Docker containers, forgotten Linux machines and unmaintained CLI tools.

Google said no forged certificate from the six could have worked against clients that enforce Certificate Transparency, such as Chrome. Google examined the remaining keys in its root stores and found no others with that flaw. Ars Technica reported that exploiting the keys requires interception of traffic between two parties and that Signal, WhatsApp and WireGuard are not affected because they do not rely on TLS for confidentiality.

eMudhra announced it is exiting the public CA business and blamed a mistake in a key generation script that it has not yet shared. The company said the incident neither compromised its infrastructure nor breached any data. eMudhra said its Indian digital signature and eSign operations run on separate infrastructure and remain unaffected, and that its global TLS business makes up around 1% of its revenue. eMudhra is issuing replacement certificates to affected customers and continues to investigate the root cause.

Patched versions listed include Go, Python’s certifi, pip, uv and Electron. Patched ca-certificates packages listed include Ubuntu, Debian, Fedora, Arch and Alpine. Node.js, Bun and FreeBSD remained listed as pending on Tuesday.

Was this helpful?

Join the discussion

Please read our Comment Policy before commenting. First-time comments are held for moderation. By posting a comment you agree to our Terms of Use and Privacy Policy, which explain how your name, email address and comment are used.

Your email address will not be published. Required fields are marked *