eMudhra weak keys enable instant certificate forgery

1. Executive summary

Eight intermediate CA private keys issued by Indian certificate authority eMudhra were generated with between three and eight bits of entropy, so anyone could recover them from the public certificates in under a second. The keys were recovered by researchers on 17 October 2026, eMudhra revoked the certificates on 18 October, and Mozilla made the incident public on 20 October. Chrome, Firefox, Apple and Microsoft have blocked or distrusted the affected intermediates, but Cloudflare's telemetry shows more than half of probes from large networks still accept the compromised chain, and embedded browsers such as Android WebView lag at 30 to 40 percent acceptance. No CVE has been assigned and the item is not in CISA KEV; the exposure is to any EMEA financial services system that verifies TLS through a trust store, bundled CA bundle, Java keystore or pinned certificate that has not been updated, and to any client that does not enforce revocation or Certificate Transparency.

2. Regulatory framing

No specific DORA/NIS2 article is directly engaged by this item.

3. Technical analysis & attack chain

The defect is in key generation, not in TLS. eMudhra generated a batch of 24 intermediates on 30 April 2025. A faulty script produced a second set of weaker keys whose labels resembled the correctly generated ones, and staff selected the weak keys when preparing the certificates. Six of the eight affected intermediates issue TLS certificates and two are used for code signing; Sectigo cross-signed all eight in May 2025. A P-384 private key should be a random 384-bit number, roughly 10^115 possibilities. The recovered keys were the integers 4, 56, 66, 115, 155, 156, 230 and 237, so recovery means testing at most 256 values. Scott Helme recovered all eight from their public certificates on a laptop in under a second. The issue survived 18 months and two independent audits before discovery.

Confirmed sequence:

1. A community researcher reported the compromised keys to Mozilla on 17 October 2026 at 20:06 UTC, having signed a test message with each key and notified Apple, Google, Microsoft, Mozilla and eMudhra.
2. eMudhra revoked the eight certificates on 18 October.
3. Chrome and Firefox blocked the certificates on the day of the report, Apple followed on 19 October and Microsoft on 20 October. Mozilla removed trust in the eMudhra root that signed the intermediates; Google said it is evaluating eMudhra's remaining CA certificates.
4. Mozilla published the incident on its dev-security-policy forum on 20 October. Cloudflare added logging to its Pingora egress proxy on 21 October to record any handshake presenting a certificate signed by the weak keys.
5. Within hours of publication, forged certificates began appearing. One certificate Cloudflare observed was dated 20 October at 18:19 UTC, less than an hour after the Mozilla bug report became public.

What an attacker can do with a recovered key: sign a certificate for any domain, present it from a server they control, and have it accepted by any client that still trusts the eMudhra intermediate and does not enforce Certificate Transparency. That enables impersonation of the domain and interception or modification of traffic to it. CERT-IN's alert adds that the same capability lets malicious software appear digitally signed by a trusted publisher, which extends the exposure to code-signing verification paths.

Cloudflare's exploitation evidence, from roughly 22,000 attempted handshakes over the week to 30 October: two-thirds were fetches of test sites such as emudhra.we-have-a-problem.com. Almost all of the remaining third went to origins that had set up a certificate for themselves using the weak intermediate. Every handshake configured to verify the certificate was refused because Cloudflare had already patched. About 160 handshakes stood out: the certificates' Subject Alternative Names named other organisations' domains, unrelated to the SNI requested, some related to consumer IoT devices. Those certificates were issued after the keys leaked, some were valid for over two years (longer than any public CA may issue), and in several cases the same certificate was presented to connections from many Cloudflare locations, which points to the certificate coming from the server itself rather than from an on-path interceptor. They named domains other than the one being connected to and would have failed hostname verification anyway. Cloudflare states there is no evidence of the weak keys being used to intercept its connections, and that this does not exclude carefully targeted interception.

Patching progress, from Cloudflare's probe of challenge pages (two probes per page, one to a host with an eMudhra-signed certificate and one control, 50 million probes over the week): up-to-date modern browsers are mostly patched, bots and old browsers are not, and Android WebView sits at 30 to 40 percent still accepting. Across large networks more than half of probes still accept the compromised chain. Cloudflare cautions that challenge-page traffic is heavily skewed by unconfirmed bots and that only JavaScript-executing clients send probes, so the figures are suggestive rather than a census.

Confidence caveats. The exploitation telemetry is single-sourced to Cloudflare and covers only connections that traverse its network. The key values and the April 2025 ceremony details come from Mozilla's incident report as relayed by Help Net Security and The Register, and eMudhra has not published the faulty script. eMudhra's chairman stated the certificates were revoked within 14 hours of discovery and that there were no compromises or data breaches; that is the company's claim, not an independently verified finding. India's Ministry of Electronics and IT said it is investigating. No threat actor is named in any source and no MITRE ATT&CK profile applies, so there is no attribution to make.

One discrepancy worth recording: eMudhra says only one of the intermediates was ever put into production and none were used to issue certificates to customers, while Mozilla's report describes six TLS and two code-signing intermediates and Sectigo cross-signing all eight. Both statements are in the public record and the difference is unresolved.

4. Mitigation & containment

P1, within 24 hours:

• Inventory every trust store your TLS verification actually uses and remove or distrust the eight eMudhra intermediates and the eMudhra root. Check system stores (/etc/ssl/certs on Linux), Java keystores (cacerts), Python certifi bundles, Docker base images, mobile app bundles and any custom or pinned store. Updating an SDK does not change verification if the HTTP library, language runtime or OS store underneath still trusts the chain.
• Update Cloudflare One Client (WARP, the 1.1.1.1 app) and Cloudflare Tunnel (cloudflared) to the versions published on 20 October 2026 at 02:00 UTC. Cloudflare Zero Trust customers with Gateway and an up-to-date client are protected automatically.
• Re-issue any certificate your organisation holds that chains to an eMudhra intermediate, through a different CA. eMudhra estimates about 30,000 customer certificates need replacement.
• Do not resolve post-patch certificate errors by disabling verification. That removes the authentication the update restores.

P2, within 72 hours:

• Enforce CRL and OCSP checking on web proxies, API gateways and egress controls, and block connections presenting revoked chains. Clients with no reliable way to learn of revocation are the residual risk Mozilla's Dennis Jackson flagged.
• Query proxy, DNS and egress logs for TLS connections to external hosts whose presented certificate chains to eMudhra, and for certificate changes on hosts you connect to regularly. Cloudflare's 160 anomalous handshakes are the pattern to hunt: SANs unrelated to the SNI requested, validity periods over two years, and the same certificate served from many locations.
• Enable Certificate Transparency monitoring and publish CAA records restricting issuance for your domains to CAs you actually use.

P3, within 7 days:

• Rebuild container images and redeploy services that bundle their own trust store, and confirm whether each application needs a reload, restart or redeployment to pick up the change.
• Test through each application's real TLS path rather than a browser or curl check. A successful browser test does not prove a background service is protected, and a curl test does not prove an application using a different verifier is protected.
• Audit code repositories and build pipelines for hard-coded eMudhra trust anchors, and review authentication and identity logs for signs of interception.

5. Indicators of compromise

No atomic indicators of compromise (hashes, domains, IP addresses) are available in the source material. The only network value named is a test host used by defenders, not by an attacker.

Behavioural indicators:

6. Detection

Insufficient indicators to author detection rules. The sources give no file artefacts, command lines, mutexes, registry keys or malicious network values to build a string-based YARA or Sigma rule from. Detection for this item is trust-store state and TLS handshake metadata, covered by the behavioural indicators in §5 and the log queries in §4.

7. Sources

• Cloudflare Security Blog, "4 real? Tracking exploitation and patching of eMudhra's weak keys", https://blog.cloudflare.com/emudhra-patching/, 2026-10-30
• Cloudflare Security Blog, "8 eMudhra certificates are compromised. Here's what you need to know", https://blog.cloudflare.com/emudhra-certificate-compromise/, 2026-10-20
• Palo Alto Unit 42, "EMudhra Intermediate CA Certificates Compromised", https://unit42.paloaltonetworks.com/emudhra-certificate-compromise/, October 2026
• Cybersecurity Dive, "Weak encryption certificates could have let hackers easily spoof websites", https://www.cybersecuritydive.com/news/website-encryption-security-certificates-emudhra-incident/833622/, October 2026
• Help Net Security, "eMudhra security blunder left trusted CA signing keys exposed to anyone", https://www.helpnetsecurity.com/2026/10/21/emudhra-certificates-private-keys-compromised/, 2026-10-21
• The Register, "Indian certification authority eMudhra's private keys compromised, one of them was the number '4'", https://www.theregister.com/security/2026/10/20/indian-certification-authority-emudhras-private-keys-compromised-one-of-them-was-the-number-4/5304312, 2026-10-20
• The Record (Recorded Future), "Indian tech company eMudhra announces withdrawal from certificate business after security incident", https://therecord.media/indian-tech-company-announces-withdrawal-certificate-business-incident, October 2026

8. Adverse Trace position

Adverse Trace assesses this as a high-impact trust infrastructure failure with no assigned CVE and no CISA KEV entry, so it will not appear in vulnerability scanners and must be handled as a configuration and supply chain problem. The exploitation evidence is real but narrow: forged certificates appeared within an hour of disclosure, and Cloudflare saw no interception of its own traffic, so the confirmed harm to date is forged certificates presented from servers that would have failed hostname verification. The material risk to EMEA financial services clients is the long tail of unpatched trust stores, embedded browsers and bundled CA bundles, where Cloudflare's probe data shows more than half of large-network traffic still accepting the chain. We will re-check browser and OS trust store status and eMudhra's root-cause report when published, and we will update this advisory if evidence of targeted interception emerges. Clients should treat the P1 trust store inventory as the priority action this week.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.