Resources · Research · 02
Eight intermediate CA private keys, sixteen cross-signed certificates, and a same-day browser response, what defenders and software-supply-chain owners need to know.
On 20 October 2026, Mozilla and Google's Chrome Root Program publicly confirmed that the private keys of eight eMudhra intermediate certificate authorities had been compromised. The report arrived three days earlier, on 17 October, from a researcher identified only as “Wayne”, who proved control of each key by signing a challenge message with it; the disclosure site and proof archive were published by Mozilla cryptography engineer Dennis Jackson [we-have-a-problem.com] [The Hacker News].
The eight keys exist in the wild as sixteen certificate objects, because each intermediate was cross-signed twice: once under an eMudhra emSign root and once under Sectigo's widely trusted AAA Certificate Services root. Six of the keys are for issuing TLS (website) certificates across domain-, organisation- and extended-validation tiers; the remaining two are code-signing intermediates [we-have-a-problem.com].
The response was unusually fast. Browsers blocked the certificates the same day they were reported, Chrome via its CRLSet mechanism and Firefox via OneCRL, with Firefox's block reaching standard installations under three hours after Mozilla was notified [Mozilla] [The Hacker News]. Over the following days, Apple, Microsoft, the Go toolchain, NSS and several language ecosystems shipped their own updates.
Possession of an intermediate key is a serious capability: the holder could, in principle, mint certificates that clients would trust. But at the cutoff there is no public evidence of real-world exploitation, no fraudulent public TLS certificate was found in Certificate Transparency before the blocks, and Mozilla reports no public TLS server certificates issued under the affected roots beyond internal test certificates [Mozilla] [Cyber Kendra]. The root CA keys are not compromised, and this does not mean every eMudhra certificate, customer or signature is affected [we-have-a-problem.com].
A root CA is a certificate that browsers and operating systems trust implicitly; its key is kept offline and guarded. A root rarely signs websites directly, it delegates to intermediate CAs. An intermediate issues the leaf certificates that individual websites and software publishers actually use. A cross-signed certificate is the same intermediate key presented under a second root, so older or different clients that trust either root will accept it.
In this incident the compromise sits at the intermediate layer. Because each affected key was cross-signed under both an emSign root and Sectigo's AAA Certificate Services, blocking a single certificate is not enough, mitigations have to target the underlying key so every chain that uses it is caught. Go's fix does exactly this, hashing the public key rather than the certificate [Cyber Kendra].
Marking a certificate revoked does not make every client stop trusting it. Browsers consume centralised blocklists, Firefox's OneCRL and Chrome's CRLSet, which is why they were protected within hours [Mozilla] [Chromium]. But many clients do no revocation checking at all, or ship their own frozen trust list, so they remain exposed until updated [Mozilla Hacks].
A small set of root certificates that browsers and operating systems ship and trust implicitly. The eMudhra and Sectigo roots here are not compromised.
The roots delegate to intermediate CAs. Eight eMudhra intermediate private keys were compromised, each existing as two cross-signed certificates (under an emSign root and under Sectigo's AAA Certificate Services).
Whoever holds an intermediate key could, in principle, mint website (TLS) or code-signing leaf certificates that chain to a trusted root, within the intermediate's constraints. This is a capability, not a confirmed event.
The risk only materialises for a relying party (browser, app, runtime, device) that still trusts the intermediate, has no revocation signal, and whose traffic an attacker can intercept or redirect.
The end impact would be website/service impersonation or a wrongly-trusted software signature, only where every precondition above holds.
Browser blocklists (CRLSet, OneCRL), OS trust updates and runtime/app trust-store updates each break the chain at the "client still trusts it" step, at different speeds.
| Intermediate (CN) | Issuing root | Use | Expires | Revoked |
|---|---|---|---|---|
| EM DV TLS CA - G3B | emSign Root TLS CA - G3 | TLS DV | 2040-04-28 | 2026-10-18 |
| EM DV TLS CA - G3B | AAA Certificate Services (Sectigo) | TLS DV | 2028-12-31 | 2026-10-19 |
| EM OV TLS CA - G3B | emSign Root TLS CA - G3 | TLS OV | 2040-04-28 | 2026-10-18 |
| EM OV TLS CA - G3B | AAA Certificate Services (Sectigo) | TLS OV | 2028-12-31 | 2026-10-19 |
| EM EV TLS CA - G3B | emSign Root TLS CA - G3 | TLS EV | 2040-04-28 | 2026-10-18 |
| EM EV TLS CA - G3B | AAA Certificate Services (Sectigo) | TLS EV | 2028-12-31 | 2026-10-19 |
| EM DV TLS CA - G3C | emSign Root TLS CA - G3 | TLS DV | 2040-04-28 | 2026-10-18 |
| EM DV TLS CA - G3C | AAA Certificate Services (Sectigo) | TLS DV | 2028-12-31 | 2026-10-19 |
| EM OV TLS CA - G3C | emSign Root TLS CA - G3 | TLS OV | 2040-04-28 | 2026-10-18 |
| EM OV TLS CA - G3C | AAA Certificate Services (Sectigo) | TLS OV | 2028-12-31 | 2026-10-19 |
| EM EV TLS CA - G3C | emSign Root TLS CA - G3 | TLS EV | 2040-04-28 | 2026-10-18 |
| EM EV TLS CA - G3C | AAA Certificate Services (Sectigo) | TLS EV | 2028-12-31 | 2026-10-19 |
| EM OV CS CA - G3B | emSign Root CS CA - G3 | Code-signing OV | 2040-04-28 | 2026-10-18 |
| EM OV CS CA - G3B | AAA Certificate Services (Sectigo) | Code-signing OV | 2028-12-31 | 2026-10-19 |
| EM OV CS CA - G3C | emSign Root CS CA - G3 | Code-signing OV | 2040-04-28 | 2026-10-18 |
| EM OV CS CA - G3C | AAA Certificate Services (Sectigo) | Code-signing OV | 2028-12-31 | 2026-10-19 |
Fingerprints, serial numbers and SPKI hashes for every record are in the incident's machine-readable inventory [we-have-a-problem.com]. All sixteen objects carry revocation reason ca_compromise.
The researcher “Wayne” reports the eight keys and signed proofs; the Chrome Root Program receives it at 18:05 UTC, Mozilla at 20:06 UTC. [The Hacker News]
Chrome's CRLSet block for the six TLS intermediates is in place by 19:45 UTC. [The Hacker News]
Mozilla's OneCRL block reaches standard-settings Firefox installations by 22:59 UTC, under three hours after Mozilla was notified. [Mozilla]
The affected certificates are marked revoked with reason ca_compromise in the published inventory (emSign-issued on 18 Oct, Sectigo cross-signs on 19 Oct). [we-have-a-problem.com]
Apple blocks the certificates in its ecosystem; the incident is responsibly disclosed to downstream trust-store operators. [we-have-a-problem.com]
Mozilla and Chrome confirm publicly. Firefox 158.0.1/ESR (CVE-2026-113470), Go 1.27.3 and 1.26.10 (CVE-2026-111943), NSS 3.131.1 and Microsoft's block all land. Node.js and Composer remain pending. [The Hacker News]
Browsers were protected on 17 October, but the ecosystem fixes (Go, NSS, certifi, Electron) landed on 19 to 20 October and some components (Node.js, Composer) were still pending at the cutoff. A vendor advisory, an available fix and a deployed fix are three different moments [The Hacker News] [we-have-a-problem.com].
Chrome CRLSet and Firefox OneCRL pushed a block within hours, independent of app updates.
Apple (19 Oct) and Microsoft (20 Oct) updated OS trust; Windows/macOS apps that defer to the OS verifier inherit it.
Go bundles its own verifier and does no revocation checking, so it shipped a hardcoded key block (1.27.3 / 1.26.10). NSS-based clients update via NSS 3.131.1.
Python certifi, Rust webpki-roots, Electron and Homebrew ca-certificates ship their own trust and must be upgraded and redeployed. Node.js and Composer were pending at the cutoff.
Devices and images that pin trust or never receive revocation data stay exposed until manually updated.
No percentages of vulnerable installations are given, none is reliably knowable. The ordering reflects how the mitigation reaches each layer, not a count of affected systems.
| Component | Affected | Fixed version | Advisory | Status | Source |
|---|---|---|---|---|---|
| Google Chrome / Chromium | TLS intermediates trusted | CRLSet block (17 Oct); AAA root removal in root store v43 | CRLSet | Deployed | [The Hacker News] |
| Mozilla Firefox | < 158.0.1 and ESR | 158.0.1 · ESR 115.43.1 · ESR 153.5.1 | CVE-2026-113470 | Released 20 Oct | [Mozilla] |
| Go (crypto/x509) | ≤ 1.27.2 / ≤ 1.26.9 | 1.27.3 · 1.26.10 | CVE-2026-111943 | Released 20 Oct | [Go (Google)] |
| NSS | < 3.131.1 | 3.131.1 (removes emSign ECC Root CA - G3) | NSS advisory | Released 20 Oct | [The Hacker News] |
| Python certifi | < 2026.10.19 | 2026.10.19 | certifi release | Released 19 Oct | [Python certifi] |
| Rust webpki-roots | < 1.0.10 | 1.0.10 (and webpki-root-certs) | release notes | Released | [Rust rustls] |
| Electron | below listed | 44.9.1 · 43.8.1 · 42.11.16 | release notes | Released | [Electron] |
| Homebrew ca-certificates | prior | 2026-09-25_1 | formula update | Released | [we-have-a-problem.com] |
| Apple (OS trust) | pre-update | OS trust update | platform update | Blocked 19 Oct | [The Hacker News] |
| Microsoft (OS trust) | pre-update | OS trust update | platform update | Blocked 20 Oct | [The Hacker News] |
| Node.js | all bundling affected trust | n/a | n/a | Pending at cutoff | [we-have-a-problem.com] |
| Composer ca-bundle (PHP) | all bundling affected trust | n/a | n/a | Pending at cutoff | [we-have-a-problem.com] |
Certificate Transparency (CT) is a public, append-only log of issued TLS certificates. Analysts checked whether any leaf certificate chaining to the six affected TLS intermediates had been logged. The reported finding is that none was logged before the blocks went live, and Mozilla states no public TLS server certificates were issued under the affected roots beyond internal test certificates [Mozilla] [Cyber Kendra].
Two cautions matter. First, CT covers publicly logged TLS certificates only, it does not cover code signing, and the two code-signing intermediates are therefore outside what CT can reassure us about. Second, absence of a logged certificate is not proof that no misuse occurred; a certificate used without being logged, or used only against a narrow target, would not necessarily appear. The honest reading is: no misuse has been demonstrated, and the public TLS evidence to date is clean, not that misuse has been ruled out.
| Risk scenario | Affected assets | Preconditions | Inherent impact | Existing mitigation | Residual risk | Recommended action |
|---|---|---|---|---|---|---|
| TLS impersonation (public web/API) | Browsers and non-browser TLS clients | Attacker holds a TLS key AND can intercept/redirect AND client still trusts it | High | CRLSet, OneCRL, OS trust updates | Low for patched browsers; Medium for non-browser clients until updated | Patch browsers/OS; upgrade and redeploy runtimes |
| Code-signing abuse | Platforms accepting signatures under EM OV CS intermediates | Attacker holds a CS key AND platform accepts the chain AND it is not yet distrusted | High | OS code-signing distrust; timestamp policies | Medium where CS trust is not yet removed | Verify code-signing trust removal; re-check build/sign pipelines |
| Non-browser runtime exposure | Go, Node.js, containers, embedded, service meshes | Runtime still trusts the key and performs no revocation checking | High | Go block, certifi, webpki-roots, NSS updates | High until each runtime is upgraded and the app rebuilt | Inventory TLS libraries/CA bundles; rebuild and redeploy |
| Legacy / unmaintained systems | Old OS images, appliances, air-gapped devices | No revocation feed and no vendor update path | Medium | Manual trust-store update | High until manually remediated | Identify, isolate, apply compensating controls |
| TLS-inspection / proxy middleboxes | Outbound proxies, inspection appliances, API gateways | Device trusts affected intermediate for re-signing or validation | Medium | Vendor firmware updates | Medium until firmware updated | Confirm vendor update; validate rejection |
Do not indiscriminately remove broad root certificates as a reflex, distrusting a root can break legitimate services and should follow a technical impact assessment under change management. Do not run unverified commands copied from third-party pages on production systems.
Reading the incident's machine-readable inventory directly, three structural points stand out that are easy to miss in the headline “eight keys” framing [we-have-a-problem.com]:
These observations are IntelliXBOM's own reading of the published JSON and are offered as analysis, not as new facts about the compromise. They reinforce the central governance point: inventory trust by key, keep it current, and correlate it with advisories, which is the same discipline a software bill of materials brings to component risk.
No. The incident concerns eight specific intermediate CA private keys and their sixteen cross-signed certificate objects. It does not mean every eMudhra certificate, customer or signature is affected, and the root CA private keys are not reported compromised.
No. A compromised intermediate does not imply the root key was exposed. The roots the affected intermediates chain to are not reported compromised; some roots are being distrusted as a mitigation, which is a trust decision, not evidence of root-key compromise.
No, and this is the most common error. There are eight unique private keys but sixteen certificate objects, because each key was cross-signed under both an emSign root and Sectigo's AAA Certificate Services. The count of affected end-user websites is a separate, unestablished figure.
There is no public evidence of successful impersonation, fraudulent issuance, interception or data theft at the research cutoff. No fraudulent public TLS certificate was found in Certificate Transparency before the blocks. Absence of a logged certificate is not proof that no misuse occurred, but no misuse has been demonstrated.
Browsers were protected quickly through CRLSet and OneCRL, but many systems do not use browser revocation data. Language runtimes (Go, Node), application-bundled CA sets (certifi, webpki-roots, Electron), containers, embedded devices and TLS-inspection appliances each need their own update. A patched browser does not patch those.
Inventory where the affected trust lives, then upgrade and redeploy. For most organisations the exposure is not the browser but non-browser clients: rebuild Go/Electron apps on the fixed releases, upgrade certifi/webpki-roots and redeploy, and verify that production, not just the package manifest, now rejects the certificates.
Go's TLS verifier bundles its own logic and does not read browser blocklists or perform online revocation checks. The fix (1.27.3 / 1.26.10) hardcodes a block keyed on the public key, so it also catches the Sectigo cross-signs, but a program only gains it once rebuilt on the fixed toolchain.
Primary technical artifact. Publishes the signed proof-of-possession for each of the eight intermediate keys, the affected-certificate inventory, the root inventory and the software mitigation list.
Machine-readable inventory: 16 certificate objects covering 8 unique public keys (each key cross-signed once under an emSign root and once under Sectigo's AAA Certificate Services), with fingerprints, serials, SPKI hashes and revocation status.
Lists the roots the affected intermediates chain to (emSign Root TLS/CS CA - G3, Sectigo AAA Certificate Services, emSign ECC Root CA - G3). No root private key is reported compromised.
Browser-vendor confirmation. Firefox blocked the certificates via OneCRL within hours and shipped Firefox 158.0.1 / ESR builds (CVE-2026-113470). Mozilla states no public TLS server certificates were issued under the affected roots beyond internal test certificates.
Reporting with the consolidated timeline (UTC) and the vendor-response matrix: Chrome CRLSet, Firefox OneCRL, Apple, Microsoft, Go, NSS, certifi, webpki-roots.
Reporting on the Go response: Go 1.27.3 and 1.26.10 add a key-level block in crypto/x509 (CVE-2026-111943) that hashes the public key so it also catches the Sectigo cross-signs; Go does no revocation checking, so apps must be rebuilt.
Background on how Firefox centrally blocks intermediate certificates through a browser-maintained revocation list.
Background on modern revocation checking and why trust decisions differ between clients.
Explains Chromium's certificate-blocking mechanism, the control Chrome used to push the TLS-intermediate block.
The shared database of CA records that root programs use to coordinate trust and distrust actions.
Context for the 24-hour / 5-day revocation expectations that apply when a CA key is compromised.
Official Go security announcement channel, to verify the emergency release numbers and the crypto/x509 change.
Release that removes the affected trust from the Python certifi CA bundle.
Release that updates the Rust trust anchors following the incident.
Electron releases that pick up the updated trust store for desktop applications.
No sources match the current filter.
Request a demo
A session with a solutions engineer, scoped to your environment and regulatory obligations.