eMudhra intermediate CA keys compromised due to weak entropy, CVE-2026-111943

1. Executive summary

Eight intermediate CA certificates issued by eMudhra were generated with private keys of 3 to 8 bits of entropy instead of the intended 384, and the keys can be recovered from the public certificates in under a second. The certificates chained to roots trusted by Apple, Google, Microsoft and Mozilla, and six were TLS intermediates capable of signing a fraudulent certificate for any domain; two were code-signing intermediates. Chrome, Firefox, Apple and Microsoft have blocked the certificates and eMudhra has revoked them, but clients that use embedded or stale trust stores and do not check revocation remain exposed. The Go team assigned CVE-2026-111943 and fixed it in Go 1.27.3 and 1.26.10; NVD records no CVSS score for the CVE, it is not in CISA KEV, and EPSS is 0%. No malicious use of the keys has been observed as of October 21, 2026, 14:00 UTC. For EMEA financial services the exposure is in TLS-validating infrastructure that does not follow browser trust decisions: VPN gateways and clients, forward and reverse proxies, load balancers, CI/CD build runners and package managers, and embedded or IIoT devices with bundled CA stores.

2. Regulatory framing

3. Technical analysis & attack chain

The flaw is in key generation, not in TLS. On April 30, 2025, eMudhra ran a key generation ceremony for 24 subordinate CAs under its emSign Root TLS CA - G3, cross-signed by Comodo AAA Certificate Services (Sectigo cross-signed the eight affected intermediates in May 2025). A faulty script created a second set of weak P-384 keys during a wrap/unwrap step. The weak keys carried labels similar to the correctly generated keys, and staff selected them when preparing the certificate signing requests. The result was private keys with 3 to 8 bits of entropy rather than 384. Scott Helme recovered all eight from their public certificates on a laptop in under a second; the recovered values included the integers 4, 56 and 115, and other researchers reported 66, 155, 156, 230 and 237. Dennis Jackson described the keys as effectively all-zeroes apart from the last byte, recoverable near-instantly with the baby-step giant-step discrete log algorithm.

The eight affected certificates, with the SHA-256 fingerprint of each certificate as published in Mozilla's bug report:

The attack chain, as far as it is confirmed:

1. An adversary recovers a private key from the public intermediate certificate. This requires no access to eMudhra systems; the key is derivable from the certificate alone.
2. The adversary uses the key to sign a leaf certificate for a target domain, chaining to the compromised intermediate and its trusted root.
3. The adversary intercepts or redirects a connection to a client that still trusts the intermediate and does not enforce revocation, key distrust, certificate transparency or pinning, and presents the forged certificate to impersonate the server.
4. With the connection accepted, the adversary can read or modify traffic in transit.

No step beyond key recovery has been observed. Talos stated on October 21, 2026 at 14:00 UTC that it had not seen malicious incidents involving the certificates. SecurityWeek reported no evidence in Certificate Transparency logs that the keys were used maliciously before revocation, while noting that not all clients enforce CT and that use against non-CT clients would not appear there. Treat the absence of observed exploitation as current, not as assurance.

The Go runtime is the case that produced the CVE. Go implements its own X.509 chain verification in crypto/x509 rather than deferring to OpenSSL, and in static container environments it can rely on embedded or legacy root pools that ignore revocation. Go 1.27.3 and 1.26.10 filter out chains containing the SHA-256 hashes of the SubjectPublicKeyInfo (SPKI) for all eight compromised intermediates. Note that the fingerprints in the table above are certificate SHA-256 values from Mozilla's report; the Go fix keys on SPKI hashes, which are different values and are not published in these sources. Talos expects further patches across other software, and named VPNs as likely to need updates.

Exposure by category, from Talos and Cloudflare:

• Enterprise infrastructure and VPNs. Proxies, reverse load balancers, VPN clients and gateways are exposed where the certificate chain is validated against a trust store that still contains the intermediates and revocation is not enforced. A stale or separately managed trust store needs an application, OS, firmware or trust-bundle update.
• Software supply chains and CI/CD. Build runners and package managers that fetch over TLS while trusting an affected key are exposed to registry impersonation. A forged TLS certificate does not by itself bypass lockfile hashes, checksums, signatures or provenance controls.
• Industrial IoT and embedded systems. Devices with bundled or independently managed CA stores, especially where revocation or trust-store updates are limited, may need a vendor update or a compensating control.
• Cloudflare-specific. Cloudflare released updates for the Cloudflare One Client (WARP / 1.1.1.1 app) and Cloudflare Tunnel (cloudflared), and deployed mitigations across CDN, Developer and Zero Trust products. Cloudflare One Agent on iOS was still in app review at the time of its post. Cloudflare's review found no active exploitation on its services.

Two caveats on confidence. First, eMudhra's own account, given on Mozilla's bug tracker and repeated to SecurityWeek, is that only one of the intermediates was ever put into production and that none were used to issue customer certificates; this is a single-party statement and conflicts with the practical assumption that all eight must be distrusted, which is what the browser vendors and the Go fix apply. Second, the specific recovered key values (4, 56, 115, 66, 155, 156, 230, 237) are reported by researchers through Helme and The Register and are not mapped to individual certificates in these sources.

4. Mitigation & containment

P1, within 24 hours:

• Inventory every TLS verification path that does not inherit browser trust: VPN gateways and clients, forward and reverse proxies, load balancers, API gateways, service meshes, and anything with a bundled or custom trust store. For each, determine whether it trusts the emSign Root TLS CA - G3 or emSign Root CS CA - G3 chain and whether it enforces revocation.
• Update Go-built services to 1.27.3 or 1.26.10. Rebuild container images rather than patching running containers, because the fix is compiled into crypto/x509.
• Update Cloudflare One Client (WARP / 1.1.1.1 app) and cloudflared to the current release. Cloudflare Zero Trust customers with Gateway and an up-to-date client are protected automatically.
• Do not resolve post-patch certificate errors by disabling verification. Cloudflare explicitly warns against this; it removes the authentication the update restores.

P2, within 72 hours:

• Apply vendor trust-store and firmware updates for proxies, load balancers, VPN appliances and embedded/IIoT devices that bundle their own CA stores. Where no update exists, apply a compensating control: pin the expected issuer for internal and partner endpoints, or restrict egress so that TLS to sensitive endpoints traverses an inspected path.
• Audit CI/CD. Check package-manager and build-runner trust configuration and the dependency tree, since the affected library may be an indirect dependency. Confirm lockfile hashes, checksums and provenance controls are enforced independently of TLS, so that registry impersonation cannot substitute a package.
• Validate through each application's actual TLS path. A 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. Mozilla's Dennis Jackson published a test site with browser checks and non-browser testing instructions for this purpose.

P3, within 7 days:

• Add the eight certificate SHA-256 fingerprints in §5 to detection content and to any certificate-inventory or CT-monitoring query, so that a leaf certificate chaining to a compromised intermediate raises an alert.
• Confirm with eMudhra-dependent counterparties and certificate customers whether they have replaced certificates issued under the G3 root. eMudhra estimates about 30,000 customer certificates need replacement.
• Track vendor advisories for further patches. Talos expects additional fixes across a range of technologies.

5. Indicators of compromise

The values below are certificate SHA-256 fingerprints of the eight compromised intermediates, not file hashes. They are the pivot for detecting a chain that includes a compromised intermediate. No network indicators, file hashes or host artefacts are published in these sources.

sha256  E7568FE6E12331F4FD7DE61DA4C7559D0F8EB192A218D4741A3BA75184333838
sha256  98B896625C0C230ADEEC3EB2CF6AAD5001ECF9156A68644E82374CE5833BC25B
sha256  42C4ACCD12C4F59597925E1A08A7A90102608543809308D50EC427E118BA1493
sha256  432EC25F0D28DE9006D97BF752F17BBB2CD41F669933FCB072D9A1148D0261F3
sha256  CB6E15165AC802E9B3F993F16C25D41F4E81C21EBDE71AE1B012AC00BF9C7C3F
sha256  0164D7CEAE5BB909C272AF151FF44B1177AE9B47D9424B94F1D9558C30934D19
sha256  9E39DE2881273ACC225A149C72BA3E0F51424963669AB633EE1DC7DF5DB067B4
sha256  4B2460A466F95FD40113BCDCCA2CEB29B3B093921DE45474DA7DF48874C630B1

Behavioural indicators:

6. Detection

The sources give no file artefacts, command lines, mutexes or registry keys, so a YARA rule would have nothing genuine to match. Detection for this item is certificate-based. The Sigma rule below flags a TLS chain that includes one of the eight compromised intermediates, keyed on the certificate SHA-256 fingerprints. Populate the CertificateSha256 field from your TLS inspection or certificate-inventory pipeline; the field name is illustrative and should be mapped to your schema.

title: TLS chain includes a compromised eMudhra intermediate CA
id: 8f3c2a10-6b7e-4d21-9a55-0c1e2d4b7f90
status: experimental
description: Detects a TLS certificate chain that includes one of the eight eMudhra intermediate certificates compromised by weak key entropy (CVE-2026-111943).
author: Adverse Trace
date: 2026-10-21
references:

  - https://blog.talosintelligence.com/compromised-intermediate-certificates/
  - https://blog.cloudflare.com/emudhra-certificate-compromise/
logsource:
  category: tls
detection:
  selection:
    CertificateSha256:

      - 'E7568FE6E12331F4FD7DE61DA4C7559D0F8EB192A218D4741A3BA75184333838'
      - '98B896625C0C230ADEEC3EB2CF6AAD5001ECF9156A68644E82374CE5833BC25B'
      - '42C4ACCD12C4F59597925E1A08A7A90102608543809308D50EC427E118BA1493'
      - '432EC25F0D28DE9006D97BF752F17BBB2CD41F669933FCB072D9A1148D0261F3'
      - 'CB6E15165AC802E9B3F993F16C25D41F4E81C21EBDE71AE1B012AC00BF9C7C3F'
      - '0164D7CEAE5BB909C272AF151FF44B1177AE9B47D9424B94F1D9558C30934D19'
      - '9E39DE2881273ACC225A149C72BA3E0F51424963669AB633EE1DC7DF5DB067B4'
      - '4B2460A466F95FD40113BCDCCA2CEB29B3B093921DE45474DA7DF48874C630B1'
  condition: selection
falsepositives:

  - Legacy clients that still present a revoked chain before trust-store update
level: high

Talos published Snort SIDs 67363 to 67374 for network coverage of this threat.

CVE assessment

1 referenced CVE

7. Sources

• Cisco Talos, "Compromised eMudhra intermediate certificates", 2026-10-21. https://blog.talosintelligence.com/compromised-intermediate-certificates/
• Cloudflare Security Blog, "8 eMudhra certificates are compromised. Here's what you need to know", 2026-10-20. https://blog.cloudflare.com/emudhra-certificate-compromise/
• Help Net Security, "eMudhra security blunder left trusted CA signing keys exposed to anyone", 2026-10-21. https://www.helpnetsecurity.com/2026/10/21/emudhra-certificates-private-keys-compromised/
• SecurityWeek, "Browsers Block eMudhra Intermediate CAs Over Recoverable Private Keys", 2026-10-20. https://www.securityweek.com/browsers-block-emudhra-intermediate-cas-over-recoverable-private-keys/
• Cybersecurity Dive, "Weak encryption certificates could have let hackers easily spoof websites", 2026-10-20. https://www.cybersecuritydive.com/news/website-encryption-security-certificates-emudhra-incident/833622/
• The Register, "Indian certification authority eMudhra's private keys compromised, one of them was the number '4'", 2026-10-20. https://www.theregister.com/security/2026/10/20/indian-certification-authority-emudhras-private-keys-compromised-one-of-them-was-the-number-4/5304312
• The Hacker News, "Eight eMudhra CA Keys Compromised, Triggering Emergency Fixes Across Browsers and Software", 2026-10-20. https://thehackernews.com/2026/10/eight-emudhra-ca-keys-compromised.html

8. Adverse Trace position

Adverse Trace assesses this as a high-impact trust failure with no observed exploitation to date. The CVE carries no NVD CVSS score, is not in CISA KEV, and has an EPSS of 0%, which reflects the absence of observed exploitation rather than the severity of a recoverable CA key; the practical risk is concentrated in clients that do not follow browser trust decisions. No actor is attributed. The key recovery is arithmetic, available to anyone with the public certificate, so attribution of any future forged certificate would rest on infrastructure and traffic evidence, not on the key. Client impact is highest for institutions running VPN gateways, TLS-inspecting proxies, load balancers and CI/CD build runners with bundled or stale trust stores, and for those with embedded or IIoT estates where revocation is not enforced. We will track vendor trust-store and firmware updates as they appear, monitor Certificate Transparency for leaf certificates chaining to the eight intermediates, and reissue this advisory if exploitation is reported or if the SPKI hashes used by the Go fix are published, so that clients can add them to detection content.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.