Cisco Talos details weak entropy flaw in eight compromised eMudhra certificates
Researchers found that eight eMudhra intermediate CA private keys used minimal randomness, allowing trivial recovery and potential impersonation attacks.
Key points
- Eight eMudhra intermediate certificates were compromised due to weak entropy during key generation in April 2025.
- Major browser vendors and Microsoft have blocked the six TLS and two code-signing certificates.
- The Go programming language released updates to filter chains containing the compromised keys.
Cisco Talos researchers identified eight intermediate certificates from eMudhra that possess critically weak private keys, enabling attackers to impersonate websites or services. As Threat Times reported on October 21, 2026, major browser vendors and root trust stores have already revoked these certificates after the vulnerability was demonstrated.
The compromised keys originated from a key generation ceremony on April 30, 2025, conducted under eMudhra’s emSign Root TLS CA - G3. A flaw in the process reduced entropy from the required 384 bits to just three to eight bits. This misconfiguration allows anyone with access to the public certificate to trivially derive the corresponding private key.
Technical context and vendor response
Six of the affected certificates are used for Transport Layer Security (TLS) and were trusted by Chrome, Mozilla, and Apple. The remaining two are code-signing certificates used by Microsoft. All eight have now been blocked by these respective vendors. eMudhra has revoked the compromised certificates and halted issuance under its G3 root following the disclosure.
The Go programming language team addressed the issue by releasing versions 1.27.3 and 1.26.10. These updates filter out certificate chains containing the SubjectPublicKeyInfo hashes of the eight compromised intermediates. This action aims to protect cloud-native ecosystems, including Docker, Kubernetes, Terraform, and Prometheus, which may rely on embedded trust stores that ignore revocation lists.
Scope of impact and current status
Public key infrastructure relies on delegated trust through certificate chains. An attacker possessing an intermediate CA’s private key can issue fraudulent certificates that clients accept if validation controls are insufficient. For TLS, this could enable man-in-the-middle attacks, allowing adversaries to intercept or modify traffic if the client still trusts the affected key.
Talos stated that as of October 21, 2026, at 14:00 UTC, no malicious incidents involving these certificates have been observed in the wild. However, applications that do not check revocation lists, such as certain virtual private network clients, may remain vulnerable. Talos recommends updating software that handles TLS certificates as fixes become available.
What should you do?
Organizations should audit their public and internal public key infrastructure assets to identify any services chaining up to eMudhra intermediate CAs. Inspect code repositories and build pipelines to ensure no hard-coded trust anchors or intermediate certificates were bundled into applications. Additionally, audit internal systems and custom trust stores for eMudhra roots or intermediates.
What to do and how to stay safe: eMudhra
- Inventory all public-facing services and internal infrastructure to identify any active TLS certificates chaining to eMudhra intermediates.
- Audit software projects, containers, and deployment scripts for bundled eMudhra certificates or hard-coded trust anchors.
- Search internal systems and custom trust stores, including Linux directories and Java keystores, for eMudhra roots.
- Monitor for software updates that filter out the compromised certificate chains, such as the recent Go runtime patches.
Step-by-step guide: Social Engineering Warning Signs and How to Respond
General security guidance from the Threat Times newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
How many eMudhra certificates were compromised?
Eight intermediate certificates were compromised, including six for TLS and two for code signing.
What caused the private keys to be weak?
A flaw in eMudhra's key generation process reduced entropy from 384 bits to between three and eight bits.
Have any attacks been observed using these keys?
No, Cisco Talos reported no malicious incidents involving these certificates as of October 21, 2026.
