Compromised CA Keys Force Browser and Trust-Store Fixes
Compromised CA keys belonging to eight eMudhra intermediate certificate authorities prompted emergency blocks in browsers and fixes across Go, Firefox, NSS, Python and Rust software. Mozilla and the Chrome Root Program confirmed the compromise on October 20, after a researcher demonstrated possession of all eight private keys. A private key is the secret material used to approve digital certificates, while an intermediate certificate authority (CA) issues the certificates websites present to visitors. Control of such a key could therefore allow someone to issue a certificate for any website that affected software might accept.
The researcher reported the problem on the evening of October 17 and proved control by signing the same message with each of the eight keys. Chrome received the report at 18:05 UTC, verified the findings and deployed a CRLSet block at 19:45 UTC. CRLSet is Chrome's remotely delivered list of certificates that must no longer be trusted. Mozilla received the report at 20:06 UTC and completed a OneCRL block for standard Firefox installations at 22:59 UTC. OneCRL performs a similar revocation role in Firefox. Both lists are fetched automatically, so normal browser installations did not require a restart or a full browser update.
Six affected intermediates were intended for Transport Layer Security (TLS), the system that authenticates websites and encrypts browser connections. They were EM DV TLS CA - G3B, EM DV TLS CA - G3C, EM OV TLS CA - G3B, EM OV TLS CA - G3C, EM EV TLS CA - G3B and EM EV TLS CA - G3C. The other two, EM OV CS CA - G3B and EM OV CS CA - G3C, were restricted to code signing. Chrome did not separately block the code-signing intermediates because its website certificate verifier will not construct a TLS trust path through an intermediate limited to code signing.
The six TLS intermediates were issued by emSign Root TLS CA - G3 and ultimately linked to emSign ECC Root CA - G3. Each of the eight also had a second certificate using the same public key, cross-signed under Sectigo's AAA Certificate Services root. Cross-signing gives the same key another route to a trusted root. Chrome's response matched the public keys rather than only the individual certificates, so its block also covered those copies. Firefox and Chrome had already stopped trusting AAA Certificate Services for websites in April 2025, while Apple's root list for iOS 26 and macOS 26, published in December 2025, still included it.
The Chrome Root Program found no TLS certificate issued through the six website intermediates in Certificate Transparency (CT) logs before its block. CT is a public record of website certificates, and Chrome and other browsers that require logging would not normally trust an unlogged certificate. This limits the evidence of misuse visible through CT, but does not settle whether the keys were used elsewhere. It remains unknown how or when the keys left eMudhra, or whether anyone other than the reporting researcher obtained them. No available method identifies earlier misuse beyond searching the certificates recorded in CT.
eMudhra revoked all eight certificates. Apple blocked them on October 19, Microsoft followed on October 20, and other trust stores were notified on October 19, according to an incident page published by a Mozilla cryptography engineer. Mozilla said it did not currently believe other CAs were affected. Chrome reported that it checked every other CA certificate in its store and found no further examples of the same failure mode.
Software that does not reliably retrieve revocation information needs a code or trust-bundle update. Go addressed the keys in versions 1.27.3 and 1.26.10 under CVE-2026-111943. Its standard-library filter rejects any chain containing one of the eight keys, including when Go uses the macOS or Windows system verifier, and it cannot be disabled through a setting. Existing programs must be rebuilt with a fixed Go release. Go 1.25 and older are unsupported and did not receive the change. The Go project used its URGENT process, although its issue and release notes do not specify whether that reflected exploitation or a wider threat to ecosystem integrity. A Go maintainer said embedding the affected keys in code was currently necessary because revocation does not reliably reach applications through poorly maintained Linux root stores.
Firefox 158.0.1, ESR 115.43.1 and ESR 153.5.1 include the OneCRL information under CVE-2026-113470 for installations that cannot receive Remote Settings. Standard Firefox installations that received the remotely delivered block need no additional action. NSS 3.131.1 removes emSign ECC Root CA - G3 from its trusted list. Python certifi 2026.10.19 and Rust webpki-roots 1.0.10 remove that root from their bundles. Homebrew ca-certificates 2026-09-25_1 excludes emSign ECC Root CA - G3, emSign Root TLS CA - G3 and AAA Certificate Services by public key.
Removing an entire root has broader effects than blocking only the eight compromised keys. It also rejects legitimate certificates that depend on that root. Mozilla warned that some servers could become unavailable to non-Firefox software using the NSS trust list until their operators move to different certificate chains. Mozilla advises trust-store operators to rely on revocation only where clients consistently check it and refuse connections when checking fails. Otherwise, they should block the eight intermediates directly where possible or consider removing the roots that issued them.
Node.js had no released fix at the time described, although a draft change would block the eight keys. Composer's ca-bundle also had no released update, with an open change proposing removal of emSign ECC Root CA - G3. Mozilla removed that root from NSS on October 20. Chrome plans to remove it in version 43 of its root store and is reviewing eMudhra's other included root, emSign Root CA - G1. The CA's trust-services repository had no incident notice as of October 20, and Mozilla said work on the root cause was continuing with the CA, other root programs and downstream trust stores.
For organisations assessing browser, application and trust-store exposure, AEU-I is the AEU Group service focused on security-first IT, infrastructure and consulting. Website operators should verify whether their current certificate chain depends on any removed root, while software teams need to distinguish automatic browser protection from libraries and compiled applications that require explicit updates or rebuilding.