# eMudhra CA Compromise: Eight Weak Private Keys Trigger Emergency Browser Blocks

Eight eMudhra CA private keys were trivially recoverable, prompting browser blocks, certificate distrust and urgent updates for affected software.

Canonical URL: https://aiidelist.com/blog/emudhra-ca-compromise-weak-private-keys-browser-blocks

Language: en

Published: 2026-10-22

Updated: 2026-10-22

## What Happened

**Google and Mozilla deployed emergency certificate blocks after a researcher reported eight compromised eMudhra intermediate certificate authority keys on October 17, 2026.** The weakness could allow forged HTTPS certificates to impersonate websites on clients that still trust the affected authorities. 

According to [Mozilla's investigation](https://bugzilla.mozilla.org/show_bug.cgi?id=2083449), all eight P-384 private keys were integers below 256. That leaves just **255 possible nonzero values per key**, making recovery trivial; Mozilla independently reproduced the finding.

The affected authorities included **six TLS intermediates and two code-signing intermediates**. Some also had Sectigo cross-signed certificates, extending the remediation work across additional trust paths. 

The initial response moved quickly:

- **Chrome:** Google deployed a CRLSet block at 19:45 UTC on October 17, targeting the affected public keys without requiring a browser restart.
- **Firefox:** Mozilla completed its initial OneCRL blocking process at 22:59 UTC that day.
- **Certificate revocation:** Mozilla's incident record documents eMudhra's revocations on October 18; Sectigo subsequently confirmed revocation of the affected cross-signed certificates. 

In its [October 21 statement](https://emudhra.com/en/press-release/emudhra-statement-distrust-global-tls-intermediate-root-ca), Bengaluru-based eMudhra attributed the problem to an April 30, 2025 key-generation ceremony. The company said a wrap/unwrap procedure produced weak keys alongside the intended strong keys, despite the use of certified hardware security modules; its root-cause investigation remains ongoing. 

## Why It Matters

**Compromising a trusted issuing CA can undermine website authentication.** An attacker able to intercept or redirect a connection could present a forged certificate to an unprotected client and potentially capture credentials or alter traffic.

This does not establish that all HTTPS traffic became readable. The demonstrated weakness concerns particular CA keys, and successful interception still depends on the client's trust decisions and the attacker's access to the connection.

Google reported that no TLS certificates chaining to the six affected intermediates had appeared in Certificate Transparency logs before its block. Consequently, fraudulent certificates from those intermediates could not have been used against clients enforcing CT, including Chrome's default configuration. 

[eMudhra says](https://emudhra.com/en/post/certificate-security-incident) it had issued no certificates from the eight affected intermediates and suffered no infrastructure compromise or data breach. Those statements describe the company's findings; they do not independently establish the absence of attempted abuse elsewhere. 

The remaining exposure includes software without effective certificate-revocation updates. Mozilla specifically warned that many endpoints lack mechanisms to receive and enforce this information. 

## What's Next

**Remediation now extends beyond blocking the eight intermediates.** Google says it has removed `emSign ECC Root CA - G3` from the Chrome Root Store, which will also affect legitimate certificates chaining to that root. Its root-program team expects the relevant Stable rollout on **October 27, 2026, Pacific time**. 

Affected users and operators have several concrete actions:

- **Node.js operators:** Install **22.23.4, 24.22.1 or 26.12.1**, as appropriate for the deployed release line, or a later supported security release. The [October 21 security advisory](https://nodejs.org/en/blog/vulnerability/october-2026-security-releases) explicitly includes CA-certificate updates addressing the eMudhra incident. 
- **Firefox for Android users:** Update to **158.0.2 or later**. Mozilla reported that some Android profiles failed to apply the updated blocklist at startup and identified this release as the fix. 
- **Affected certificate subscribers:** Coordinate replacement certificates and verify deployment of the replacement chain. eMudhra says it is working with customers to prevent service disruption. 

The investigation must still explain how weak keys entered the trusted hierarchy and why earlier checks failed to identify them. Google has requested further answers about key handling, prior incidents and customer migration progress.