Back to Blog
ArticleOctober 22, 2026

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

Listen to this article

Uses your device’s available voices. Voice and speed changes apply at the next passage.

eMudhra CA Compromise: Eight Weak Private Keys Trigger Emergency Browser Blocks
On This Page3 sections

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, 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, 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 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 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.

Share this article

Referenced Tools

Browse entries that are adjacent to the topics covered in this article.

Explore directory