1. Executive summary
Eight intermediate CA certificates issued by Indian certificate authority eMudhra were generated with private keys so weak that researchers recovered them from the public certificates in under a second; one key was the number 4, others were small integers such as 56, 115, 66, 155, 156, 230 and 237. Mozilla's Dennis Jackson disclosed the compromise on 20 October 2026, and Chrome, Firefox, Apple and Microsoft blocked the certificates between 17 and 20 October, with eMudhra revoking them on 18 October. Anyone holding a recovered key could forge a TLS certificate for any domain and impersonate a server to clients that still trust the chain, which is the exposure for EMEA financial services: internal services, origin servers, API clients and embedded devices that pin or bundle their own trust stores may not have picked up the browser blocks. No CVE has been assigned and no exploitation has been observed in Certificate Transparency logs, but not all clients enforce CT, so absence of evidence is not proof the keys went unused.
2. Regulatory framing
| Article | Trigger (the fact in this item) | Practical impact |
|---|---|---|
| DORA Art. 28 | The trust failure sits in a third-party certificate authority whose intermediates chain to roots in client trust stores, and affected firms must assess and update their own ICT third-party dependencies on that CA | Firms need to identify contracts and services that rely on eMudhra-issued or eMudhra-chained certificates and record the remediation |
| DORA Art. 30 | Replacement of certificates and trust-store changes may require contractual cooperation from the CA and from providers that bundle trust stores | Check whether existing ICT contracts oblige the provider to supply replacement certificates and notify of trust changes |
| NIS2 Art. 21(2)(d) | Supply chain security: the compromise originates in a supplier's key-generation process, not the client's own systems | Entities in scope must be able to evidence supplier security assessment and remediation tracking for this CA |
3. Technical analysis & attack chain
The flaw is a key-generation failure, not a cryptographic break. eMudhra ran a Key Generation Ceremony on 30 April 2025 using FIPS 140-2 Level 3 HSMs. A faulty script in the ceremony produced a second set of weak keys alongside the correctly generated ones. Because the weak keys carried labels resembling the strong keys, staff selected the weak set when building the certificate signing requests, and those weak keys were the ones published to browser root stores. The eight affected intermediates came from a batch of 24 generated that day; six issue TLS certificates and two are used for code signing, and Sectigo cross-signed all eight in May 2025.
The weak keys are P-384 keys whose private value is effectively all zeroes apart from the last byte. Instead of a random 384-bit number (roughly 10^115 possibilities), each key is smaller than 256, so the private key can be recovered by testing at most 256 values. Jackson states the keys can be recovered near instantly via the baby-step giant-step discrete log algorithm. Scott Helme recovered all of them from the public certificates on a laptop in under a second. Cybersecurity Dive reports the keys contained between three and eight bits of entropy.
Confirmed sequence of events:
- 30 April 2025: key generation ceremony produces strong keys and, through the script flaw, a parallel weak set.
- May 2025: Sectigo cross-signs the eight intermediates; the weak keys are published in the certificates.
- 17 October 2026: researcher Wayne finds the flaw while running a check against the Common CA Database (CCADB) and proves it by signing the message "We have a problem here - Wayne" with each key, reporting to Apple, Google, Microsoft, Mozilla and eMudhra.
- 17 October 2026: Mozilla and Google block the certificates in Firefox and Chrome.
- 18 October 2026: eMudhra revokes the certificates.
- 19 October 2026: Apple blocks the certificates; Cloudflare becomes aware at approximately 17:00 UTC and begins patching.
- 20 October 2026: Microsoft blocks the certificates; Jackson discloses publicly on Mozilla's dev-security-policy forum; Cloudflare publishes client updates.
The attack this enables: an attacker who recovers a key can sign a certificate for any domain, present it to a client that still trusts the eMudhra chain, and intercept or modify traffic to that domain. Cloudflare's assessment is that this affects certificate-based authentication, not the TLS encryption algorithms. The practical target set is clients that do not reliably learn of revocation: origin servers, API clients, embedded and IoT devices, applications with bundled or custom trust stores, and software that has not been updated since the blocks landed.
eMudhra's account, given on Mozilla's bug tracker, is that only one of the intermediates was ever put into production and that none were used to issue customer certificates. The company says the issuers were intended for export to its US and European data centres to address data sovereignty for some customers. It has stopped issuing from the affected root and estimates about 30,000 customer certificates need replacement. Mozilla removed trust in the eMudhra root that signed the intermediates; Google is evaluating the status of eMudhra's remaining CA certificate.
Unconfirmed and caveated points. No evidence has been found in Certificate Transparency logs that the keys were used maliciously before revocation, but SecurityWeek notes not all clients enforce CT, so this is not a clean bill of health. eMudhra's claim that the weak intermediates issued no customer certificates is single-sourced to the CA and has not been independently corroborated in the material reviewed. No threat actor has been named or attributed in any source, and no MITRE ATT&CK profile applies; treat any attribution as unconfirmed. There is no CVE, no CVSS score and no CISA KEV entry for this item.
4. Mitigation & containment
P1 within 24 hours
- Inventory every certificate and trust anchor that chains to eMudhra, including origin server certificates, internal service certificates, code-signing certificates and any pinned or bundled trust stores. Do not rely on a browser test alone: Cloudflare notes a successful browser check does not prove a background service is protected, and a curl test does not cover an application using a different verifier.
- Update browsers and operating systems to current versions so the blocks from Chrome, Firefox, Apple and Microsoft are active. Mozilla's Jackson advises exactly this.
- Update Cloudflare One Client / WARP and Cloudflare Tunnel (cloudflared) to the versions published on 20 October 2026 if either is deployed. Cloudflare Zero Trust with Gateway and an up-to-date client is automatically protected.
- Do not resolve certificate errors that appear after patching by disabling verification. Cloudflare is explicit that this removes the authentication protection the update restores.
P2 within 72 hours
- Walk the dependency tree for TLS libraries and SDKs. An API client may delegate verification 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. Apply the patched package list crowdsourced by Dennis Jackson, rebuild affected images, and reload, restart or redeploy as required.
- Use Jackson's test site to check non-browser verification paths, testing through each application's actual TLS path rather than a generic client.
- Replace certificates issued under the affected eMudhra root. eMudhra is issuing replacements directly to affected customers; engage account teams and confirm replacement timelines against the roughly 30,000 certificates the CA says need replacing.
P3 within 7 days
- Review contracts with eMudhra and with any provider that bundles trust stores, confirming obligations to supply replacements and to notify of trust changes.
- Add a control that monitors root program announcements and CCADB changes so future distrust events are caught from the source rather than from press coverage.
5. Indicators of compromise
No atomic indicators of compromise (hashes, domains, IPs, file paths) are present in the source material. The relevant observables are behavioural: trust in specific certificates and the presence of weak keys.
| type | value | confidence | source |
|---|---|---|---|
| n/a | No atomic indicators in source material | n/a | n/a |
Behavioural indicators
| behaviour | where to observe | confidence |
|---|---|---|
| Client still accepts a certificate chaining to the revoked eMudhra intermediates | TLS handshake logs, application verifier output, Jackson's test site | High |
| Application uses a bundled or custom trust store that has not been updated | Application configuration, container base images, dependency manifests | High |
| Certificate presented for a domain does not match the legitimate issuer | Certificate Transparency monitoring, TLS inspection logs | Medium (no malicious use observed in CT) |
6. Detection
Insufficient indicators to author detection rules.
The sources give no file artefacts, command lines, mutexes, registry keys or network strings belonging to an attacker. The only concrete artefacts are the weak private key values (4, 56, 115, 66, 155, 156, 230, 237) and the proof-of-concept message "We have a problem here - Wayne", neither of which is a threat artefact suitable for a detection rule. Detection here is a trust-configuration audit, covered in §4, not a signature.
7. Sources
- The Register, "Certification authority eMudhra defends its laughably weak private keys", https://www.theregister.com/security/2026/10/22/certification-authority-emudhra-defends-its-laughably-weak-private-keys/5304647, 2026-10-22
- 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
- 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
- Cybersecurity Dive, "Weak encryption certificates could have let hackers easily spoof websites", https://www.cybersecuritydive.com/news/website-encryption-security-certificates-emudhra-incident/833622/, 2026-10
- SecurityWeek, "Browsers Block eMudhra Intermediate CAs Over Recoverable Private Keys", https://www.securityweek.com/browsers-block-emudhra-intermediate-cas-over-recoverable-private-keys/, 2026-10
- Cloudflare Security Blog, "8 eMudhra certificates are compromised. Here's what you need to know", https://blog.cloudflare.com/emudhra-certificate-compromise/, 2026-10
- The Hacker News, "Eight eMudhra CA Keys Compromised, Triggering Emergency Fixes Across Browsers and Software", https://thehackernews.com/2026/10/eight-emudhra-ca-keys-compromised.html, 2026-10-20
8. Adverse Trace position
Adverse Trace assesses this as a high-impact trust failure with no observed exploitation. There is no CVE, no CVSS score and no CISA KEV entry, and no actor is attributed; the risk is the window during which clients that have not updated still accept forged certificates for any domain. For EMEA financial services the exposure concentrates in non-browser TLS paths: origin servers, API clients, embedded devices and applications with bundled trust stores, where the browser blocks do not apply and revocation may never be checked. We will track eMudhra's root-cause findings and Google's evaluation of the remaining eMudhra root, and we will reissue this note if evidence of forged-certificate use appears in Certificate Transparency logs or if a CVE is assigned. Clients should treat the P1 inventory in §4 as the immediate action and report back any service that cannot be updated within 72 hours.
Published via PulseTrace — Adverse Trace threat intelligence.