"We have a problem here - Wayne," signed with each of the eight keys, is how the incident began — a terse, unmistakable alert that a security researcher (credited only as Wayne) sent to the root programs on the evening of October 17, 2026.
Scope of the cryptographic compromise
Eight intermediate certificate authority (CA) private keys belonging to eMudhra's emSign hierarchy were compromised, according to confirmations from Mozilla and Google's Chrome Root Program on October 20. The eight include three pairs (G3B and G3C) covering domain-validated TLS, organization-validated TLS, extended-validation TLS, and code-signing intermediates: 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, EM EV TLS CA - G3C, EM OV CS CA - G3B, and EM OV CS CA - G3C.
Six of those intermediates were TLS authorities that chained to emSign Root TLS CA - G3 and ultimately to emSign ECC Root CA - G3, a root present in Chrome and Apple's stores and, until October 20, in Mozilla's. Each intermediate also existed as a second certificate with the same public key cross-signed by Sectigo under its AAA Certificate Services root.
How browsers and root programs acted
The disclosure timeline is precise: the Chrome Root Program received the report at 18:05 UTC on October 17 and deployed a CRLSet update blocking the six TLS intermediates by 19:45 UTC the same day. Mozilla's team received the report at 20:06 UTC and finished pushing a OneCRL block to standard Firefox installations at 22:59 UTC. Apple blocked the certificates on October 19 and Microsoft on October 20; other trust stores were notified on October 19.
Chrome's block matches the public key rather than the certificate, which also catches the Sectigo cross-signed copies. Chrome noted that no TLS certificate chaining to the six intermediates had been logged to Certificate Transparency (CT) before Chrome's block, so none could have been trusted by default in Chrome or in any browser that requires CT logging. Chrome also said it checked every other CA certificate in its store and "found no other instances of this failure mode."
Chrome did not need to block the two code-signing intermediates because its TLS verifier will not build a path through an intermediate restricted to code signing.
Nobody's watching your logs at 2 AM.
Full SOC coverage without building one. Nubivance deploys and manages Rapid7 InsightIDR and MDR for organizations that need detection and response, not another dashboard.
Get coverageSoftware fixes across the ecosystem
Not all software relies on browser-style revocation pushes. Several downstream bundles and runtimes released fixes on October 20. Go issued an URGENT-track security release that embeds a filter in the standard library rejecting any chain containing one of the eight compromised keys; the eight hash values in Go's code match the eight certificates. The Go change applies to Go's own verifier and to the macOS and Windows system-verifier paths and cannot be turned off; programs pick up the change only when rebuilt with the new release. Go 1.25 and older are out of support and will not receive fixes.
Other fixes removed roots rather than blocking keys: certifi, webpki-roots, and Homebrew's ca-certificates dropped emSign ECC Root CA - G3 from their bundles. Homebrew additionally removed Sectigo's AAA Certificate Services root and emSign Root TLS CA - G3. Mozilla made the same removal in NSS. Those removals cut off any legitimate certificates that chained to those roots; Mozilla warned some servers will become unavailable to non-Firefox users of its trust list until those servers move to new certificate chains.
Firefox installations with Remote Settings enabled require no action; the October 20 releases carry the block list for installations where Remote Settings is disabled or blocked on the network. None of the published remedies provide a way to detect past misuse of the keys beyond searching Certificate Transparency logs for logged certificates.
What this means for technologists, enterprises, and end users
- Technologists and security teams: Rebuild and redeploy Go binaries with the patched runtime if they rely on Go's standard library verifier, and update any root-bundle-consuming software (certifi, webpki-roots, Homebrew) to pick up the removals. Where revocation is reliably checked and enforced, no further steps are needed; where software does not check revocation, a bundle update or removing trust in the affected roots is necessary.
- Enterprises and service operators: Operators whose certificates chained to emSign ECC Root CA - G3 or emSign Root TLS CA - G3 should plan to obtain new certificate chains promptly. Mozilla cautioned that some servers will be unreachable to non-Firefox users until they move to new chains because several trust stores removed the root.
- End users: Browsers that fetch CRLSets or OneCRL will receive the blocks without user action; users of programs that rely on static root bundles or on runtimes that do not check revocation may remain exposed until those bundles or binaries are updated.
eMudhra's status and outstanding questions
eMudhra revoked the eight certificates, and Mozilla removed emSign ECC Root CA - G3 from NSS on October 20. The Chrome Root Program said it will remove the same root in version 43 of its root store and is reviewing the status of eMudhra's other root, emSign Root CA - G1. Mozilla said it is working with the CA, other root programs and downstream trust stores on root-cause analysis and will post more when it can; eMudhra's trust-services repository carried no notice as of October 20.
How and when the keys left eMudhra, and whether anyone other than the researcher holds copies, remain unresolved. On Go's issue thread, maintainers declined to name the CA there, citing "specific security concerns around their operation" in release notes; Filippo Valsorda, who maintains Go's cryptography packages, wrote that the keys are compromised and revoked, that Linux root stores are too poorly maintained for revocation to reach applications reliably, and that embedding the keys in code was the only practical option for now.
The immediate technical response — rapid browser blocks, root removals, and urgent runtime fixes — closed the most direct paths an attacker could use. The broader questions that remain are procedural and forensic: how the private keys escaped their owner, who else may possess them, and how many servers or binaries will need remediation as root stores and runtimes catch up. Root programs and eMudhra say they will pursue those answers and report back.
