Eight intermediate certificate authority (CA) certificates operated by Indian CA eMudhra were compromised because their private keys were generated with almost no randomness, allowing anyone holding the public certificates to recover the keys and forge trusted TLS or code-signing certificates. The company revoked all eight intermediates on October 18, 2026, and browser vendors have rushed to block the affected chains.
According to TrendAI, the compromised P-384 keys had effective lengths between 3 and 8 bits, compared with roughly 384 bits for a normal key. Mozilla’s incident record described them as extremely small integers that could be recovered almost instantly from the public certificates. The keys came from a batch of 24 intermediates generated on April 30, 2025.
eMudhra said a flawed key wrap/unwrap script used during that day’s key-generation ceremony produced a second set of much weaker private keys whose labels resembled the correct keys, and staff selected the weak versions when preparing the intermediates. The company told Help Net Security that seven of the eight intermediates were never deployed in production and the one that was deployed never issued end-entity certificates to customers.
Who is affected
Six of the compromised intermediates were TLS CAs — EM DV TLS CA – G3B/G3C, EM OV TLS CA – G3B/G3C and EM EV TLS CA – G3B/G3C — and two were code-signing CAs, EM OV CS CA – G3B/G3C, according to Openwall’s oss-security coordination post. Cisco Talos reported the TLS intermediates were trusted by Chrome, Mozilla and Apple, while the code-signing intermediates were trusted by Microsoft.
The intermediates chained to two widely trusted roots: emSign ECC Root CA – G3 and AAA Certificate Services, operated by Comodo, according to TrueNAS’s impact statement. Sectigo revoked related cross-signed certificates on October 19.
The biggest remaining exposure is outside browsers. Cloudflare warned, in comments reported by ITNews Australia, that tools such as curl on macOS still accepted the compromised chain despite Apple’s browser-level block. Servers, IoT devices, Linux distributions, language runtimes and applications that bundle their own root stores may trust forged certificates until they are updated. TrueNAS also cautioned that non-browser systems using the affected roots will continue to trust forged certificates until their trust stores change.
Exploitation status
As of the oss-security post’s publication, certificate transparency (CT) logs showed no certificates issued from the compromised intermediates, and eMudhra has said none were used to sign customer certificates. However, the post warned that abuse of the derived keys is likely in the near future, particularly through unlogged certificates or future logged certificates trusted by clients that do not enforce revocation or CT checking. Palo Alto Networks Unit 42 said attackers with the keys could sign unauthorized TLS certificates and conduct man-in-the-middle attacks, and TrendAI noted that code-signed binaries would remain valid on systems with unupdated trust stores.
What browser vendors did
Mozilla said it received the report at 20:06 UTC on October 17, independently recovered the private keys to confirm the flaw, and pushed OneCRL blocking updates that reached Firefox users with standard configurations by 22:59 UTC the same day. Mozilla also released Firefox 158.0.1, ESR 115.43.1 and ESR 153.5.1 for users who did not receive OneCRL updates, and removed the signing root from NSS 3.131.1 to protect applications that use Mozilla’s trust store directly.
BleepingComputer reported that Google blocked the certificates via CRLSets and that Apple and Microsoft acted through their root programs. Mozilla and Chrome are now moving to remove trust in emSign ECC Root CA – G3 entirely, per ITNews Australia’s reporting, and eMudhra has ceased issuing certificates under that root. The company estimates around 30,000 existing certificates under the root need migration.
What to do now
- Revoke and reissue any certificates chaining through the eight affected intermediates, as advised by Unit 42 and Cisco Talos.
- Update or rebuild trust stores — including those in servers, appliances and non-browser tools — to distrust the affected intermediates and, where appropriate, emSign ECC Root CA – G3 and AAA Certificate Services.
- Ensure Firefox installations are on 158.0.1, ESR 115.43.1 or ESR 153.5.1, or receive OneCRL updates, and that NSS-based applications use version 3.131.1 or later.
- Review PKI dependencies for services that use eMudhra chains under the G3 root and begin migration to alternative certificate chains.
Several questions remain open. There is no public evidence that forged certificates have been used in targeted attacks or in environments that do not log to CT, but that possibility cannot be ruled out. The number of non-browser systems and devices still trusting the compromised chains is unknown, as is how long full ecosystem-wide remediation will take. It is also unclear what long-term action browser root programs or regulators may take against eMudhra beyond the current revocations and distrust steps.
One Response