Eight intermediate certificate keys linked to Indian digital trust company eMudhra have been compromised, triggering an urgent security response from Google, Mozilla, Cloudflare and other software developers. The incident exposed a serious weakness in the system used to establish trust between websites and their visitors.
The compromised keys could allow attackers to create fraudulent HTTPS certificates for domains they do not own. This could help them impersonate legitimate websites and potentially intercept or modify traffic if they could also position themselves between a victim and the intended server.
Cloudflare confirmed the incident in a blog post. The company said it had not identified active exploitation on its own services and had already deployed security measures across its network. However, the incident is not limited to Cloudflare. Any application that continues to trust the affected certificates without effective revocation protection could remain at risk.
The issue was reported to browser security teams on October 17, 2026. According to Google’s Chrome security team, a researcher reported that the private keys associated with eight eMudhra subordinate Certificate Authority (CA) certificates had been generated with insufficient randomness.
Private keys must be unpredictable. In this case, the keys were so weak that researchers could recover them from publicly available certificate information. Mozilla independently recovered the keys, confirming that the problem was not simply an unverified claim.
The affected certificates include six intended for TLS website authentication and two intended for code signing. The weakness could allow someone with the recovered keys to sign fraudulent certificates that appear to come from a trusted certificate authority.
This is particularly serious because intermediate CAs help issue certificates for websites and other services. If an attacker controls an intermediate CA’s private key, they can potentially create certificates for domains they do not own.
The flaw does not mean that attackers have broken HTTPS encryption algorithms. It means the system used to verify a server’s identity can be undermined. Even strong encryption cannot guarantee that users are talking to the right server if the certificate used to establish that identity is fraudulent.
Could attackers impersonate any website?
In principle, yes. An attacker with one of the compromised TLS signing keys could create a certificate for a target domain. However, that alone would not give the attacker access to a victim’s traffic.
They would still need a way to intercept or redirect the connection, such as through a compromised network or another traffic interception technique. If the victim’s software accepted the fraudulent certificate, the attacker could potentially impersonate the server and read or modify the connection.
There is an important qualification. Google said it had found no Certificate Transparency records showing certificates chaining to the six affected TLS intermediates before the browser blocks were applied. eMudhra also said its internal analysis and public Certificate Transparency records showed that the affected intermediates had not issued end-entity certificates.
This is reassuring, but it does not make the key compromise insignificant. Certificate Transparency records help track publicly trusted certificates, but they do not prove that no attempted or other forms of abuse occurred. The available evidence does not establish that attackers used the keys to intercept real users’ connections.
Google confirmed the compromise and deployed a Chrome CRLSet update on October 17. The update blocks the affected public-key hashes, preventing Chrome from trusting certificates that use those keys without requiring users to install a browser update or restart it.
Mozilla also added the certificates to OneCRL, its centralised certificate blocklist. The update reached Firefox users with standard configurations within hours. Mozilla subsequently released Firefox 158.0.1, Firefox ESR 115.43.1 and Firefox ESR 153.5.1 to extend protection to users whose settings might prevent normal blocklist updates. It is also updating the NSS trust store used by Firefox and other applications.
Cloudflare said it had deployed mitigations across its CDN, Developer Platform and Zero Trust services. It also updated shared trust stores and other common components used to authenticate remote servers.
The company released security updates for Cloudflare One clients, the WARP and 1.1.1.1 apps, and Cloudflare Tunnel, also known as cloudflared.
What should users and businesses do?
Most users should keep their browsers and operating systems updated. Chrome and Firefox have already deployed protections through their certificate blocklists, but not every application uses the same trust store or receives these updates.
Cloudflare customers should install the following versions where applicable:
| Software | Required version |
|---|---|
| Cloudflare One Client for Android | 2.5.6 |
| Cloudflare One Client for iOS | 1.12.16 |
| 1.1.1.1 app for Android | 6.38.10 |
| 1.1.1.1 app for iOS | 6.31.7 |
| Windows, macOS and Linux desktop clients | 2026.8.2115.0 |
| Cloudflare Tunnel | 2026.10.2 |
Businesses should review custom certificate authorities, mutual TLS trust stores and origin server configurations. Organisations running Cloudflare Containers should also check their images and application dependencies for affected trust stores, then rebuild and redeploy them where necessary.
Developers need to check how their applications validate certificates. Verification may be handled by an operating system, HTTP library, language runtime or a bundled trust store. Updating an SDK alone may not be enough.
Cloudflare has specifically warned developers not to disable certificate verification to work around errors after applying security fixes. Doing so would remove the authentication protection these updates are designed to restore.
The biggest challenge now is ensuring that every affected system stops trusting the compromised keys. Browser makers can push centralised blocklists quickly, but servers, containers, embedded devices and older applications may depend on certificate stores that need separate updates.
eMudhra said the incident involved intermediate certificates created during a key generation ceremony in April 2025. The company said its root CA private keys were not compromised and that none of the affected intermediates had issued end-entity certificates, according to its investigation.
The available information does not establish how the weak keys were generated or why the problem passed the company’s checks. Those questions matter because the incident involves a failure at the certificate authority level, where strong key generation is a basic security requirement.
I think the most concerning part is not just that eight weak keys were discovered. It is that trust in a certificate can extend across browsers, operating systems, and applications, while revocation does not reach all of them equally quickly.
The immediate response from major browser makers has reduced the risk for many users. However, businesses should not assume that a browser update protects every application on their systems. They need to check the actual certificate verification paths their software uses and confirm that the affected keys are no longer trusted.
Related Posts
