# CVE-2026-111943: Go Blocks Compromised eMudhra CA Keys After Certificate Authority Incident

> Private keys for eight eMudhra intermediate CA certificates (six TLS, two code-signing) were trivially recoverable because a flawed April 2025 key ceremony produced weak keys, some of them single-byte values. Chrome, Mozilla, Apple and Microsoft blocked the certificates, and Go 1.26.10 and 1.27.3 reject chains containing the eight keys (CVE-2026-111943). No TLS certificate chaining to the six website intermediates had been logged to Certificate Transparency before Chrome blocked them.

- **Published:** 2026-10-21T11:21:00Z
- **Last reviewed:** 2026-10-21T11:21:00Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-4034
- **ID:** TL-2026-4034
- **Severity:** HIGH
- **Category:** VULNERABILITY
- **Status:** PATCHED
- **Detections:** 9 · **IOCs:** 15 (full data via the Threadlinqs MCP server — Purple tier)
- **CVEs:** CVE-2026-111943, CVE-2026-113470

## Description

On 2026-10-17 a researcher known as Wayne reported to Chrome (18:05 UTC), Mozilla (20:06 UTC) and other root programs that the private keys for eight eMudhra intermediate CA certificates were compromised. The researcher demonstrated possession by signing a message ("We have a problem here - Wayne") with all eight keys. The affected intermediates are EM DV TLS CA - G3B/G3C, EM OV TLS CA - G3B/G3C, EM EV TLS CA - G3B/G3C and EM OV CS CA - G3B/G3C (code signing). The G3B certificates belong to eMudhra BV (Netherlands) and the G3C certificates to eMudhra Inc. (United States). They chain to emSign ECC Root CA - G3 and were also cross-signed by Sectigo's AAA Certificate Services root. Per Scott Helme's analysis, the P-384 private keys were single-byte integers, so recovery means computing 1xG, 2xG, 3xG and so on until the result matches the certificate's public key. That is at most 255 steps and finishes in milliseconds. Mozilla independently reproduced the recovery within about two hours of the report.

Root cause, per eMudhra's statement: a flaw in the key wrap/unwrap procedure of the Key Generation Ceremony held on 2025-04-30 produced a second, weak set of keys alongside the intended strong keys, and the weak set was what was published to browser root stores. Reporting on the Mozilla incident ticket attributes it to an HSM ceremony script bug combined with a human error in selecting the wrong key pair for signing. eMudhra says seven of the intermediates were never deployed in production, one was deployed but issued no end-entity certificates, no root CA keys were compromised, and customer impact was limited to one US customer ecosystem. All eight intermediates were revoked on 2026-10-19.

Impact: anyone able to compute these keys could mint certificates that chain to a trusted root. Against TLS clients that do not require Certificate Transparency or revocation checking, a network-positioned attacker could use such certificates to impersonate websites and read or modify traffic. The code-signing intermediates raise the risk of forged code-signing certificates. Browsers that require CT logging, such as Chrome, were largely protected, because no TLS certificate chaining to the six TLS intermediates appeared in CT logs before the block. Non-browser clients (curl, Python, Node.js, Go, Java, git, package managers) lack CT checking and default revocation validation and need explicit updates.

Response: Chrome deployed a CRLSet block at 19:45 UTC on 2026-10-17. Mozilla distributed a OneCRL block at 22:59 UTC the same day. Apple blocked the certificates on 2026-10-18/19, and Microsoft on 2026-10-19/20. Android received a block via Google Play Services. Fixed software releases: Go 1.26.10 and 1.27.3 (CVE-2026-111943, rejecting chains that contain the eight keys, rebuild required), Firefox 158.0.1, ESR 115.43.1 and ESR 153.5.1, NSS 3.131.1 (removes emSign ECC Root CA - G3), Python certifi 2026.10.19, Rust webpki-roots 1.0.10, Composer ca-bundle 1.6.0/1.4.16, and Cloudflare cloudflared 2026.10.2. A Node.js fix was pending at the time of the cited reporting. No in-the-wild abuse was demonstrated before the block. CVSS is not stated by any source, and severity HIGH is analyst-assigned.

## MITRE ATT&CK

- T1587.003 Digital Certificates
- T1649 Steal or Forge Authentication Certificates
- T1557 Adversary-in-the-Middle
- T1557 Adversary-in-the-Middle
- T1553 Subvert Trust Controls
- T1553.002 Code Signing

## Sources

- [CVE-2026-111943: Go Blocks Compromised eMudhra CA Keys After Certificate Authority Incident](https://socprime.com/blog/cve-2026-111943-analysis/)
- [Protecting Firefox users following the compromise of eMudhra intermediate certificates](https://blog.mozilla.org/security/2026/10/20/protecting-firefox-users-following-the-compromise-of-emudhra-intermediate-certificates/)
- [Eight eMudhra CA Keys Compromised, Triggering Emergency Fixes Across Browsers and Software](https://thehackernews.com/2026/10/eight-emudhra-ca-keys-compromised.html)
- [Eight Bits of Trust; eMudhra's CA keys cracked in milliseconds](https://scotthelme.co.uk/eight-bits-of-trust-emudhras-ca-keys-cracked-in-milliseconds/)
- [eMudhra Statement on Recent Certificate Security Incident](https://emudhra.com/en/post/certificate-security-incident)
- [eMudhra Intermediate CA Compromise (proof and affected intermediates list)](https://emudhra.we-have-a-problem.com/)
- [eMudhra intermediate CA compromise (LWN.net)](https://lwn.net/Articles/1101643/)
- [eMudhra CA Key Compromise: Chrome and Firefox Have Blocked It, Non-Browser Clients Need Updates Now](https://www.rescana.com/post/emudhra-intermediate-ca-key-compromise-october-2026)
- [Indian certification authority eMudhra's private keys compromised](https://www.theregister.com/security/2026/10/20/indian-certification-authority-emudhras-private-keys-compromised-one-of-them-was-the-number-4/5304312)

## Full data

Detection queries (Splunk SPL / Microsoft KQL / Sigma) and IOC values require the Threadlinqs MCP server (Purple tier): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-4034