CTIPilot
AI-generated · no human review · verify critical claims against the linked source. how it works →

eMudhra intermediate CA private-key compromise (October 2026)

incident · incident:emudhra-intermediate-ca-key-compromise-2026-10

Eight eMudhra intermediate CA keys generated in April 2025 were generated with too little randomness, which BleepingComputer, citing Mozilla's incident report, puts at values below 256; reported on 2026-10-17, blocked by Firefox, Chrome, Apple and Microsoft platforms and revoked by eMudhra, with the emSign ECC Root CA - G3 root removed from NSS and, from 2026-10-27, from the Chrome Root Store (Google, Mozilla, the incident tracker and BleepingComputer, 2026-10-20).

Aliases: eMudhra CA compromise, emSign ECC Root CA - G3 removal

Coverage
1
first 2026-10-21 → last 2026-10-21
Latest activity
2026-10-21
Eight eMudhra CA keys were guessable; browsers are protected, Go, Python, Rust and curl stacks need updates
Peak priority
notable
1 notable
Targets
·
no sector or region stated
Sources cited
5
5 hosts

Action items (1)

Do-now tasks recorded on the entries about eMudhra intermediate CA private-key compromise (October 2026), newest first. Check the date before acting on an older one.

  • Update the trust store or toolchain of every non-browser TLS client that keeps its own CA bundle or does not check revocation (Go 1.27.3 or 1.26.10, Python certifi 2026.10.19, rustls-webpki 0.103.16, webpki-roots 1.0.10, the curl CA bundle of 2026-10-20, the distribution ca-certificates package, container base images) and rebuild images that embed an older bundle, then confirm with curl against the tracker's test host that the client now rejects the certificate; replace before 2026-10-27 every TLS certificate your organisation holds that chains to emSign ECC Root CA - G3.
    2026-10-21Eight eMudhra CA keys were guessable; browsers are…

Defender insights

What each entry about eMudhra intermediate CA private-key compromise (October 2026) tells a defender to do, newest first.

2026-10-21NOTABLEEight eMudhra CA keys were guessable; browsers are protected, Go, Python, Rust and curl stacks need updates

Exposure · triage · detection

Story timeline

  1. 2026-10-21eMudhra: the private keys of eight intermediate CA certificates were trivially recoverable, so anyone could forge trusted HTTPS certificates; browsers block them, clients with their own trust store or no revocation checking need an update (CVE-2026-111943 in Go)
    active-threatsEight eMudhra CA keys were guessable; browsers are protected, Go, Python, Rust and curl stacks need updates

Hunting pivots

Tags
patch-availablesupply-chain
ATT&CK techniques (1 across 2 tactics)

1 technique observed across 1 entry about this entity, derived from entry metadata and body evidence, never asserted without a published entry behind it · pinned to MITRE ATT&CK v20.0 · compare on the matrix · Navigator layer (JSON)

  • Credential AccessAdversary-in-the-Middle
  • CollectionAdversary-in-the-Middle

Credential Access TA0006

T1557Adversary-in-the-Middle×1

Adversaries may attempt to position themselves between two or more networked devices using an adversary-in-the-middle (AiTM) technique to support follow-on behaviors such as Network Sniffing, Transmitted Data Manipulation, or replay attacks (Exploitation for Credential Access). By abusing features of common networking protocols that can determine the flow of network traffic (e.g. ARP, DNS, LLMNR, etc.), adversaries may force a device to communicate through an adversary controlled system so they can collect information or perform additional actions.

Evidence: 2026-10-21/emudhra-intermediate-ca-keys-recoverable-trust-store-updates · ATT&CK page ↗

Collection TA0009

T1557Adversary-in-the-Middle×1

Adversaries may attempt to position themselves between two or more networked devices using an adversary-in-the-middle (AiTM) technique to support follow-on behaviors such as Network Sniffing, Transmitted Data Manipulation, or replay attacks (Exploitation for Credential Access). By abusing features of common networking protocols that can determine the flow of network traffic (e.g. ARP, DNS, LLMNR, etc.), adversaries may force a device to communicate through an adversary controlled system so they can collect information or perform additional actions.

Evidence: 2026-10-21/emudhra-intermediate-ca-keys-recoverable-trust-store-updates · ATT&CK page ↗

Entries about eMudhra intermediate CA private-key compromise (October 2026) (1)

2026-10-21 · view entry permalink →

NOTABLENATOA1

eMudhra: the private keys of eight intermediate CA certificates were trivially recoverable, so anyone could forge trusted HTTPS certificates; browsers block them, clients with their own trust store or no revocation checking need an update (CVE-2026-111943 in Go)

On 2026-10-17 a researcher reported to the Chrome Root Program, and Mozilla received a report the same day, that the private keys of eight eMudhra subordinate CA certificates were compromised: the keys were generated with insufficient randomness, which lets anyone forge trusted HTTPS certificates to impersonate any website against clients that have not removed trust in those CAs (Google, 2026-10-20; Mozilla, 2026-10-20). BleepingComputer, citing Mozilla's incident report, says all eight were P-384 keys generated in April 2025 with values below 256, so testing 256 numbers recovers a key, and that eMudhra blames a key-generation script error and found no evidence of end-user certificates (BleepingComputer, 2026-10-20). Google reports that no certificates chaining to the six TLS intermediates were logged to Certificate Transparency before it blocked them, so CT-enforcing clients such as Chrome could not have been attacked (Google, 2026-10-20); the tracker adds that many clients outside browsers do not enforce CT and that it is not known whether attackers used the flaw against them (Dennis Jackson, 2026-10-20).

Chrome blocked the intermediates on 2026-10-17, Firefox through OneCRL the same day, Apple devices on 2026-10-19 and Microsoft platforms on 2026-10-20, and eMudhra revoked all eight (Dennis Jackson, 2026-10-20; BleepingComputer, 2026-10-20). Google removed the root that signed them, emSign ECC Root CA - G3, from the Chrome Root Store, with the removal expected to reach devices on 2026-10-27, after which some legitimate certificates chaining to it will stop working in Chrome (Google, 2026-10-20); Mozilla removes the signing root from NSS 3.131.1 to protect applications that use its trust store without OneCRL (Mozilla, 2026-10-20). Go 1.27.3 and 1.26.10 filter chains that contain the intermediates in crypto/x509, tracked as CVE-2026-111943 (Go team, 2026-10-20).

Triage: a site that still chains to emSign ECC Root CA - G3 failing in Chrome after 2026-10-27 is the announced root removal, not an attack (Google, 2026-10-20).

enabling anyone to forge trusted HTTPS certificates to impersonate any website against clients that have not yet removed trust in those CAs.

Google (Chrome Root Program and Android Security) 2026-10-20

many other clients do not consume revocation information and require software updates to ensure they no longer trust the compromised intermediates.

We do not know if attackers exploited the flawed key generation to target these clients.

Dennis Jackson (eMudhra intermediate CA compromise incident tracker) 2026-10-20

crypto/x509: mitigation for security concerns with a specific Certificate Authority

Go team (golang-announce) 2026-10-20
incident21 Oct 03:43Zmulti-sourceOpen finding →
Sources: Google (Chrome Root Program and Android Security) · Dennis Jackson (eMudhra intermediate CA compromise incident tracker) · Mozilla Security Blog · Go team (golang-announce) · BleepingComputer

explore in graph

Where this entity is cited

  • Threats1

Source distribution

  • bleepingcomputer.com1 (20%)
  • blog.google1 (20%)
  • blog.mozilla.org1 (20%)
  • emudhra.we-have-a-problem.com1 (20%)
  • groups.google.com1 (20%)
All cited sources (5)