eMudhra's eight compromised TLS intermediate certificates: browsers block them, the long cleanup begins

Eight intermediate TLS certificates issued by India-based certificate authority eMudhra were found to have private keys so weak that anyone could recover them in moments and use them to forge a trusted certificate for any website. Browser makers blocked the certificates within days, but the harder job is just starting: every operating system, programming language runtime, container image and device that carries its own copy of the trusted-certificate list has to be updated, and some had not been when the story broke on 20 October 2026.

Key points

• Eight eMudhra intermediate CA certificates had private keys with values below 256 (the published example is the number 4), so each key can be recovered by trying a few hundred numbers (Mozilla incident report, via BleepingComputer; Ars Technica).
• Whoever holds such a key can sign certificates that browsers and apps trust for any domain, but exploiting this needs an active adversary-in-the-middle position on the network path (Ars Technica).
• Mozilla and Chrome blocked the certificates on 17 October, Apple on 19 October and Microsoft on 20 October, according to the tracking site run by Mozilla's Dennis Jackson.
• eMudhra says a script error in April 2025 created a second, weaker set of keys that were picked for signing by mistake; it says it has found no evidence of misuse (BleepingComputer).
• Patches are listed for Go, NSS, Python's certifi, Rust's rustls-webpki, Electron, Alpine, Arch, Ubuntu, Debian and others; Node.js, Bun and FreeBSD were still pending when the tracker was last read.

What happened

According to BleepingComputer's account of Mozilla's incident report, a researcher known as Wayne found the problem on 17 October 2026 while scanning publicly available certificate data. The eight certificates all use NIST P-384 elliptic-curve keys generated in April 2025. A healthy P-384 private key is a number chosen from roughly 2^384 possibilities. These were all below 256, so trying 256 values was enough to recover each one. Ars Technica lists the eight values as 4, 56, 66, 115, 155, 156, 230 and 237.

To prove control, the reporter used each key to sign the message "We have a problem here - Wayne". Dennis Jackson, whom Cloudflare names as a Mozilla engineer, published the proof, the public keys and a test site at emudhra.we-have-a-problem.com. A valid signature shows the key can be reconstructed by someone other than the certificate authority.

The affected certificates are intermediates: certificates that a root authority signs so that the intermediate can issue certificates to websites. Because browsers and operating systems trust the roots, they trust anything that chains up to them. With an intermediate's private key an attacker can mint a certificate for any hostname, and clients that accept the chain will show no warning. The Jackson site names the chain roots as the Comodo AAA Services root and the emSign ECC Root CA - G3, and gives one affected intermediate by name, EM-DV-TLS-CA-G3B.

The timeline from the Jackson site and BleepingComputer:

• 17 October: reported to the root programs; Firefox and Chrome block the certificates.
• 19 October: Apple adds protections; downstream trust-store maintainers are told.
• 20 October: Microsoft adds its block; Firefox 158.0.1 and ESR updates ship for configurations that missed the earlier revocation push.

Cloudflare wrote that it became aware at about 17:00 UTC on 19 October, shipped fixes to its WARP clients early on 20 October and finished deploying CDN and Zero Trust mitigations at 19:20 UTC the same day.

eMudhra's explanation

BleepingComputer reports that eMudhra blames an error in a script used to generate the certificates in April 2025. The error produced a second set of weaker keys, and those were selected for signing because their labels looked like the correctly generated ones. Some of the resulting certificates were submitted to Sectigo for cross-signing. eMudhra says most of the affected intermediates were never used in production and that it has found no evidence of certificates issued to end users from them. It also acknowledges the weak keys could have been recovered and abused since April 2025, with no sign that happened. After disclosure it revoked the eight certificates and stopped issuing under its G3 root. We could not independently verify these statements; they come from the company as relayed by BleepingComputer.

Background

Certificate authorities have lost browser trust before, usually because of mis-issued certificates or a breach. This incident differs in kind: the keys were weak from the day they were generated, so nobody had to break in to get them. Cryptography engineer Filippo Valsorda, a Go maintainer, told Ars Technica the error is "extremely in the 'this should not be possible' category". Ben Cartwright-Cox of BGP.tools guessed to Ars that it could be example code that leaked into production, and stressed that this is a guess; eMudhra's own explanation is the script error above.

What limited the damage is the revocation channel browsers have. Cloudflare's post says browser maintainers could fix this "with a flip of a switch" through quick-revocation mechanisms such as Chrome's CRLSets, and that they have one application to update rather than hundreds. Mozilla used its OneCRL list the same way. Most other software has no such channel. A Python program may use the certifi bundle, a Go binary may rely on the operating system or ship its own list, and a container image keeps whatever trust store was baked in when it was built.

The numbers

Ars Technica reports the eight recovered private-key values. For comparison, a normal P-384 key is chosen from about 2^384 values (a number with 116 digits), and BleepingComputer, quoting Mozilla's report, says trying 256 numbers was enough to recover each key.

237237

230230

156156

155155

115115

6666

5656

44

Private key value of each compromised eMudhra certificate (a healthy P-384 key has about 2^384 possible values) (key value)

	key value
237	237
230	230
156	156
155	155
115	115
66	66
56	56
4	4

Source: Ars Technica, 20 October 2026

The patch coverage is the other set of numbers that matters. The Jackson tracker lists fixed versions for, among others, Go (1.27.3 and 1.26.10), NSS 3.131.1, Python certifi 2026.10.19, pip 26.2.2, uv 0.13.4, Rust rustls-webpki 0.103.16, Electron (44.9.1, 43.8.1 and 42.11.16), Alpine 20261020-r0 and Arch 3.131.1-1, plus Ubuntu, Debian, Fedora and Homebrew ca-certificates packages. Node.js, Bun and FreeBSD's ca_root_nss are marked pending.

What it means

For ordinary users. Keep browsers and operating systems updated. Ars Technica notes that most browsers had already blocked the certificates, with Edge on Windows 10 the exception it observed: when the article went live it still connected to 12 vulnerable hosts, and Microsoft told Ars only that it would be in touch if it had anything to share. The Jackson site says Microsoft added its block on 20 October, so check that your system has received it. Apps that do not rely on TLS for confidentiality, such as Signal, WhatsApp and WireGuard, are not affected, according to Ars.

For developers and operators. Cloudflare's advice is to look "beneath the SDK": an API client may leave certificate checking to an HTTP library, a language runtime, the operating system or a custom trust configuration, so updating the SDK alone may not change the policy. After patching you may see new certificate errors; Cloudflare says not to silence them by turning verification off, because that removes the protection the updates restore. A passing browser test does not prove a background service is safe, and neither does a curl test if the application uses a different verifier. Rebuild container images, then reload or restart services so they pick up the new trust store.

macOS command-line curl. The Jackson site says /usr/bin/curl reads /etc/ssl/cert.pem, which was not updated and does not check revocation, and it publishes a workaround that removes the two affected roots. Linux distributions that have not shipped updates can distrust the two roots by hand; the site marks that route for expert users only.

For the industry. Valsorda told Ars the cleanup would be "bigger than Heartbleed", with a long tail of IoT devices, Docker containers, forgotten Linux machines and unmaintained command-line tools that ship their own roots, a common habit in some ecosystems such as Python. Cloudflare points to projects such as upki, which treat a trust store as something that can receive revocation and certificate-transparency data quickly instead of a static list. Ars also notes that transparency logs cover much of the gap, but only if someone is actively monitoring them and only after a certificate has been issued.

Who is exposed. Ars stresses that abusing the certificates requires an active attacker who sits between the two parties, decrypts and re-encrypts traffic. That is usually the reach of well-resourced attackers, though someone controlling a local network such as a cafe or campus Wi-Fi has an easier path. Ars judged that the most immediate threat is to people using VPNs, especially where governments are likely to intercept traffic. Cloudflare reported it had not identified active exploitation on its services. Ars reports no sign in certificate transparency logs of the compromised keys being used maliciously.

What we don't know yet

• Whether anyone used the keys before disclosure. eMudhra says it has no evidence of abuse, and neither Cloudflare nor Ars saw any, but a forged certificate that is never logged would not show up in transparency data.
• How the weak keys were really generated. The script explanation is eMudhra's; Mozilla's incident report and any independent review may add detail. We did not read the Mozilla bug itself (bug 2083449 per the Jackson site) and rely on BleepingComputer's account of it.
• What happens to eMudhra's roots. Our sources describe the intermediates being revoked and issuance under the G3 root stopped; none of them describe a decision on the CA's wider trust status.
• How quickly Node.js, Bun, FreeBSD and the many embedded and container ecosystems will follow.
• Whether Edge on Windows 10 and other late systems are now covered.

What to watch next

Watch the Jackson tracker for the pending packages and for a count of patched software. Watch Mozilla's incident report for eMudhra's full root-cause analysis and any policy action. Check your own build pipeline: base images, language-runtime bundles and vendored certificate lists are the places a stale copy hides. If you run services that call out to the internet, confirm that a restart really picked up the new bundle. For more background on how supply-chain problems spread through developer tooling, see our report on the OVHcloud CLI backdoor and on the Rank Math Pro malware.

Sources

• Cloudflare: 8 eMudhra certificates are compromised. Here's what you need to know
• Dennis Jackson: emudhra.we-have-a-problem.com (proof, tracker, test hosts)
• Ars Technica: The Internet goes on high alert after discovery of 8 compromised TLS certs
• BleepingComputer: Mozilla, Google, Apple block compromised eMudhra CA certificates