Weak private keys could allow attackers to forge trusted certificates and impersonate websites; Google, Mozilla and Cloudflare have taken steps to contain the risk
Private keys associated with eight digital certificates issued by Indian certification authority eMudhra have been compromised, according to a Mozilla security engineer, potentially allowing attackers to forge trusted certificates and impersonate websites.
Dennis Jackson, a member of Mozilla’s cryptography engineering team, said the company received a report of the compromise on Oct. 17 from a researcher identified as Wayne. The report included proof that all eight private keys had been compromised and was forwarded by Google’s Chrome Root Program to Mozilla.
Mozilla independently recovered all eight keys, confirming that the key-generation process was flawed. “This confirmed the key generation process was flawed and is trivial to exploit,” Jackson wrote in Mozilla’s account of the incident.
The weakness was so severe that one of the private keys was simply the number 4, according to security researcher Scott Helme. Other recovered keys included 56 and 115, he said in his technical analysis.
The affected keys belonged to eight intermediate certificate authorities. Six of the certificates were used for Transport Layer Security (TLS) and trusted by the Chrome, Mozilla, Microsoft and Apple root programs. The other two were code-signing certificates trusted by Microsoft, Jackson said.
Digital certificates help browsers and applications verify the identity of websites and services. Intermediate certificate authorities issue certificates that establish this trust. An attacker who obtains an authority’s private key may be able to create fraudulent certificates that appear legitimate to systems that still trust the authority.
Such certificates could be used to impersonate websites and, if an attacker could intercept a connection, potentially read or modify traffic. However, the compromise does not by itself establish that fraudulent certificates were issued or used in attacks.
Google and Mozilla block affected certificates
Google’s Chrome Root Program blocked the affected intermediate authorities through a Certificate Revocation List Set update, according to the company’s security advisory. The mechanism allows Chrome to reject certificates associated with the compromised keys without requiring users to restart their browsers. Android devices received equivalent protection through Google Play Services.
Google also said it would remove the emSign ECC Root CA – G3 certificate from the Chrome Root Store. The root certificate had signed the affected intermediates. Google warned that the change could cause some legitimate certificates linked to that root to stop working in Chrome.
Mozilla began distrusting the affected certificates through OneCRL, its centralized certificate-blocking mechanism, shortly after acknowledging the report at 20:08 UTC on Oct. 17. The process was completed at 22:59 UTC, less than three hours after the initial report, Jackson said.
The report was also sent to eMudhra and the root certificate programs operated by Apple and Microsoft. Jackson said eMudhra acknowledged the report at 21:29 UTC and told Mozilla it was investigating the issue. The company had also notified Sectigo, which had cross-signed some of the affected certificates.
Cloudflare updates its systems
Cloudflare said it became aware of the compromise on Oct. 19 and began updating services that rely on certificate verification.
“Because the keys themselves are weak, an attacker can create a forged certificate for any domain and use it to impersonate servers to intercept or modify traffic,” the company said in its incident report.
Cloudflare updated shared trust stores and base images, deployed mitigations across its content delivery network, developer and Zero Trust products, and released updates for Cloudflare One clients and Cloudflare Tunnel.
The company said its security review had not identified active exploitation of the issue on its services. It warned that some customers would need to update software and certificate-trust configurations they manage themselves.
Cloudflare also cautioned that updating an application’s software development kit might not be enough to resolve the problem. Applications can rely on separate libraries, operating-system certificate stores or custom configurations to verify certificates.
eMudhra says no end-entity certificates were issued
In its statement on the incident, eMudhra said the eight intermediate certificate authorities were created during a key-generation ceremony in April 2025.
The company said the incident did not affect its root certificate authority private keys or other intermediate authorities. Only one of the eight affected intermediates had been deployed in production, and none had issued end-entity certificates, eMudhra said. The company said its internal analysis and publicly available Certificate Transparency records supported that finding.
eMudhra said it had begun incident-response procedures and was working with browser and root-store operators. Its investigation into the incident and its security controls was continuing.
The company’s statement distinguishes the potential for certificate forgery from evidence of actual misuse. The compromised keys could have enabled attackers to create fraudulent certificates, but the available disclosures do not establish that attackers used them to impersonate websites.
The incident also raises questions for organisations whose applications, servers and connected devices rely on certificate stores outside web browsers. Those systems may not receive the same automatic protections as Chrome or Firefox. Cloudflare advised developers to check how their applications validate certificates and update affected dependencies rather than assuming that browser updates protect every system.
