eMudhra Certificate Authority Incident: Eight Weak Intermediate CA Keys Expose Global Trust
Eight eMudhra intermediate certificate authority (CA) certificates were found to contain cryptographically weak private keys that could be recovered from their corresponding public keys. Six intermediates were associated with TLS certificate issuance and two with code signing. An attacker possessing these private keys could potentially create fraudulent certificates to impersonate websites, intercept communications or sign malicious software. The affected intermediates have been revoked, and major browser and platform vendors have moved to distrust them.
Impacted systems
| Software / application | Version / scope |
|---|---|
| eMudhra Global TLS intermediate CA certificates | Affected: six TLS intermediates with cryptographically weak private keys generated during the April 2025 key-generation ceremony. The affected intermediates were revoked on 18 October 2026. Verify that all relevant trust stores reject the affected certificate chains. |
| eMudhra code-signing intermediate CA certificates | Affected: two code-signing intermediates with cryptographically weak private keys. Platform trust updates are required to prevent acceptance of signatures chaining to the affected certificates. |
| Oracle Java | Affected: deployments whose certificate-validation behaviour is vulnerable to the affected eMudhra CA certificates. Apply the vendor security update associated with CVE-2026-91403 and verify the effective trust configuration. |
| Go applications and runtimes | Affected: deployments that may continue trusting the affected CA hierarchy through their certificate-validation path. Apply the vendor fix associated with CVE-2026-111943 and rebuild or redeploy affected applications. |
| Mozilla Firefox | Affected: deployments that continue to trust the affected TLS certificate authorities. Apply the vendor update associated with CVE-2026-113470 and verify that the affected authorities are distrusted. |
| Custom and application-specific trust stores | Affected: operating systems, containers, Java runtimes, SDKs, CI/CD runners, API clients, network appliances, OT/IoT devices and embedded systems that retain trust in the affected certificate authorities. Fixed: update or explicitly remove the affected trust anchors and intermediates using the applicable vendor guidance. |
Exploitation conditions
An attacker who obtains one of the affected intermediate CA private keys can potentially sign fraudulent certificates that chain to a previously trusted CA hierarchy. For TLS, this can enable impersonation of arbitrary domains and man-in-the-middle attacks against clients that continue to trust the affected chain. For code signing, the compromised intermediates could potentially be used to sign malicious software or other content that appears to have a trusted signature. The underlying defect involved insufficient cryptographic randomness, which made the private keys recoverable from their public keys. The issue was reported on 17 October 2026, and eMudhra revoked the eight affected intermediates on 18 October 2026. Browser and platform vendors subsequently implemented distrust measures. Available reporting does not establish widespread successful exploitation. Exposure remains possible on systems with stale or independently maintained trust stores, incomplete vendor updates or certificate-validation implementations that do not enforce the updated distrust decisions.
Recommended action
- Inventory certificate trust dependencies across endpoints, servers, application runtimes, containers, CI/CD systems, VPNs, proxies, API clients, network appliances and OT/IoT devices. Identify systems that trust the affected eMudhra intermediate certificates or their distrusted root hierarchy.
- Apply the latest applicable security updates from operating-system, browser, runtime and application vendors. Address CVE-2026-91403 in Oracle Java, CVE-2026-111943 in Go and CVE-2026-113470 in Firefox using the relevant vendor advisories.
- Update operating-system CA bundles, application-specific trust stores, container base images, Java trust stores and bundled certificate packages. Remove or distrust affected certificates according to vendor guidance rather than relying on browser updates alone.
- Review TLS client authentication, mutual TLS configurations, custom CA bundles, outbound API connections and origin-certificate validation. Check whether any application continues accepting chains associated with the affected intermediates.
- Inspect software supply-chain controls and code-signing verification paths. Ensure that affected code-signing certificates are rejected and that software signatures are validated against updated platform trust policies.
- Review certificate transparency records, TLS inspection telemetry, DNS and proxy logs, EDR alerts and application logs for suspicious certificate issuance, unexpected certificate chains, anomalous authentication events or possible man-in-the-middle activity.
- If suspicious activity is identified, preserve logs and forensic evidence, isolate affected systems where necessary, investigate possible credential exposure and rotate credentials or tokens that may have been intercepted.
- Replace affected certificates where applicable and validate trust decisions through the actual application or service validation path. A successful browser test does not prove that background services, SDKs or custom TLS clients are protected.
- Document systems that cannot receive trust-store updates, apply vendor-supported compensating controls, restrict exposure where feasible and track remediation to completion.
Workarounds
Where vendor updates are unavailable, explicitly remove or distrust the affected certificate authorities in application-specific trust stores using a supported configuration. Validate the effect carefully because removing a CA can disrupt legitimate connections.
For legacy devices or embedded systems that cannot be updated promptly, restrict access to affected services, route connections through a suitably updated and managed TLS validation layer where technically appropriate, and plan a supported firmware or trust-store update.
For critical services, move to replacement certificates issued under an independently trusted CA hierarchy where the service owner and certificate provider support the migration. Validate the new certificate chain before switching production traffic.
Do not disable TLS certificate verification, hostname validation or code-signing verification to work around certificate errors. These controls are essential to prevent impersonation and restore the intended security boundary.
Sources
- 8 eMudhra certificates are compromised. Here's what you need to know ↗
- The eMudhra Certificate Authority Incident Is a Wake-Up Call for Enterprise PKI ↗
- eMudhra Intermediate CA Certificates Compromised ↗
- eMudhra Statement on Recent Certificate Security Incident ↗
- Microsoft's response to compromised eMudhra certificate authority keys ↗
- Compromise of eMudhra Intermediate CA Certificates ↗