eMudhra CA Key Compromise: Chrome and Firefox Have Blocked It, Non-Browser Clients Need Updates Now

eMudhra CA Key Compromise: Chrome and Firefox Have Blocked It, Non-Browser Clients Need Updates Now

The private keys of eight intermediate certificate authority (CA) certificates operated by the Indian CA eMudhra (emSign brand) have been compromised. Mozilla and the Chrome Root Program confirmed the incident publicly on 20 October 2026. Mozilla says these keys "could allow attackers to issue fraudulent HTTPS certificates for websites they do not control", letting an attacker who can intercept a connection impersonate a website or service and read or change its traffic.

According to Mozilla's incident report, the keys were generated incorrectly and Mozilla was able to recover them on its own, without knowing the reporter's method. On 20 October Mozilla also said that "multiple individuals have independently recovered the private keys". Rescana's view: treat the keys as available to others, not only to the original reporter.

Chrome and Firefox blocked the certificates on 17 October. The Chrome Root Program says no TLS certificate chaining to the six affected TLS intermediates was logged to Certificate Transparency (CT) before its block, so "no fraudulent certificates issued by these CAs could have been trusted by default in Chrome or other CT-enforcing browsers". According to the community-maintained incident site run by Mozilla's Dennis Jackson, Apple devices have blocked the certificates since 19 October and Microsoft platforms since 20 October. Apple and Microsoft have not published their own notices, and Ars Technica reported that Edge on Windows 10 was still connecting to the incident site's test hosts when its article went live. The risk sits outside the browser: Go programs, Python apps that use certifi, Node.js services, custom or bundled trust stores, origin servers, API clients and appliances that don't check revocation or CT. Many of these keep trusting the compromised intermediates until their software or root bundle is updated.

No exploitation has been reported by the sources we checked. Cloudflare says its security review "has not identified active exploitation of this issue on Cloudflare services". CISA's SSVC assessment for CVE-2026-113470 records exploitation as "none", and neither CVE is in CISA's Known Exploited Vulnerabilities (KEV) catalog.

Technical Information

Eight intermediate CAs are affected. All were created in a key ceremony on 30 April 2025 (Mozilla incident report):

  • TLS, domain validated: EM DV TLS CA - G3B (eMudhra BV) and EM DV TLS CA - G3C (eMudhra Inc)
  • TLS, organisation validated: EM OV TLS CA - G3B and EM OV TLS CA - G3C
  • TLS, extended validation: EM EV TLS CA - G3B and EM EV TLS CA - G3C
  • Code signing: EM OV CS CA - G3B and EM OV CS CA - G3C

The six TLS intermediates chain to emSign ECC Root CA - G3. Each of the eight also exists as a cross-signed certificate with the same key under Sectigo's AAA Certificate Services root (shown as "Comodo AAA Services root" in some trust stores). Sectigo told Mozilla this root had already been removed from the Chrome and Mozilla root stores but is still trusted by Microsoft and Apple. Mozilla's dev-security-policy post links machine-readable lists of the affected intermediates and the roots they chain to.

Cause (preliminary, per eMudhra): In the Mozilla bug, eMudhra says a flaw in the script used on that day's key-generation ceremony produced a second, weaker set of keys, and those keys were used by mistake to create the certificates. eMudhra also says its RSA intermediates went through a different process and are not affected. Its investigation is still ongoing.

Timeline (times in UTC; source in brackets):

  • 17 Oct, 18:05: A researcher (credited by Mozilla as "Wayne") reports the compromise to the Chrome Root Program, with proof of control of all eight keys [Chrome Root Program].
  • 17 Oct, 19:45: Chrome lands a CRLSet update that blocks the six TLS intermediates by public key. This also blocks the Sectigo cross-signed copies, with no browser update or restart needed. The two code-signing CAs did not need a Chrome block [Chrome Root Program].
  • 17 Oct, 20:06–22:59: Mozilla receives the report and finishes pushing a OneCRL block to Firefox users with standard settings [Mozilla].
  • 18 Oct, ~09:24–09:40: eMudhra revokes all eight intermediates with reason "cACompromise" [Mozilla bug, eMudhra comment].
  • 19 Oct: Sectigo completes revocation of the cross-signed certificates [Mozilla bug, Sectigo comment]. Mozilla begins disclosing the issue to downstream trust-store operators [Mozilla bug]. According to the incident site published by Mozilla engineer Dennis Jackson, Apple devices have blocked the certificates since 19 October.
  • 19–20 Oct: Go ships 1.27.3 and 1.26.10 with a crypto/x509 block (CVE-2026-111943). Python certifi 2026.10.19 and Rust webpki-roots 1.0.10 drop emSign ECC Root CA - G3.
  • 20 Oct: Mozilla releases Firefox 158.0.1 and ESRs (CVE-2026-113470) and NSS 3.131.1, which removes emSign ECC Root CA - G3. Mozilla announces the emergency removal of trust in that root after several people recovered the keys independently. Chrome says it will remove the same root in Chrome Root Store version 43 and is reviewing eMudhra's remaining root. eMudhra stops issuance from all intermediates chaining to emSign ECC Root CA - G3 [Mozilla bug; MDSP]. According to Jackson's incident site, Microsoft platforms have blocked the certificates since 20 October.

Side effect for legitimate sites: Mozilla warns that removing the root "will impact the availability of some servers" for non-Firefox clients until those servers move to new certificate chains. After you update, expect some TLS errors with partners or vendors that still use those chains. Do not "fix" them by turning off certificate verification.

CVE / KEV status (checked 21 Oct 2026, 08:12 Asia/Nicosia):

  • CVE-2026-111943 (Go, crypto/x509): published by the Go CNA. NVD status "Received", with no CVSS score from NVD or the CNA.
  • CVE-2026-113470 (Mozilla Firefox/Thunderbird): Mozilla rates it high impact in MFSA 2026-111. NVD has not analysed it yet ("Awaiting Analysis"). CISA's ADP container on NVD scores it CVSS 3.1 5.4 (Medium).
  • Neither CVE is in CISA KEV (catalog version 2026.10.20).

Affected Product Versions

Any client that trusts emSign ECC Root CA - G3 (or Sectigo AAA Certificate Services for the cross-signs) is potentially exposed if it doesn't consume revocation data and doesn't enforce CT. Fixes confirmed by vendors so far:

Software Status Fixed in What it does
Go Fix available (golang-announce, release history) 1.27.3, 1.26.10 crypto/x509 rejects chains containing the blocked intermediates (CVE-2026-111943). Affected: versions before 1.26.10, and 1.27.0 to before 1.27.3 (CVE record). Programs must be rebuilt with a patched Go release
Firefox / Thunderbird Fix available (MFSA 2026-111 to 2026-115) Firefox 158.0.1, Firefox ESR 153.5.1, Firefox ESR 115.43.1, Thunderbird 158.0.1 and 153.5.1 Bakes in the OneCRL block for installs where Remote Settings is disabled or blocked (CVE-2026-113470)
NSS Fix available (NSS 3.131.1 release notice) 3.131.1 Removes trust in emSign ECC Root CA - G3 (and emSign Root CA - C1 and emSign ECC Root CA - C3)
Python certifi Fix available (PyPI) 2026.10.19 Bundle no longer includes emSign ECC Root CA - G3
Rust webpki-roots / webpki-root-certs Fix available (release notes, crates.io) 1.0.10 Removes emSign ECC Root CA - G3
Composer ca-bundle (PHP) Fix available (1.6.0, 1.4.16) 1.6.0, 1.4.16 Distrusts the compromised eMudhra intermediates
Debian ca-certificates Fix available (DSA-6572-1, DLA-4845-1) 13 trixie: 20250419+deb13u1; 12 bookworm: 20250419~deb12u2 Removes emSign ECC Root CA - G3 and Comodo AAA Services root
Node.js No release yet — A change blocking the eight keys was merged into Node.js main on 20 Oct. At the time of writing, no Node.js release contains it

Fixes for other distributions and packages (for example Ubuntu, Fedora, Alpine, Arch, Homebrew, pip, uv, Electron) are tracked on the community-maintained incident site run by Mozilla's Dennis Jackson. Check each one against the vendor's own advisory before you rely on it. Cloudflare has published customer actions for its own products, including updated WARP / Cloudflare One clients and cloudflared 2026.10.2.

Workaround and Mitigation

The steps below are Rescana guidance. Where a step relies on vendor, Mozilla or Cloudflare advice, that source is named.

  1. Inventory and rebuild Go binaries. The Go fix lives in the standard library, so a Go program only picks it up when it is rebuilt with Go 1.27.3 or 1.26.10. List every Go-built service, CLI, agent and sidecar you run, including third-party ones, rebuild with a patched toolchain, and redeploy. Go 1.25 and older get no fix (Go security policy).
  2. Update bundled root stores in your dependencies. Upgrade certifi (2026.10.19), webpki-roots (1.0.10), NSS (3.131.1) and Composer ca-bundle (1.6.0 / 1.4.16). These are often indirect dependencies, so walk the dependency tree. Rebuild container images and base images, then restart or redeploy so the new store is actually loaded.
  3. Update OS trust stores. Apply your distribution's ca-certificates update (for example Debian DSA-6572-1 / DLA-4845-1), and confirm that containers and golden images pick it up.
  4. Plan for Node.js. No Node.js release includes the fix yet. Watch the Node.js releases and patch when it lands. Until then, review services that use Node's built-in root store for high-value outbound connections.
  5. Check bundled and custom trust stores, appliances and origin servers. Look at Java keystores, application-bundled CA files, mutual-TLS (client certificate) trust stores, proxies, load balancers, VPN and security appliances, IoT and embedded devices. Ask the vendor for an update wherever you can't change the store yourself. Cloudflare advises customers to review origin certificates and server configuration and their uploaded mTLS CAs.
  6. Enforce revocation and CT where you can. Where a client supports it, enable hard-fail revocation checking or CT enforcement. Mozilla notes that clients which reliably check revocation and fail closed need no further action.
  7. Test the real TLS path, and don't disable verification. Cloudflare notes that a passing browser test does not prove a background service is protected, and that a curl test may use a different verifier than your app. After you patch, expect certificate errors from legitimate servers still on emSign ECC Root CA - G3 chains. Work with those owners to migrate rather than turning off verification.

Indicators of Compromise

None published. Chrome says no TLS certificates chaining to the six TLS intermediates were logged to CT before its 17 October block, and the incident site says there were no CT entries for them since their creation in April 2025. Neither source can rule out misuse against clients that don't enforce CT. Defenders can check certificate chains seen in their own TLS logs or inspection tools against the published list of affected intermediates.

Why this matters for vendor risk

Chrome and Firefox blocked the compromised certificates within hours. Your vendors' backend services, SDKs, agents and appliances were not, because they trust certificates outside the browser and often carry their own root bundles or Go/Python/Node builds. A vendor that hasn't rebuilt or updated could still be talked into trusting a forged certificate for your domain or theirs. Ask your critical vendors directly: have you updated trust stores and rebuilt Go, Python and Node.js components for the eMudhra compromise, and when? Then follow up until each one confirms.

What we will update: We will update this post when Node.js ships a fixed release, when NVD scores the CVEs, and if exploitation or a root-cause report is published.

Sources

Forward this to your TPRM owner: Chrome and Firefox blocked the compromised eMudhra certificates within hours, but vendor services, SDKs and appliances that trust certificates outside the browser may not be covered. Ask critical vendors whether they've updated trust stores and rebuilt Go, Python and Node.js components, and when.

Want to see which of your vendors may still need trust-store updates or rebuilds after the eMudhra compromise? Book a demo.

Contact us / Book a demo

Talk to Rescana about this advisory, or book a demo of the platform.