eMudhra Certificate Key Compromise Triggers Chrome and Firefox Blocks

The eMudhra incident shows how a failure in certificate key generation can put trust in widely used software at risk. Eight intermediate certificate authority keys were compromised, creating the potential for attackers to forge certificates and impersonate websites or services.

Mozilla engineer Dennis Jackson said the report reached Mozilla on October 17 at 20:06 UTC, forwarded by the Chrome Root Program. Mozilla recovered the keys independently at 21:48 UTC, confirming that the generation process was flawed and that the keys were easy to derive. Security researcher Scott Helme reported that three had values of 4, 56 and 115; he recovered all eight from public certificates in less than a second. The report was submitted by a researcher identified as Wayne.

Six affected intermediates were intended for Transport Layer Security (TLS), which helps clients authenticate websites and establish encrypted connections. The other two were for code signing. Google said insufficient randomness made it possible to forge trusted HTTPS certificates for clients that still trusted the affected authorities.

Browser protections are in place

Google's Chrome Root Program blocked the intermediates through an update to Chrome's Revocation List Set. The company said Chrome users received protection without a browser update or restart. Android devices and Chromebooks received equivalent changes through Google Play Services.

Mozilla distributed a OneCRL block to Firefox users with standard configurations and announced updates for users whose custom settings could prevent them from receiving it. Google also removed the emSign ECC Root CA – G3, which signed the affected intermediates, from the Chrome Root Store. That change was scheduled to reach devices using the store on October 27.

Google said its review found no TLS certificates linked to the six affected intermediates in Certificate Transparency logs before the block. It said clients that enforce Certificate Transparency, including Chrome's default configuration, could not have used fraudulent certificates issued by those authorities.

That finding narrows the known exposure, but browser protections don't cover every application. Enterprise software and devices can rely on their own certificate stores, so teams need to check which authorities their systems trust as well as which certificates their services present.

Organizations need to check their own trust stores

Yash Kadakia, founder and CTO of Security Brigade, estimated that around 30,000 legitimate certificates would need to be migrated. He warned that government and public-sector websites using the affected hierarchy could trigger browser warnings or access problems if replacement certificates weren't installed in time.

His suggested review covers payment gateways, vendor integrations, older Java applications, mobile apps and network appliances. These systems may not inherit browser updates. Kadakia also advised testing whether affected clients reject certificates signed by the compromised keys, including certificates presented through cross-signed chains.

Cloudflare said it learned of the incident on October 19 and deployed mitigations across its content delivery network, developer services and Zero Trust products. It updated shared trust stores and base images, and released updates for Cloudflare One clients and Cloudflare Tunnel. The company said its review had found no active exploitation on Cloudflare services.

eMudhra says the intermediates issued no certificates

eMudhra said the affected intermediates were created during a key-generation ceremony in April 2025. The company said its root CA private keys and other intermediates weren't affected, and that none of the eight compromised intermediates had issued end-entity certificates, including the one deployed in production.

The company said public Certificate Transparency records supported its internal analysis. It was investigating the incident and reviewing its security controls. Kadakia said the lack of issued end-entity certificates was reassuring, while pointing out that possession of an intermediate key could let someone create fraudulent certificates without going through eMudhra.

The practical priority now is to verify that browsers, applications and managed devices reject certificates tied to the compromised keys. eMudhra's claim about certificates it issued addresses one part of the incident; organizations still need to account for the independent ability to forge certificates with those keys.

Mozilla bug report · Scott Helme's analysis · Google security post · Mozilla security post · Cloudflare incident report · eMudhra incident statement