Diagram of a certificate trust chain: trusted roots at the top, a row of eight intermediate CA keys marked compromised in red, and below them the browsers, runtimes and containers that must stop trusting them, some marked fixed in green and others pending in amber.
Threat-intelligence dossier · PKI and digital trust Research cutoff 20 Oct 2026, 23:59 IST TLP:CLEAR
Investigative dossier · The eMudhra intermediate CA key compromise

Eight private keys. One question: who still trusts them?

On 17 October 2026, browser root programs received cryptographic proof that someone outside eMudhra held the private keys of eight of its intermediate certificate authorities. Within three hours of receiving the report, both Chrome and Firefox had blocked them. This dossier checks every material claim against primary evidence, separates what an attacker could do from what has been shown, and tells enterprises where trust may still be leaking.

01 · REPORTED COMPROMISE
8 keys, 16 certificates
6 TLS, 2 code signing, each also cross-signed by Sectigo
02 · VERIFIED MITIGATION
Blocked in 1h40m
Chrome CRLSet, 17 Oct 19:45 UTC
03 · STILL UNKNOWN
How the keys left
No root cause or CA statement at cutoff
Briefing A · The 30-second version for a CISO

Incident intelligence briefing

INCIDENT eMudhra intermediate CA private-key compromise Intermediate CAs under emSign roots, operated by eMudhra BV (NL) and eMudhra Inc (US). Parent root operator: eMudhra Technologies Limited (IN). E-001, E-006
SCALE 8 keys 8 unique public keys across 16 certificate objects: 6 TLS intermediates (DV, OV, EV) and 2 code-signing intermediates. E-003, E-004
KEY DATES (UTC) 17 Oct reported; Chrome and Firefox block
18–19 Oct all 16 certificates revoked
19–20 Oct Apple, Go, Microsoft, NSS
20 Oct public disclosure E-008–E-015
EXPLOITATION None publicly evidenced Chrome found no TLS certificate under the six TLS intermediates in CT before its block. Code signing is not covered by CT. E-021, E-024
Confirmed vendor actions
  • Chrome CRLSet blocks the 6 TLS SPKIs (E-009)
  • Firefox OneCRL block; Firefox 158.0.1 (E-011, E-012)
  • Go 1.27.3 / 1.26.10 reject chains through all 8 SPKIs (E-015)
  • NSS 3.131.1 and webpki-roots 1.0.10 drop emSign ECC Root CA - G3 (E-013, E-016)
  • CA revocation of all 16 certificates, reason cACompromise (E-008)
Evidence gaps
  • How, when and by whom the keys were taken (E-023)
  • Whether anyone besides the reporter holds them (E-023)
  • Any check for code-signing misuse (E-024)
  • First-party statements from Apple, Microsoft, eMudhra, Sectigo (E-014, E-023)
  • Node.js and Composer fixes still pending (E-019)
Assessment. Browsers acted fast and Chrome's CT data makes trusted fraudulent TLS certificates in Chrome very unlikely. The residual enterprise risk sits in clients that do not use browser blocklists: application CA bundles, runtimes, containers, Java, appliances and Windows code-signing trust.
Briefing G · Proportionality check

What we know, and what we do not

Each step below needs its own evidence. A compromised key does not mean a fraudulent certificate was issued; an issued certificate does not mean a victim was attacked.

PropositionStatusBasis
1 · Eight intermediate private keys compromisedEstablishedProof-of-possession signatures; Chrome "completed corroborating the findings"; CA revoked all 16 with reason cACompromise. (E-001, E-002, E-008, E-009)
2 · Fraudulent certificate issuedNot evidencedNo CT entries under the six TLS intermediates before Chrome's block. Code-signing issuance is not logged anywhere public. (E-021, E-024)
3 · Successful impersonationNot evidencedNo public report. Chrome states no fraudulent certificate from these CAs "could have been trusted by default" in Chrome. (E-021)
4 · Exploitation of real usersNot evidencedNo report of interception, signed malware or affected organisations found by the cutoff. (E-024)
5 · Data theftNot evidencedNo claim of data theft by anyone. (E-024)
6 · Original compromise mechanismUnknownNo statement from eMudhra or the root programs. Mozilla's tracking bug is access-restricted. (E-023)

Absence of evidence is not evidence of absence. "Not evidenced" means no public source shows it as of the cutoff.

Board C · Certificate inventory

The eight-key evidence board

"Eight" means eight private keys, which is also eight unique public keys (SPKI hashes). Each key appears in two certificate objects: one issued by an eMudhra root, and a cross-certificate issued by Sectigo's AAA Certificate Services. That makes 16 certificates to block, not 8. All keys are ECDSA P-384. Data from the researcher's published impacted-intermediates.json, which matches the 8 SPKI hashes hard-coded in Go's fix.

EM DV TLS CA - G3BTLS · DV
eMudhra BV · NL
SPKI ebed6475…5b5105
① emSign Root TLS CA - G3 · revoked 18 Oct 09:24 UTC② Sectigo AAA cross-sign · revoked 19 Oct 10:35 UTC
EM OV TLS CA - G3BTLS · OV
eMudhra BV · NL
SPKI 43bffa19…e2717b
① emSign Root TLS CA - G3 · revoked 18 Oct 09:37 UTC② Sectigo AAA cross-sign · revoked 19 Oct 10:35 UTC
EM EV TLS CA - G3BTLS · EV
eMudhra BV · NL
SPKI e0254c7f…5a8a41
① emSign Root TLS CA - G3 · revoked 18 Oct 09:28 UTC② Sectigo AAA cross-sign · revoked 19 Oct 10:35 UTC
EM DV TLS CA - G3CTLS · DV
eMudhra Inc · US
SPKI 49dd353d…34fe5f
① emSign Root TLS CA - G3 · revoked 18 Oct 09:27 UTC② Sectigo AAA cross-sign · revoked 19 Oct 10:35 UTC
EM OV TLS CA - G3CTLS · OV
eMudhra Inc · US
SPKI 63ecefee…6c109cf8
① emSign Root TLS CA - G3 · revoked 18 Oct 09:38 UTC② Sectigo AAA cross-sign · revoked 19 Oct 10:35 UTC
EM EV TLS CA - G3CTLS · EV
eMudhra Inc · US
SPKI 5c0660a2…1f81a0
① emSign Root TLS CA - G3 · revoked 18 Oct 09:30 UTC② Sectigo AAA cross-sign · revoked 19 Oct 10:35 UTC
EM OV CS CA - G3BCode signing
eMudhra BV · NL
SPKI ec4ffa1a…5eb4f6b6
① emSign Root CS CA - G3 · revoked 18 Oct 09:33 UTC② Sectigo AAA cross-sign · revoked 19 Oct 10:35 UTC
EM OV CS CA - G3CCode signing
eMudhra Inc · US
SPKI 92c063d6…25e0e30
① emSign Root CS CA - G3 · revoked 18 Oct 09:35 UTC② Sectigo AAA cross-sign · revoked 19 Oct 10:35 UTC
8
unique private / public keys (distinct SPKI SHA-256)
16
certificate objects: 8 eMudhra-issued + 8 Sectigo cross-signs
6 + 2
TLS (2 each DV, OV, EV) + code signing (OV)
2025
validity start of every certificate (30 Apr eMudhra, 14 May Sectigo). Valid until 2040 and 2028 respectively

Full fingerprints, serials, Subject and Authority Key Identifiers and CCADB record IDs for all 16 objects are in the technical appendix below. G3B entities are eMudhra BV (Netherlands); G3C entities are eMudhra Inc (United States). Times are the CRL revocation timestamps recorded in the published data. (E-003–E-008)

Diagram B · Inside the compromised trust chain

Three roots, two cross-sign paths, one weak link

A root CA signs an intermediate; the intermediate signs end-entity (leaf) certificates; clients accept a leaf if they can build a path to a root they trust and nothing on the path is revoked or distrusted. Whoever holds an intermediate's private key can mint leaves that this path vouches for. The roots' own keys are not reported compromised.

ROOT CAs · KEYS NOT REPORTED COMPROMISED emSign ECC Root CA - G3 In Apple, Chrome, Microsoft, Mozilla stores Removed by NSS 3.131.1 · webpki-roots 1.0.10 AAA Certificate Services (Sectigo) In Apple, Microsoft · removed from Chrome (Apr 2025), Mozilla RSA-2048 · expires 31 Dec 2028 emSign Root CS CA - G3 Code-signing root · in Microsoft store Not in Apple, Chrome, Mozilla emSign Root TLS CA - G3 In Microsoft store directly Elsewhere via cross-sign from ECC G3 (inferred) cross-sign (inference, E-007) 6 TLS intermediates · KEYS COMPROMISED EM DV / OV / EV TLS CA - G3B (eMudhra BV) and - G3C (eMudhra Inc) 12 certificate objects · 6 SPKIs · revoked 18–19 Oct 2 code-signing intermediates · KEYS COMPROMISED EM OV CS CA - G3B (eMudhra BV) and - G3C (eMudhra Inc) 4 certificate objects · 2 SPKIs · revoked 18–19 Oct Sectigo cross-certificates (same keys) Fraudulent TLS leaf (hypothetical) Any domain name · none found in CT (E-021) Rogue code-signing cert (hypothetical) Not publicly logged · none reported (E-024) MITIGATION CRLSet · OneCRL · Apple, Microsoft blocks · Go SPKI blocklist · CA revocation · root removal Client verification: accept only if path is trusted and not blocked
Documented issuance (certificate data) Hypothetical attack step Inferred relationship Verified mitigation
CALLOUT Compromised intermediate key ≠ compromised root key. Intermediates can be revoked and blocked individually, and the roots can be removed. A root-key compromise would have no such narrow fix. Mozilla and the Rust and PHP bundles still removed emSign ECC Root CA - G3 to cut every path at once.
Why the Sectigo cross-signs matter The same eight keys were also certified by Sectigo's AAA Certificate Services root, which Apple and Microsoft still trusted. A client that distrusts only the eMudhra-issued certificate objects, but not the cross-signs, could still build a path. Blocking by public key (SPKI), as Chrome and Go did, covers both. (E-007, E-009, E-015)

Root-store status comes from the researcher's roots.json, compiled from CCADB data. The cross-sign from emSign ECC Root CA - G3 to emSign Root TLS CA - G3 is our inference: roots.json lists ECC G3 with the role "cross_signer", and eMudhra told Mozilla its purpose-based TLS roots are cross-signed by the G1/G3 roots. We did not see the cross-certificate itself. Name Constraints, Key Usage and EKU fields were not independently parsed.

Forensics · Proof of private-key possession

"We have a problem here - Wayne"

The reporter, identified only as "Wayne", signed that message with each of the eight private keys. The signatures went to the root programs on 17 October, and the disclosure site publishes them in proof.zip, with each certificate and public key, and OpenSSL commands to check them.

The logic is simple. A certificate binds a public key to a CA name. An ECDSA P-384 signature over a chosen message that verifies against that public key can only have been produced with the matching private key. So a valid signature on a fresh, attacker-chosen message proves present-day possession of the key, which no outsider should have.

# 1 · the certificate's public key equals the supplied key openssl x509 -in EM-DV-TLS-CA-G3B.crt.pem -noout -pubkey \ | diff - EM-DV-TLS-CA-G3B.pub.pem # 2 · the signature over message.txt verifies (SHA-384) openssl dgst -sha384 -verify EM-DV-TLS-CA-G3B.pub.pem \ -signature EM-DV-TLS-CA-G3B.sig message.txt

Commands as published by the disclosure site. We did not reproduce them: our research environment could not download proof.zip. The Chrome Root Program states it "completed corroborating the findings" before blocking, and the CA revoked all 16 certificates as cACompromise. (E-002, E-008, E-009)

What a valid signature establishes
  • The signer held each of the eight private keys when signing
  • The keys match the published certificates exactly
  • Every certificate sharing those keys (including Sectigo cross-signs) is equally exposed
What it cannot establish
  • When the keys were first taken
  • How: an HSM failure, key-ceremony error, insider, backup or software flaw
  • Who else holds copies
  • Whether the keys were ever used to issue certificates
A pattern worth noting All eight eMudhra-issued intermediate certificates start their validity on 30 April 2025 within about an hour (15:35–16:38 UTC), and all eight keys leaked together. That points to a shared cause in how the CA generated, stored or backed up keys, rather than eight separate failures. This is our inference; nothing published confirms it. (E-005, E-023)
Timeline D · 17 to 20 October 2026, UTC

From report to remediation in four days

Lanes separate the kinds of milestone, so that a patch being released is not confused with it reaching users. Where only a date is published, no time is shown.

Sat 17 OctSun 18 OctMon 19 OctTue 20 Oct REPORT RECEIVEDBLOCK / DISTRUSTCA REVOCATIONPATCH RELEASEDPUBLIC DISCLOSUREDEPLOYED TO USERS 18:05 Chrome 20:06 Mozilla 19:45 CRLSet 22:59 OneCRL Apple* Microsoft* 09:24–09:38 · 8 eMudhra-issued 10:35 · 8 Sectigo cross-signs Go 1.27.3 webpki 1.0.10 NSS 3.131.1 Firefox 158.0.1 certifi 10.19 Electron* Disclosure site + Mozilla DSP post Browsers auto-update blocklists → apps, runtimes, containers, appliances depend on each owner redeploying (ongoing)
* Reported by the disclosure site only; no first-party statement found. Electron versions are listed as patched by the disclosure site, but their release notes do not describe the change. Go's release date is 19 Oct per go.dev; some reports say 20 Oct. Sources: E-008–E-020.
When (UTC)TypeEventOrganisationEvidence
17 Oct 18:05ReportChrome Root Program receives the reportGoogleE-009
17 Oct 19:45BlockCRLSet blocks SPKIs of the 6 TLS intermediates; the 2 code-signing CAs not needed for ChromeGoogleE-009, E-010
17 Oct 20:06ReportMozilla receives the reportMozillaE-011
17 Oct 22:59BlockFirefox blocks the certificates via OneCRL (no restart needed)MozillaE-011
18 Oct 09:24–09:38RevocationAll 8 eMudhra-issued intermediates revoked, reason cACompromiseeMudhraE-008
19 Oct 10:35RevocationAll 8 Sectigo cross-certificates revoked, reason cACompromiseSectigoE-008
19 OctBlock*Apple devices begin blockingAppleE-014
19 OctPatchGo 1.27.3 and 1.26.10 (CVE-2026-111943); webpki-roots 1.0.10Go · rustlsE-015, E-016
20 OctBlock*Microsoft begins blockingMicrosoftE-014
20 OctPatchNSS 3.131.1; Firefox 158.0.1 (MFSA2026-111, CVE-2026-113470); certifi 2026.10.19Mozilla · certifiE-012, E-013, E-017
20 OctDisclosurePublic disclosure site; Mozilla and Chrome posts to dev-security-policyResearcher · Mozilla · GoogleE-001, E-021
Analysis H · Capability versus evidence

Two hypothetical attack paths, set against what actually happened

Dashed steps are what an attacker holding the keys could attempt. Solid steps are documented. No documented step links to a victim.

Path A · TLS impersonationHypothetical
  1. 1Mint a leaf for a target domain (for example a bank's login host) with a TLS intermediate key.
  2. 2Get on the path: DNS hijack, BGP hijack, rogue Wi-Fi, compromised proxy or router. The key alone does not redirect traffic.
  3. 3Pass the client's checks: the client must trust a root on the path, must not have the block, and, in CT-enforcing browsers such as Chrome and Safari, must see valid CT proofs, which would publish the fake certificate.
  4. 4Impact: read or alter traffic, steal credentials or API tokens.
Mitigation: CRLSet, OneCRL, Apple and Microsoft blocks, Go SPKI blocklist, root removals, CA revocation. Most exposed: clients that check none of these, such as apps with an old CA bundle that skip revocation checks, and some appliances. Confidence that it happened: no evidence; Chrome's CT check found nothing (E-021).
Path B · Code-signing abuseHypothetical
  1. 1Issue a code-signing certificate in any publisher name from a CS intermediate key. No public log records it.
  2. 2Sign a payload: malware, a tampered installer or a driver package.
  3. 3Deliver and get it run: phishing, a compromised update channel. A signature only helps once the file reaches a machine whose platform trusts the chain. The issuing root, emSign Root CS CA - G3, is listed only in Microsoft's store.
  4. 4Impact: fewer security warnings, more trust from allow-listing tools that key on "signed by a trusted CA".
Mitigation: revocation of both CS intermediates; Microsoft's reported block (20 Oct); Go's blocklist includes both CS SPKIs. Browsers do not use CS CAs for TLS (E-010). Open issue: how each platform treats signatures timestamped before the revocation. This depends on platform policy and was not confirmed by any vendor. Confidence that it happened: unknown; code-signing issuance is not publicly logged, and no misuse has been reported (E-024).
SIX PROPOSITIONS, SIX EVIDENCE BARS · SOLID = DOCUMENTED · DASHED = NOT EVIDENCED
1 · DOCUMENTEDKey compromised
2 · DOCUMENTEDKey could issue certificates
3 · NOT EVIDENCEDFraudulent certificate issued
4 · NOT EVIDENCEDAccepted by a client
5 · NOT EVIDENCEDUsed against a victim
6 · NOT EVIDENCEDMeasurable harm
Certificate Transparency · Reading the "no fraudulent certificates" claim

Strong evidence, with a precise scope

The only first-party CT statement is Chrome's: "no TLS certificates chaining to these six intermediate CAs were logged to CT prior to our CRLSet block on October 17", so "no fraudulent certificates issued by these CAs could have been trusted by default" in Chrome. Chrome refuses publicly trusted certificates without CT proofs, so an unlogged fake would fail in Chrome anyway.

Chrome also says it is working with CT log operators to reject certificates chaining to these intermediates, which closes the route of logging a fake now and using it against a client that has CT checks but no block.

One news report attributes a broader "no public TLS server certificates" statement to Mozilla. We could not find it in Mozilla's posts; it appears to conflate eMudhra's own statement about two other roots in Mozilla Bug 2083709. We treat it as unverified. (E-021, E-027)

CoveredPublicly logged TLS certificates under the six TLS intermediates, up to the Chrome block (17 Oct 19:45 UTC), and Chrome's default CT-enforcing behaviour.
Not coveredUnlogged certificates shown to clients that do not require CT proofs: most applications, language runtimes, IoT devices and appliances.
Not coveredAnything issued by the two code-signing intermediates. Code signing has no public transparency log.
UnknownWhich specific CT logs and time windows were searched. Chrome's post does not list them.
Diagrams E and K · Browser trust versus application trust

Why an updated browser is not the end of it

Revocation is a statement by the CA. Whether a client acts on it depends on the client. Browsers fixed themselves through push updates. Everything else trusts certificates through its own layer, and each layer has its own fix and its own way to check it.

LAYERMITIGATION MECHANISMHOW TO VERIFYSTATUS
BrowsersCRLSet (Chrome, Edge and other Chromium), OneCRL (Firefox), Apple and Microsoft remote blocksBrowser on current version, remote updates not disabled by policyVerified (Chrome, Firefox)
Operating-system trust storesApple and Microsoft distrust (reported); Linux distribution ca-certificates updates not yet seenOS updates applied; for Linux, check the bundle no longer chains the intermediatesPartly reported
Runtime verificationGo: built-in SPKI blocklist in crypto/x509, covering system-verifier paths on macOS and Windows; Node.js blocklist pendingRebuild binaries with Go ≥ 1.27.3 / 1.26.10; check go version -mGo verified
Bundled CA filescertifi, webpki-roots, Composer, Homebrew remove the emSign G3 roots (and Homebrew also AAA)Lock files and SBOMs show fixed versions; grep the bundle for the root's fingerprintMixed
Containers and minimal imagesOnly as fresh as the base image's ca-certificates and the language bundle at build timeRebuild and redeploy; scan running images, not just registriesOwner action
Proxies, gateways, TLS inspectionVendor trust store or admin-managed CA list; often no CRL or OCSPVendor advisory; test with a chain built on an affected intermediateUnknown
Java, embedded, legacyJDK cacerts, firmware stores; no response found by the cutoffInventory, then remove the roots or add the intermediates to a deny listUnknown
REVOCATION GAP · ARCHITECTURAL EXPLANATION, NOT A TEST RESULT Compromised intermediate revoked: cACompromise Browser + blocklistCRLSet / OneCRL OS, updated storeApple, Microsoft App, old CA bundleno revocation check No revocation datamany IoT, appliances Custom verifierpinning, own code Rejects Rejects* May accept May accept Depends

* Apple and Microsoft distrust is reported by the disclosure site; we found no first-party statement. "May accept" assumes the client still trusts a root on the path and does not enforce CT. Not every application in a category is affected.

Matrix F · For engineering teams

The software remediation matrix

Fixed versions are taken from official releases or commits. Where a fix is only listed by the disclosure site, or the release notes do not describe it, we say so. Projects took different approaches: some block the eight keys, some remove one or more emSign roots.

Verified official record shows the change Reported listed as fixed, not independently confirmed Pending fix proposed, not released Unknown no response found by the cutoff
ComponentChange (official record)Fixed versionActionStatus
Chrome / ChromiumCRLSet blocks the 6 TLS SPKIs, covering Sectigo cross-signs (Chrome Root Program). Root Store v43 to remove the eMudhra root.CRLSet, 17 OctAllow component updates; check enterprise policies do not freeze themVerified
FirefoxOneCRL block; release ships the list for users with remote settings disabled (MFSA2026-111, CVE-2026-113470)158.0.1 · ESR 153.5.1 · ESR 115.43.1Update managed fleets, especially where remote settings are disabledVerified
NSSRemoves emSign ECC Root CA - G3 (and, at eMudhra's request, emSign Root CA - C1 and ECC Root CA - C3) (NSS announcement)3.131.1Update NSS-based clients and distro packages; expect some emSign-issued sites to failVerified
Gocrypto/x509 rejects chains containing any of the 8 SPKIs, including on macOS and Windows verifier paths. CVE-2026-111943 (announcement, commit)1.27.3 · 1.26.10Rebuild and redeploy every Go binary; older toolchains get no fixVerified
Rust webpki-roots / webpki-root-certsRemoves emSign ECC Root CA - G3 from the bundle (PR #133)1.0.10cargo update, rebuildVerified
Homebrew ca-certificatesExcludes three roots by SPKI: emSign ECC Root CA - G3, emSign Root TLS CA - G3 and Sectigo AAA Certificate Services (formula)2026-09-25_1brew upgrade ca-certificatesVerified
Python certifi2026.10.18 removed emSign CAs; 2026.10.19 restored unaffected emSign roots after breakage reports. Release notes do not list the net change (release)2026.10.19pip install -U certifi; rebuild images and wheelsReported
ElectronListed as patched by the disclosure site; the release notes do not mention the change (v44.9.1)44.9.1 · 43.8.1 · 42.11.16Ship app updates on these versions; confirm with the Electron teamReported
Apple · MicrosoftBlocking on 19 and 20 Oct, per the disclosure site onlyNot publishedKeep platform updates current; watch for vendor advisoriesReported
Node.jsDraft PR adds a compiled-in SPKI blocklist with the 8 keys; needs backports (PR #66871)—Interim: pass an explicit CA list without the affected roots through the TLS ca optionPending
Composer ca-bundle (PHP)PR removes emSign ECC Root CA - G3 from the bundled cacert.pem (PR #154)—Watch for the release; prefer the system store meanwhilePending
Java · Debian/Ubuntu/RHEL · AndroidNo response found by the cutoff—Remove the roots or deny-list the 16 certificates locally until vendors shipUnknown

Side-effect warning from Mozilla: removing the root "will impact the availability of some servers" for non-Firefox NSS users. Servers using legitimate certificates from these emSign hierarchies need new certificates. (E-013, E-015–E-020)

Heatmap I · Where to look first

Enterprise investigation priorities

Method. Priority combines three qualitative judgements: how likely the area is to still trust the keys (mitigation coverage), how bad a successful abuse would be (impact), and how hard the prerequisites are. These are not probabilities. Re-rate them against your own estate.

AreaMitigation coverageImpact if abusedAttacker prerequisitesPriority
Browser trustHigh: pushed blocksHighHard: CT + network positionLow
App CA bundlesLow until rebuiltHigh: tokens, dataNetwork positionHigh
APIs and outbound servicesDepends on runtimeHigh: payments, partnersEgress pathHigh
Software signing (Windows)Reported block, unconfirmedHigh: malware trustDelivery neededMedium
ContainersLow until rebuiltMedium–HighNetwork positionHigh
Legacy and embeddedOften noneVariesNetwork positionMedium
TLS inspectionVendor-dependentHigh: re-signs for usersUpstream positionHigh
Build and release pipelinesDepends on runnersHigh: supply chainNetwork positionMedium

Why TLS inspection rates high: an inspection proxy validates the upstream certificate on the user's behalf and then re-signs it with its own trusted CA. If the proxy still trusts these intermediates, the browser's own block never sees the original chain.

Playbook J · Seven stages to close the incident

The enterprise remediation playbook

  1. 01 · DISCOVERFind what trusts the chainsInventory runtimes, CA bundles, base images, appliances and Windows signing trust. Owner: platform + security engineering. Evidence: SBOM and asset list with trust source per system.
  2. 02 · IDENTIFYMap certificates and pathsSearch stores and bundles for the 3 roots and 16 certificates by SPKI and fingerprint; list your own emSign-issued certificates. Owner: PKI team. Evidence: match report.
  3. 03 · VERIFY FIXESUse only confirmed vendor fixesCheck each component against the matrix above and the vendor's own release record. Owner: application owners. Evidence: version pins with release links.
  4. 04 · UPGRADERebuild and redeployGo binaries, containers, Python and Rust apps, desktop apps; deny-list locally where no fix exists. Owner: DevOps. Evidence: deployment records for running workloads.
  5. 05 · VALIDATEProve the chains are rejectedTest each client class against a lab chain that uses an affected intermediate certificate. Owner: security testing. Evidence: rejection logs per client class.
  6. 06 · INVESTIGATELook back for abuseSearch TLS and proxy logs for chains with these issuers; hunt for binaries signed under the CS intermediates. Owner: SOC. Evidence: hunt queries, results, time range.
  7. 07 · DOCUMENTRecord residual riskList systems that cannot be fixed, compensating controls and owners. Brief the risk committee. Owner: CISO office. Evidence: signed-off risk register entry.
QUICK CHECK · DOES A PEM BUNDLE CONTAIN AN AFFECTED ROOT? (SPKI SHA-256)
# split the bundle, then print each certificate's SPKI SHA-256 awk '/BEGIN CERT/{n++} {print > ("cert" n ".pem")}' bundle.pem for f in cert*.pem; do openssl x509 -in "$f" -noout -pubkey | openssl pkey -pubin -outform DER \ | openssl dgst -sha256 | awk -v f="$f" '{print $2, f}' done | grep -Ei '8d417db2dd8bf5e3|c619e4780ed8e0ab|bd153ed7b0434f68'
Prefixes: emSign ECC Root CA - G3 (8d417db2…), emSign Root TLS CA - G3 (c619e478…), Sectigo AAA Certificate Services (bd153ed7…). Removing AAA also affects other Sectigo chains that rely on it; test before removing it.
Map L · The digital trust dependency chain

One CA's keys, seven layers of dependants

Trust flows left to right. Fixes have to travel the same way, and every arrow is a place where a fix can stall. The map explains how the exposure can spread; it does not mean every dependant service was affected.

CA operatorseMudhra · Sectigo Root programsApple · Chrome · MS · Mozilla Operating systemssystem trust stores Runtimes, librariesGo · NSS · certifi · webpki ApplicationsElectron · CLIs · agents Enterprise servicesAPIs · proxies · CI End userscustomers · staff Ttrust decision Rrevocation (CRL) Bpushed blocklists Usoftware update U Dredeploy by owner T T Each further hop to the right adds delay before a fix reaches the end user, and needs its own owner to act.
Control assessment · Lessons as measurable objectives

Ten controls this incident tests

The incident does not show that any particular organisation failed these controls. It shows why each one matters when a trusted CA fails.

#Control domainLesson from this incidentMeasurable objective
01Certificate inventory and lifecycleOrganisations holding emSign-issued certificates must replace them where roots are being removed.100% of external certificates mapped to issuing CA and chain; replacement plan for any CA within 30 days.
02Trust-store update governanceFixes arrived as root removals in some bundles and key blocklists in others; owners need to know which their systems use.Every runtime and appliance has a named trust source and an update owner; critical trust updates applied within 72 hours.
03Dependency and runtime inventoryGo binaries need rebuilding; a library update alone does not fix them.Running workloads mapped to toolchain and CA-bundle versions; rebuild completed within 7 days of a trust advisory.
04Software bill of materials (SBOM)CA bundles such as certifi and webpki-roots are dependencies too.SBOMs include CA-bundle packages and versions; queries answer “who ships certifi older than 2026.10.19” in minutes.
05Code-signing key managementTwo code-signing CA keys leaked alongside TLS keys; signing trust needs its own monitoring.Allow-listing based on specific publisher certificates, not “any trusted CA”; review of CA-based rules within 30 days.
06Certificate Transparency monitoringCT gave the strongest evidence that no TLS fakes were trusted.Monitor CT for every owned domain, alerting on certificates from unexpected issuers within 1 hour.
07Incident disclosure and responseRoot programs moved in hours; downstream fixes took days and are still incomplete.PKI incidents in the IR playbook, with a tested 24-hour discovery and mitigation runbook.
08Legacy-client managementClients that ignore revocation keep trusting revoked CAs.Every legacy or embedded client listed with its revocation behaviour and an override or retirement path.
09Production deployment verificationA patch available is not a patch deployed.Post-deployment test proves affected chains are rejected for each client class.
10Residual-risk documentationSome systems will lag (pending Node.js and Composer fixes, appliances).Residual-risk register entries with owner, compensating control and review date for every unfixed system.
Claim verification matrix

Six headline claims, checked one by one

The right-hand column is the wording we consider safe to publish.

Claim · originator · typeOutcomeIndependent supportSafe published wording
Eight intermediate CA private keys were compromised
Disclosure site; Chrome · Primary Unchanged Yes: Chrome corroborated; CA revoked all as cACompromise “Eight eMudhra intermediate CA private keys were compromised, as corroborated by the Chrome Root Program.”
Six concern TLS, two code signing
Disclosure data; Chrome · Primary Narrowed: 16 certificate objects, not 8 Yes: certificate usage fields and Chrome's post agree “Eight keys: six TLS intermediates (DV, OV, EV) and two code-signing intermediates, each in two certificates.”
The intermediates chain to the specified roots
roots.json, impacted-intermediates.json · Primary data Qualified Partly: issuers confirmed; ECC G3 cross-sign inferred “They were issued by emSign Root TLS CA - G3, emSign Root CS CA - G3 and Sectigo AAA; browser trust likely ran via an emSign ECC Root CA - G3 cross-sign.”
Browser and OS vendors implemented distrust
Disclosure site; Chrome; Mozilla · Mixed Narrowed Chrome and Mozilla confirmed; Apple and Microsoft only reported “Chrome and Firefox are confirmed blocked; Apple and Microsoft blocking is reported but not confirmed by those vendors.”
Emergency software releases address the incident
Disclosure site; vendors · Mixed Narrowed Go, NSS, webpki-roots, Firefox, Homebrew confirmed; certifi partly; Electron not documented “Go, NSS, Firefox, webpki-roots and Homebrew have confirmed fixes; Node.js and Composer are pending.”
CT found no fraudulent public TLS certificates
Chrome; one news report attributes it to Mozilla · Primary (Chrome) Scope-limited Yes, for Chrome's stated scope “Chrome found no TLS certificates under the six TLS intermediates logged to CT before its 17 Oct block.”
The India lens

An Indian CA, a global trust chain, and Indian obligations

The parent roots belong to eMudhra Technologies Limited (C=IN), listed on Indian exchanges. The compromised intermediates were operated through its Dutch and US entities. For Indian organisations, three practical questions follow.

01 · YOUR OWN CERTIFICATESSites issued from emSign hierarchiesMozilla's NSS update removes emSign ECC Root CA - G3 and two other emSign roots, and Chrome's next root store removes the upstream eMudhra root. Certificates from those hierarchies, even legitimate ones, may stop working for some users. Check your issuers now.
02 · REPORTING CLOCKSIf you find abuse, the 6-hour rule appliesThe incident itself is not, on current evidence, a reportable compromise for most organisations. But if your hunt finds a certificate from these CAs used against your systems, CERT-In's 6-hour incident reporting applies, and so do sector rules such as RBI's DAKSH reporting and SEBI's 6-hour email and 24-hour portal reporting.
03 · VENDOR ASSURANCEAsk vendors what their products trustRBI expects vendors to certify their software is free of known vulnerabilities, and SEBI's CSCRF requires SBOMs for critical systems. Both are a natural route to ask COTS and SaaS vendors whether their products bundle the affected roots, and when they will ship fixes.

eMudhra's only exchange filing found up to the cutoff (NSE, 19 Oct 2026) is an earnings-call notice that does not mention the incident. Whether further disclosure is required is a question for eMudhra and its regulators; we make no claim either way. (E-026)

Executive intelligence brief

For the board and the security leadership team

What happened. Someone obtained the private keys of eight intermediate certificate authorities run by eMudhra's Dutch and US entities. Six can issue website (TLS) certificates and two can issue code-signing certificates. A researcher proved possession to browser makers on 17 October 2026.

Why it matters. Whoever holds such keys can mint certificates that software trusts. Website certificates could be used to impersonate services; code-signing certificates could make malware look legitimate.

What is confirmed. The compromise; all 16 related certificates revoked; Chrome and Firefox blocking within hours; fixes in Go, NSS, Rust's root bundle, Firefox and Homebrew; and Chrome's finding that no TLS certificates from these CAs were in CT before its block.

What remains uncertain. How the keys were taken and who else holds them; whether the code-signing keys were used; Apple's and Microsoft's actions beyond the researcher's report; when Node.js, PHP, Java and Linux distributions will ship fixes.

Who should investigate. Platform and DevOps teams (runtimes, containers), the PKI owner (certificates and trust stores), network security (proxies, TLS inspection), endpoint security (code-signing trust) and the SOC (log review).

Immediate actions. Rebuild Go services, update CA bundles and redeploy containers; confirm proxies and appliances distrust the chains; replace any certificates you hold from affected emSign hierarchies; hunt for binaries signed under the two code-signing CAs.

Long-term lesson. Trust lives in many places, not just the browser. Treat CA bundles as software dependencies, know which trust store every system uses, and be able to prove a distrust change reached production.

Technical appendix · Affected-certificate inventory

All 16 certificate objects

Transcribed from the researcher's impacted-intermediates.json; CCADB record IDs are from the Common CA Database. The 8 SPKI hashes match those in Go's fix. Each pair of rows is one key. eMudhra-issued certificates are signed with ecdsa-with-SHA384, Sectigo cross-signs with sha256WithRSAEncryption. Verify against the source files before using them in production blocklists.

IntermediateIssuer · CCADBPublic keyCertificateValidity · revocation
EM DV TLS CA - G3B
eMudhra BV, NL · TLS DV emSign Root TLS CA - G3
CCADB A012302 SPKI ebed6475c2c2d80fcb199f3fe8dd6e6b3ce60b77eb15d4e42c3dec0c6f5b5105
SKI e21e2fe71c19390e554b62c120245735248a2514 SHA-256 42c4accd12c4f59597925e1a08a7a90102608543809308d50ec427e118ba1493
Serial a4aee678f23362b4c0e460b772f214 2025-04-30 → 2040-04-28
Revoked 18 Oct 09:24:32 UTC
↳ same key Sectigo AAA Certificate Services
CCADB A012347 SPKI ebed6475c2c2d80fcb199f3fe8dd6e6b3ce60b77eb15d4e42c3dec0c6f5b5105
SKI e21e2fe71c19390e554b62c120245735248a2514 SHA-256 45a883f349aedfd5f3a649b5498ffb121712ba8b448f3f2a91dbc5a766fcddbe
Serial a024fdf4ba665c785ce4a020483858b7 2025-05-14 → 2028-12-31
Revoked 19 Oct 10:35:36 UTC
EM OV TLS CA - G3B
eMudhra BV, NL · TLS OV emSign Root TLS CA - G3
CCADB A012308 SPKI 43bffa19d6ef651451f6841e019931e96f6f2eaeff28ab4b6f1ce4576de2717b
SKI 9bd86551afe7e72c37ad08ee6919d9bf3784ae0a SHA-256 98b896625c0c230adeec3eb2cf6aad5001ecf9156a68644e82374ce5833bc25b
Serial 6cada367fb1c100088120ea202d568 2025-04-30 → 2040-04-28
Revoked 18 Oct 09:37:19 UTC
↳ same key Sectigo AAA Certificate Services
CCADB A012354 SPKI 43bffa19d6ef651451f6841e019931e96f6f2eaeff28ab4b6f1ce4576de2717b
SKI 9bd86551afe7e72c37ad08ee6919d9bf3784ae0a SHA-256 5f1ded4dd590af74631290cf073b122a2aac6a1fa479778a0bd43579bd832699
Serial e94223bde92f914e5ab9acabfdac3710 2025-05-14 → 2028-12-31
Revoked 19 Oct 10:35:36 UTC
EM EV TLS CA - G3B
eMudhra BV, NL · TLS EV emSign Root TLS CA - G3
CCADB A012304 SPKI e0254c7fcdc265e2f0f8a428dabb75ab4ae039b4872d62f5ee57f0877d5a8a41
SKI 3edc20d9894698877b873fd88147b25c15d84706 SHA-256 e7568fe6e12331f4fd7de61da4c7559d0f8eb192a218d4741a3ba75184333838
Serial c7c41efe92d825f05eae841a4a82c1 2025-04-30 → 2040-04-28
Revoked 18 Oct 09:28:53 UTC
↳ same key Sectigo AAA Certificate Services
CCADB A012333 SPKI e0254c7fcdc265e2f0f8a428dabb75ab4ae039b4872d62f5ee57f0877d5a8a41
SKI 3edc20d9894698877b873fd88147b25c15d84706 SHA-256 579480aea166290bd3c643589e795fc0d0e54e86505d180f1dff99efd3199512
Serial d8f8685e4f2bd9d82402a85a1c1eb731 2025-05-14 → 2028-12-31
Revoked 19 Oct 10:35:36 UTC
EM DV TLS CA - G3C
eMudhra Inc, US · TLS DV emSign Root TLS CA - G3
CCADB A012294 SPKI 49dd353dc2b919a3770645117d0e60c16115e7d1bc259eefe734b00ea434fe5f
SKI ae7e105c3c2996c1a847270559f1e03dd4e50af3 SHA-256 0164d7ceae5bb909c272af151ff44b1177ae9b47d9424b94f1d9558c30934d19
Serial 588b2e3c2bb8cda13e1a1209254321 2025-04-30 → 2040-04-28
Revoked 18 Oct 09:27:07 UTC
↳ same key Sectigo AAA Certificate Services
CCADB A012342 SPKI 49dd353dc2b919a3770645117d0e60c16115e7d1bc259eefe734b00ea434fe5f
SKI ae7e105c3c2996c1a847270559f1e03dd4e50af3 SHA-256 62b7f9868263f72f6911fc78ceaf72c1979158b7368bf648683bb2aa39b02e72
Serial 91f347f1a5b7d39962b95e0ee4e299d1 2025-05-14 → 2028-12-31
Revoked 19 Oct 10:35:36 UTC
EM OV TLS CA - G3C
eMudhra Inc, US · TLS OV emSign Root TLS CA - G3
CCADB A012300 SPKI 63ecefee431d49523bc1136c4e72d0206a477086caf606cd5cf025686c109cf8
SKI 34eaea0cebc90adaf9d0c5e2ed9b78c9879e1b6c SHA-256 cb6e15165ac802e9b3f993f16c25d41f4e81c21ebde71ae1b012ac00bf9c7c3f
Serial 296926c227a3a1526392b19482a504 2025-04-30 → 2040-04-28
Revoked 18 Oct 09:38:46 UTC
↳ same key Sectigo AAA Certificate Services
CCADB A012343 SPKI 63ecefee431d49523bc1136c4e72d0206a477086caf606cd5cf025686c109cf8
SKI 34eaea0cebc90adaf9d0c5e2ed9b78c9879e1b6c SHA-256 7485b51c0ed192878fa1d2f948fb529ae1842cc5086c4b67f7be5b2039de9489
Serial 8d5a4811939ef447d77111cdd9849ae9 2025-05-14 → 2028-12-31
Revoked 19 Oct 10:35:36 UTC
EM EV TLS CA - G3C
eMudhra Inc, US · TLS EV emSign Root TLS CA - G3
CCADB A012296 SPKI 5c0660a2b164910d8ff589c18e14552e9e0ec237dcefe2cb736d41a4811f81a0
SKI a6255e80a94db7f3967c1bc791df92bcee4beb5f SHA-256 432ec25f0d28de9006d97bf752f17bbb2cd41f669933fcb072d9a1148d0261f3
Serial 8009928a64107601af05fa2f19f109 2025-04-30 → 2040-04-28
Revoked 18 Oct 09:30:49 UTC
↳ same key Sectigo AAA Certificate Services
CCADB A012334 SPKI 5c0660a2b164910d8ff589c18e14552e9e0ec237dcefe2cb736d41a4811f81a0
SKI a6255e80a94db7f3967c1bc791df92bcee4beb5f SHA-256 fd9d5c2dbbd4995ab69b8d50c439d9527b00529199c2fd01b2174eb58f07021f
Serial 05f078752dece7a1bb8595d303167171 2025-05-14 → 2028-12-31
Revoked 19 Oct 10:35:36 UTC
EM OV CS CA - G3B
eMudhra BV, NL · Code signing emSign Root CS CA - G3
CCADB A012306 SPKI ec4ffa1ad0ac88081314b7aaffef6a91f97cd57291bb5ba686c5415f5eb4f6b6
SKI 79fae8eccfdb0d758da458d69fb6eddc7c49dee6 SHA-256 9e39de2881273acc225a149c72ba3e0f51424963669ab633ee1dc7df5db067b4
Serial 7818933f8f85b4619a2b35fba83d0a 2025-04-30 → 2040-04-28
Revoked 18 Oct 09:33:37 UTC
↳ same key Sectigo AAA Certificate Services
CCADB A012352 SPKI ec4ffa1ad0ac88081314b7aaffef6a91f97cd57291bb5ba686c5415f5eb4f6b6
SKI 79fae8eccfdb0d758da458d69fb6eddc7c49dee6 SHA-256 a496e23ac0cab8155fc9b117b97eae368efcbb9041aec8804d5a308d2d01c2d8
Serial 41e32b73ac185d6ce0d7480bacf84e69 2025-05-14 → 2028-12-31
Revoked 19 Oct 10:35:36 UTC
EM OV CS CA - G3C
eMudhra Inc, US · Code signing emSign Root CS CA - G3
CCADB A012298 SPKI 92c063d67e8f14db71d288e11266ffdaf69cbf115f7bab14f3bc2f68d25e0e30
SKI ee6f73298d6fbfa7b31bc39534f61556447866b7 SHA-256 4b2460a466f95fd40113bcdcca2ceb29b3b093921de45474da7df48874c630b1
Serial 544b7f922c31ae220a4a922916f6e6 2025-04-30 → 2040-04-28
Revoked 18 Oct 09:35:24 UTC
↳ same key Sectigo AAA Certificate Services
CCADB A012350 SPKI 92c063d67e8f14db71d288e11266ffdaf69cbf115f7bab14f3bc2f68d25e0e30
SKI ee6f73298d6fbfa7b31bc39534f61556447866b7 SHA-256 84112972b8e59d14560ae7e7119654474aad119990cf3722bfc1e3b91615e1fd
Serial d6a5ef613b390f32ef9cdf349f772841 2025-05-14 → 2028-12-31
Revoked 19 Oct 10:35:36 UTC
emSign Root TLS CA - G3
SHA-256 7dd78d5f4f13459a83dff9abbba62edbaf6f2d102bf257fd712f4d9f2746ed8d
SPKI c619e4780ed8e0abeda24ad732567de4383a7ea941338f6d1a7d1b49ac792fe9
emSign Root CS CA - G3
SHA-256 f2edaaff3d9b701fb4d14c9f285f8c0bad90fc3bcc1fa07d47f4718edaba34a5
SPKI 0a6c2b2ca5b364207954171987ac9d2178561569d8205457e77ca90c32ede282
AAA Certificate Services (Sectigo)
SHA-256 d7a7a0fb5d7e2731d771e9484ebcdef71d5f0c3e0a2948782bc83ee0ea699ef4
SPKI bd153ed7b0434f6886b17bce8bbe84ed340c7132d702a8f4fa318f756ecbd6f3
emSign ECC Root CA - G3
SHA-256 86a1ecba089c4a8d3bbe2734c612ba341d813e043cf9e8a862cd5c57a36bbe6b
SPKI 8d417db2dd8bf5e3084d1e3f196d583849d81bdd4c00c70b9d39369e96b8c782
Evidence ledger · Every ID cited in this dossier

Claims, evidence and confidence

Confidence rates the specific claim, not the reputation of its source. High: shown by primary evidence or independently corroborated. Moderate: credible but not reproduced. Low: incomplete or indirect. Unknown: no evidence either way.

IDClaimEvidence · dateSource typeConfidenceOutstanding question
E-001 Eight eMudhra intermediate CA private keys are compromised Disclosure site; Chrome Root Program: "compromise of private keys associated with eight eMudhra subordinate CA certificates"
20 Oct 2026 Primary High —
E-002 The reporter proved possession by signing a message with each key Published signatures and OpenSSL steps; Chrome "completed corroborating the findings"
17–20 Oct 2026 Primary (reporter) + corroboration High Not reproduced by us: proof.zip could not be downloaded
E-003 8 unique keys appear in 16 certificate objects impacted-intermediates.json: 8 distinct SPKI hashes, each in an eMudhra-issued and a Sectigo-issued certificate
20 Oct 2026 Primary data High —
E-004 6 TLS (DV/OV/EV for two entities) and 2 code-signing intermediates JSON usage fields; Chrome: "six intermediate CAs" and "two compromised Code Signing CAs"
20 Oct 2026 Primary High —
E-005 All keys are ECDSA P-384; eMudhra-issued certificates valid from 30 Apr 2025 JSON key and validity fields
20 Oct 2026 Primary data High —
E-006 Issuers: emSign Root TLS CA - G3 (6), emSign Root CS CA - G3 (2), Sectigo AAA Certificate Services (8 cross-signs) JSON issuer fields
20 Oct 2026 Primary data High —
E-007 Root-store status of the three issuing roots and of emSign ECC Root CA - G3; trust path in Mozilla and Chrome via an ECC G3 cross-sign roots.json (CCADB-derived); eMudhra statement in Bug 2018979
20 Oct 2026 Primary data + technical inference High (status); Moderate (path) Cross-certificate itself not examined
E-008 All 16 certificates revoked, reason cACompromise JSON revocation fields; CCADB per Go issue #82345
18–19 Oct 2026 Primary High —
E-009 Chrome received the report 17 Oct 18:05 UTC and blocked the 6 TLS SPKIs via CRLSet at 19:45 UTC Chrome Root Program post
20 Oct 2026 Primary High —
E-010 Chrome did not need to block the 2 code-signing CAs Chrome: no TLS path through CS-EKU-constrained intermediates
20 Oct 2026 Primary High —
E-011 Mozilla received the report 17 Oct 20:06 UTC and blocked via OneCRL by 22:59 UTC Dennis Jackson, Mozilla dev-security-policy
20 Oct 2026 Primary High NSS post says OneCRL delivered "Saturday 19th"; conflicts with 17 Oct
E-012 Firefox 158.0.1 and ESR releases ship the block for users without remote settings MFSA2026-111; Firefox 158.0.1 release notes; CVE-2026-113470
20 Oct 2026 Primary High (158.0.1); Moderate (ESR versions) Mozilla blog post could not be read
E-013 NSS 3.131.1 removes emSign ECC Root CA - G3 (plus emSign C1 and ECC C3 at eMudhra's request) NSS release announcement; Bugs 2084101, 2083709
20 Oct 2026 Primary High —
E-014 Apple blocked on 19 Oct; Microsoft on 20 Oct Disclosure site only
20 Oct 2026 Secondary (reporter) Moderate No first-party Apple or Microsoft statement found
E-015 Go 1.27.3 and 1.26.10 reject chains through the 8 SPKIs (CVE-2026-111943) golang-announce; commit 7f86f95; go.dev release history
19 Oct 2026 Primary High Some reports date the release 20 Oct
E-016 webpki-roots and webpki-root-certs 1.0.10 remove emSign ECC Root CA - G3 Release and PR #133
19 Oct 2026 Primary High —
E-017 certifi 2026.10.19 removes the affected emSign root after restoring unaffected ones Release history, PR #437, commit 662df63
18–20 Oct 2026 Primary + technical inference Moderate Net diff not directly confirmed
E-018 Electron 44.9.1, 43.8.1, 42.11.16 patched Disclosure site; release notes silent
20 Oct 2026 Secondary (reporter) Low What changed is undocumented
E-019 Node.js and Composer fixes pending PR #66871 (draft), PR #154 (open)
20 Oct 2026 Primary High Release dates unknown
E-020 Homebrew ca-certificates excludes AAA, emSign Root TLS CA - G3 and emSign ECC Root CA - G3 by SPKI Formula at commit d02b876; SPKIs matched to roots.json
20 Oct 2026 Primary High —
E-021 No TLS certificate chaining to the six TLS intermediates was in CT before the Chrome block Chrome Root Program post
20 Oct 2026 Primary High (for stated scope) Logs and windows searched not listed
E-022 Chrome Root Store v43 will remove the eMudhra root; CT logs to reject these chains Chrome Root Program post
20 Oct 2026 Primary (stated intent) High Release date not given
E-023 How the keys were taken, by whom, and whether others hold them is unknown Absence of any CA or root-program statement; Bug 2083382 restricted; THN: "It is not known how the keys left eMudhra"
20 Oct 2026 Primary (absence) + secondary Unknown eMudhra incident report
E-024 No public evidence of fraudulent issuance, signed malware, impersonation or data theft Searches of vendor posts, news and security reporting to the cutoff
20 Oct 2026 Technical inference Low (absence of evidence) Code-signing issuance not logged
E-025 A "Wayne" reported undisclosed eMudhra subCAs in Bug 2018979 around 13 Oct Mozilla Bugzilla
~13 Oct 2026 Primary Low (link to this incident) Same person? Same issue?
E-026 eMudhra's 19 Oct NSE filing is an earnings-call notice with no incident mention NSE filing
19 Oct 2026 Primary High (fact) Whether a disclosure will follow
E-027 A report attributes a broad "no public TLS certificates" statement to Mozilla Cyber Kendra; not found in Mozilla sources
20 Oct 2026 Secondary Low Likely conflated with eMudhra's statement about other roots
Evidence gaps, unverified claims and research limitations
  • Root cause: unknown. Needs eMudhra's incident report or the contents of Mozilla Bug 2083382.
  • Other key holders: unknown. Needs forensic findings from eMudhra.
  • Code-signing misuse: unknown. Needs telemetry from endpoint and malware-analysis vendors on signatures under the two CS intermediates.
  • Apple and Microsoft: reported only. Needs vendor advisories or update records.
  • Firefox trust path: inferred. Needs the emSign ECC Root CA - G3 to TLS G3 cross-certificate.
  • Electron and certifi: release notes do not describe the change. Needs the diffs or maintainer statements.
  • CT scope: Chrome does not list the logs or windows searched.
  • Timing conflicts: NSS post says OneCRL was delivered "Saturday 19th"; other primary sources say 17 Oct. Go's release is dated 19 Oct by go.dev and 20 Oct by some reports.
  • Our own limits: we could not download proof.zip to reproduce the signatures, could not read Mozilla's security blog post (server error), and did not parse Name Constraints, Key Usage or EKU from the certificates ourselves.
Method

Every material claim was traced to its originator and checked against primary records: the researcher's certificate data, root-program posts, vendor advisories, release pages and commits. News reports were used for context and to find primary sources, never as the sole basis for a technical fact. Certificate details were transcribed from the published JSON and cross-checked against the SPKI list in Go's commit. No untrusted code was executed.

Research cutoff: 20 October 2026. Information published later will be added in a separate, dated update section rather than edited into the text above.

This dossier is research, not legal advice. Logos and screenshots are deliberately not used; all figures trace to the evidence ledger.

Frequently asked questions

What happened in the eMudhra CA compromise?

The private keys of eight intermediate certificate authorities operated by eMudhra's Dutch and US entities were exposed. A researcher proved possession to browser root programs on 17 October 2026, and the Chrome Root Program corroborated the finding. All 16 certificates containing those keys were revoked as cACompromise on 18 and 19 October.

Why are there 16 certificates but only eight keys?

Each of the eight intermediate keys appears in two certificates: one issued by an eMudhra root (emSign Root TLS CA - G3 or emSign Root CS CA - G3) and a cross-certificate issued by Sectigo's AAA Certificate Services. Blocking by public key (SPKI) covers both.

Were any fraudulent certificates issued?

No public evidence shows it. Chrome reported that no TLS certificates chaining to the six TLS intermediates were logged to Certificate Transparency before its 17 October block. That statement does not cover the two code-signing intermediates, whose certificates are not logged to CT.

Are browsers protected?

Chrome blocked the six TLS intermediates by CRLSet at 19:45 UTC on 17 October, and Mozilla blocked them through OneCRL the same evening and shipped Firefox 158.0.1. The researcher reports Apple blocked them on 19 October and Microsoft on 20 October; we found no first-party statement from either.

What should enterprises do now?

Rebuild Go services with Go 1.27.3 or 1.26.10, update CA bundles such as certifi, webpki-roots, NSS and Homebrew ca-certificates, redeploy containers, confirm proxies and TLS-inspection appliances distrust the affected SPKIs, replace certificates from affected emSign hierarchies, and hunt for binaries signed under the two code-signing CAs.

How did the keys leak?

Unknown. As of 20 October 2026, neither eMudhra nor Sectigo has published an incident report, and the Mozilla bug tracking the issue is restricted. It is not known how, when, or whether anyone other than the researcher holds the keys.

Sources linked in this report

  1. impacted-intermediates.json
  2. proof.zip
  3. Chrome Root Program
  4. MFSA2026-111
  5. NSS announcement
  6. announcement
  7. commit
  8. PR #133
  9. formula
  10. release
  11. v44.9.1
  12. PR #66871
  13. PR #154