Compromised eMudhra Intermediate CA Certificates

Public Key Infrastructure (PKI) | Certificate Authority | TLS | Code Signing | CVE-2026-111943

Source Material: Google Security; Mozilla Security; CERT-In; eMudhra | Technology: PKI, TLS, code signing, operating-system and application trust stores | Targeting: Opportunistic

Executive Summary

Security researchers have reported control of the private keys for eight eMudhra intermediate certificate authorities: six authorized for TLS and two for code signing. Google, Mozilla, Apple, Microsoft, eMudhra, Sectigo, and downstream software maintainers have begun revoking or blocking the affected keys. eMudhra attributes the weakness to a flaw during a key-generation ceremony that published a set of extremely weak elliptic-curve keys.

The exposed Certificate Authority (CA) keys could be used to create fraudulent certificates for arbitrary domains or to sign malicious software. A successful TLS attack still requires a client that trusts an affected chain and an attacker able to intercept or redirect traffic. Google reported no TLS leaf certificates from the six compromised TLS intermediates in Certificate Transparency (CT) logs before its block, and no credible source has confirmed malicious use. Absence from CT does not exclude unlogged certificates against clients that do not enforce CT.

Organizations should prioritize remediating environments that lack automatic browser revocation feeds, including stale trust stores, TLS-inspection proxies, appliances, and containers, by explicitly distrusting affected intermediates and replacing certificates before root removal causes disruption. Update trust stores and software, explicitly distrust affected intermediates where updates are unavailable, and replace server certificates chaining to emSign ECC Root CA – G3 before root removal causes disruption.

Threat Overview and Strategic Impact

The incident is a Web PKI trust failure, not evidence that an eMudhra network was breached. Researchers independently recovered the affected private keys shortly after disclosure, confirming that the key-generation weakness has practical impacts. Researchers reported that the P-384 private values were smaller than 256, making recovery from the public keys effectively immediate. eMudhra states that a wrap/unwrap flaw during a FIPS 140-2 Level 3 HSM ceremony produced weak secondary keys and that its infrastructure, data, Indian Digital Signature Certificate business, and eSign services were not compromised. Those vendor assertions remain subject to the ongoing root-cause investigation.

Six affected intermediates could issue browser-trusted TLS certificates; two could issue code-signing certificates which are trusted by Microsoft. The same key material also existed in Sectigo cross-signed certificates. An adversary could forge a certificate for a high-value domain and combine it with DNS, routing, Wi-Fi, proxy, or other network-positioning techniques to impersonate a service, decrypt traffic, capture credentials, or alter content. The code-signing keys could be used to make malicious software appear signed by a trusted chain where revocation or updated deny lists are not enforced.

Chrome blocked the TLS keys through CRLSet on October 17, 2026 and Mozilla completed a OneCRL block the same day. eMudhra revoked the eight certificates on October 18, 2026; Sectigo revoked cross-signs on October 19, 2026. Firefox released 158.0.1, ESR 115.43.1, and ESR 153.5.1, followed by Firefox for Android 158.0.2 for a bundled-blocklist issue. Go added a deny list in 1.26.10 and 1.27.3. Google plans broad removal of emSign ECC Root CA – G3 from the Chrome Root Store on October 27, 2026. This layered response reduces risk for updated platforms but may break legitimate services that still chain to the removed root.

Risk is highest where revocation checks fail open, CT is not enforced, or trust stores are bundled and rarely refreshed. Root removal can create availability impact even when a server certificate was not issued by a compromised intermediate, so remediation should address both security exposure and certificate-chain continuity.

Security Hardening and Recommendations

Apply current browser, operating-system, mobile-platform, CA-bundle, Java/runtime, container-base-image, appliance, and security-product updates. Upgrade Go to 1.26.10 or 1.27.3 or later where applicable.
Inventory Internet-facing and internal services whose chains include emSign ECC Root CA – G3, emSign Root TLS CA – G3, or AAA Certificate Services. Replace affected or dependent certificates with a chain from an unaffected trusted hierarchy before root-store removals reach clients.
For products without timely updates, use the vendor-supported mechanism to distrust the eight affected intermediate keys. Removing an entire root can protect clients but may disrupt legitimate chains; test before broad deployment.
Confirm TLS inspection, secure web gateways, VPNs, EDR agents, package managers, embedded devices, and custom applications perform revocation checking and fail closed where operationally appropriate.
Rebuild containers and immutable images after trust-store updates. Review code-signing policy and block binaries chaining through EM OV CS CA – G3B or G3C unless a trusted vendor has explicitly remediated the chain.

Detection Strategy

Monitor TLS telemetry, proxy logs, endpoint certificate stores, and application validation errors for the affected intermediate subjects, certificate fingerprints, or SPKI hashes. Alert when high-value domains present a new or unexpected issuer, when a chain includes eMudhra G3B/G3C intermediates, or when a client accepts a chain rejected by a patched reference client. Compare observed leaf certificates with Certificate Transparency (CT) where the client is expected to enforce CT.

For code signing, collect Authenticode signer chains and flag executables, installers, drivers, or scripts chaining through EM OV CS CA – G3B or EM OV CS CA – G3C, especially files first seen after October 17, 2026. Correlate with reputation, download source, file prevalence, parent process, and execution behavior; a chain match is a triage lead, not proof of maliciousness.

After remediation, watch for spikes in certificate-validation, OCSP, CRL, or handshake failures. These may identify devices with stale trust stores or legitimate services still dependent on removed roots. No public indicators currently demonstrate successful exploitation, so detection should focus on certificate-chain anomalies and enabling network-positioning behaviors.

How Deepwatch Protects Our Customers

Deepwatch experts use available DNS, proxy, firewall, network, endpoint, and cloud telemetry to investigate unexpected certificate chains, network redirection, anomalous proxy use, and suspicious execution of newly observed signed binaries. Coverage depends on the data sources and certificate metadata available in each customer environment. Customers should coordinate with the Deepwatch team to validate ingestion from TLS-inspection devices and endpoint tooling, confirm whether affected certificate fields are searchable, and verify visibility for high-value services.

Relevant Detections

Please visit the Guardian Platform to access the relevant detections for this activity and ask NEXA Detection Advisor for a breakdown of which detections are enabled in your environment.

Threat Hunting Leads

Search TLS, proxy, and network-security logs for the six affected TLS intermediate subjects and SPKI SHA-256 hashes
Inventory systems and applications that bundle CA stores or disable revocation and CT enforcement
Compare certificate chains for critical domains against a patched Chrome or Firefox reference client
Review Authenticode chains for files first seen on or after October 17, 2026 to identify signatures chaining to eMudhra OV Code-Signing CAs (G3B/G3C)
Hunt for DNS poisoning, rogue proxy settings, unauthorized VPN gateways, ARP spoofing, or route changes coinciding with certificate anomalies
Identify legitimate services chaining to emSign ECC Root CA – G3 and track replacement before root distrust causes outages

Technical Artifacts

Please visit the Guardian Platform to access available technical artifacts for this report.

Threat Object Mapping

Intrusion Set:

No intrusion set or threat actor has been attributed to exploitation of the compromised keys.

Attack Pattern (MITRE ATT&CK/MITRE ATLAS):

Tactic	Technique	Technique ID	Associated Threat Activity
Credential Access / Collection	Adversary-in-the-Middle	T1557	Forge a trusted TLS certificate and combine it with traffic interception or redirection.
Resource Development	Develop Capabilities: Digital Certificates	T1587.003	Recover weak CA private keys and create fraudulent certificates.
Defense Evasion	Subvert Trust Controls: Code Signing	T1553.002	Use an affected code-signing chain to make malicious software appear trusted.

Vulnerabilities:

CVE-2026-111943 / GO-2026-6809 – Go crypto/x509 trust-store mitigation tracking; no CVSS score published. This is a certificate-authority key compromise, not a conventional product vulnerability.