Threat Type: Weak key generation compromising subordinate CA private keys (Web PKI trust failure). No software vulnerability or intrusion into eMudhra systems has been reported.

Severity: High (NopalCyber assessment; no CVE or CVSS score applies). The keys are recoverable almost instantly and are public, the certificates chain to roots trusted by the four major root programs, and non-browser clients stay exposed until updated. Revocation within hours, CT enforcement and no confirmed exploitation offset this. Mozilla rates its related Firefox update (MFSA 2026-111) High and Red Hat rates RHSB-2026-012 Important.

Authentication: None required to recover a key. Abuse needs a man-in-the-middle position (see Interception).

CVE ID: None for the incident; Red Hat states it is not a software vulnerability. Projects assigned identifiers to track trust-store updates: CVE-2026-111943 (Go crypto/x509), CVE-2026-113470 (Firefox), CVE-2026-114406 (RHEL ca-certificates), CVE-2026-91403 (Java) and CVE-2026-113812 (Perl Mozilla::CA). A third-party tracker lists CVSS 3.1 5.4 for the Firefox identifier without naming the scorer; it relates to the blocklist update, not the incident.

Threat Actors: None identified. Reported by independent researcher Wayne (Mozilla Bug 2083449). Several individuals independently recovered the keys (Mozilla comment 18), and BleepingComputer reports that researcher Flüpke published one key (EM OV TLS CA - G3C, value 4) on GitHub and that it matches a revoked certificate.

Affected CAs: Eight intermediates from a Key Generation Ceremony (KGC) on April 30, 2025: EM DV, OV and EV TLS CA - G3B (eMudhra BV) and G3C (eMudhra Inc), and EM OV CS CA - G3B and G3C (code signing). Each key appears in two certificates: one issued by emSign Root TLS CA - G3 or emSign Root CS CA - G3, and one Sectigo cross-certificate issued by AAA Certificate Services. Fingerprints are in Section 5.0. Per roots.json (published with the Mozilla disclosure, hosted on Dennis Jackson’s tracker site), the two emSign G3 roots are included by Microsoft only, emSign ECC Root CA - G3 (cross-signer) by Apple, Chrome, Microsoft and Mozilla, and AAA Certificate Services by Apple and Microsoft (removed from Chrome and Mozilla).

Affected Systems:

• Clients that trust a chain through emSign ECC Root CA - G3 or Sectigo’s AAA Certificate Services root without a block, revocation check or CT check.

• Mozilla NSS-derived stores (Debian, Ubuntu, RHEL 6 to 10, Fedora, Alpine) and software bundling them: Go, Node.js, Python certifi, Java, Rust webpki-roots, Electron and containers built on older CA bundles (sources reviewed).

• macOS built-in curl, git, python3, perl, ruby and openssl, which use the non-updated /etc/ssl/cert.pem and are not covered by Apple’s block (Dennis Jackson; BleepingComputer for curl).

• Code signing: Microsoft trusts the affected code-signing root directly.

Scope limits stated by sources: eMudhra states its root keys, other intermediates and India digital signature and eSign services are not affected (CERT-In notes those use separate keys), and that only one affected intermediate was deployed in production. Google’s review of its root stores and a CCADB scan by Wayne using paranoid_crypto (dev-security-policy, October 21) found no other key with the same failure. Mozilla could not recover the A and A-1 series P-384 keys and had not examined the RSA keys (preliminary).

Root cause (eMudhra, preliminary): The KGC used Utimaco HSMs, and an approved deviation to test key wrap/unwrap introduced a code error that created a second, weaker key pair onboard. The weak keys were used by mistake for the certificate signing requests, which had similar key labels, and the same requests went to Sectigo. Mozilla confirmed the P-384 keys are integers below 256 (The Register reports values from 4 to 237). CERT-In notes this is not a weakness in P-384. eMudhra also states that 2025 CRLs for the six TLS intermediates failed validation (Bug 1970728) and were re-signed with the weak keys. No full root-cause report exists yet; eMudhra says it will publish one and re-check every key ceremony (Help Net Security). The Chrome Root Program and others asked for the KGC script, HSM FIPS status, ceremony records and migration metrics (Bug 2083449, comments 30 to 33), unanswered at the time of writing.

Exploit Status: No confirmed malicious exploitation; the keys are public.

• CERT-In: public disclosures do not establish confirmed exploitation as of October 21. Google: no TLS certificate chaining to the six TLS intermediates was logged in CT before its block. Cloudflare: no active exploitation on its services.

• BleepingComputer: the keys could have been abused since April 2025, with no evidence this happened. Dennis Jackson: unknown whether attackers used them against clients that do not enforce CT.

• Scott Helme recovered all eight keys in under a second.

Attack Chain:

• Key Recovery: A P-384 key should be a random integer up to the group order. All eight are below 256, so each can be derived from the public certificate by generating the first 256 candidate P-384 keys or by baby-step giant-step (Mozilla).

• Certificate Forgery: A key holder can sign TLS certificates for any domain, or code-signing certificates (CERT-In).

• Interception: The client must trust the affected chain, and the attacker must hold a key and a man-in-the-middle position (Red Hat, Mozilla).

• Client Acceptance: CT-enforcing browsers reject unlogged certificates (Google). Clients with static bundles that check neither revocation nor CT accept them. In Scott Helme’s test, curl, Python and Node accepted a forged api.stripe.com certificate by default on Linux and macOS, and Windows CryptoAPI accepted it unless revocation checking was on, and then only one of two routes reported it revoked.

• Persistence and Command and Control: Not applicable; no malware or attacker infrastructure reported.

Timeline (UTC, dates in 2026 unless stated):

• April 30, 2025: The eight intermediates are created in the KGC.

• October 17: Chrome receives the report at 18:05 and lands a CRLSet block at 19:45. Mozilla receives it at 20:06 and completes its OneCRL block at 22:59.

• October 18: eMudhra’s CRL shows all eight certificates revoked (cACompromise) between 09:24 and 09:38. eMudhra’s statement dates the revocation to October 19.

• October 19: Sectigo revokes the eight cross-certificates (10:35, per Dennis Jackson’s data). Android devices receive the block through Google Play services. Apple is reported to block the certificates (October 19 per BleepingComputer, Endor Labs and Help Net Security; Dennis Jackson’s tracker now says October 22; no Apple notice found to resolve it).

• October 20: Microsoft is reported to block the certificates (Dennis Jackson, The Hacker News). Mozilla and Google publish formal disclosures. Mozilla removes emSign ECC Root CA - G3 in NSS 3.131.1 and releases Firefox 158.0.1, ESR 115.43.1 and ESR 153.5.1. eMudhra publishes its first statement.

• October 21: Firefox for Android 158.0.2 (08:29) fixes some clients not applying the OneCRL change after startup. CERT-In publishes CIAD-2026-0050, Red Hat publishes RHSB-2026-012, and eMudhra updates its statement and issues a press release. Dennis Jackson’s tracker lists OpenJDK and Oracle JDK advisories.

• October 22: eMudhra announces its Board decision to exit global SSL/TLS and says it will still publish a root-cause report (The Register). Dennis Jackson’s tracker adds two No CT test chains.

• October 27 (morning, PDT): Chrome Root Store v43, which removes emSign ECC Root CA - G3, is expected to reach all devices that rely on it.