Weak encryption keys discovered

Private keys from the eMudhra certificate authority were found to be extremely weak, allowing them to be recovered almost instantly. The incident, revealed on October 20, 2026, enables the creation of fake certificates to impersonate websites in front of vulnerable software.

Browsers respond quickly

The main browsers have reacted, but patches still need to reach many other tools. The private key was simply the number 4, while the other seven had values such as 56, 66, 115, 155, 156, 230, and 237, reports Ars Technica on October 20, 2026. The discovery pushed Chrome and Firefox to urgently block the affected certificates as early as October 17.

Explanation of the threat

In their statements, Mozilla and Google explain that these keys could allow the creation of fake HTTPS certificates to impersonate websites in front of vulnerable software. The company involved, eMudhra, is Indian. However, its certificates are recognized by software used worldwide.

Understanding digital certificates

Although browsers have reacted quickly, many other applications and infrastructures also need to be protected. A fake ID for any website. To understand the problem, one must return to the role of a certificate. When a browser connects to a website in HTTPS, it must verify that it is communicating with the correct server.

How the compromise works

A digital certificate serves, in a way, as an ID card. The browser recognizes it through a chain of signatures from authorities to which it trusts. The compromised certificates belong to intermediate authorities: the private keys associated with them allow signing other certificates. Recovering these keys is therefore equivalent to obtaining the official stamp with which to create fake ID cards.

Technical flaws in key generation

These keys should normally be chosen randomly from an enormous number of possibilities. The system used here, called P-384, offers nearly 2 to the power of 384 possible values: trying them all is unrealistic. However, in the technical report published on Mozilla's website, Dennis Jackson, a cryptography engineer, confirms that the eight keys in question were numbers below 256.

Verification of the breach

They could therefore be recovered almost immediately from the public certificates. The report distinguishes six certificates intended for TLS connections and two for software signing. The researcher who reported the issue, identified under the name Wayne, provided a demonstration: "We have a problem here – Wayne," or "We have a problem here – Wayne."

Potential risks for users

He digitally signed this message with each of the eight compromised keys. The signatures could be verified using the public keys contained in the certificates, proving that he indeed had the secret keys. What risk for your connections? Imagine a vulnerable application connects to a service to transmit personal information. If an attacker manages to intercept this connection, he can present a fake certificate and impersonate the expected server.

Limitations of the threat

The application trusts him: he can then potentially read or modify the exchanges. This condition is essential: the attacker must also be able to intercept the connection. Possessing these keys does not automatically give him access to all internet users' accounts. As Cloudflare points out, the TLS encryption algorithms themselves have not been broken.

Ongoing efforts to secure systems

The problem concerns the server's identity: an encrypted connection does not protect the data if it is established with an imposter. The browsers have reacted, the other software must follow. Chrome and Firefox have blocked the affected certificates as early as October 17.

Challenges in patching all systems

Mozilla states that it distributed its protection in less than three hours to Firefox users keeping standard settings, without requiring a browser restart. According to Dennis Jackson's technical tracking page, the blocks were also deployed on Apple devices on October 19, then on Microsoft platforms on October 20.

Incomplete protection across tools

These measures, however, do not automatically protect all installed software. The page notes that the curl connection tool provided with macOS uses a separate certificate list and could still accept the compromised certificates despite Apple's blocking. Some tools therefore need to be fixed separately: a protected browser does not guarantee that all connections on the same device are protected.

Comparison to past vulnerabilities

Asked by Ars Technica, cryptographer Filippo Valsorda estimates that this project could surpass that of Heartbleed, a major flaw discovered in 2014. He points out particularly the diversity of systems to be fixed and the forgotten machines or tools that are no longer maintained.

No confirmed malicious use yet

At this stage, no malicious exploitation has been confirmed in the consulted sources. Google indicates that no TLS certificate attached to the six intermediate certificates involved had been registered in public transparency logs before their blocking. This prevented their use against software requiring this registration, such as Chrome.

Explanation from eMudhra

Attacks against those who do not check it, however, cannot be ruled out. In a response published on Mozilla's incident tracking, Naveen Kumar ML, from eMudhra, provides an initial explanation: an error in the key generation program would have produced a second set of weaker keys, subsequently used by mistake due to similar labels.

Recommendations for users

For users, the recommendation is to update browsers, operating systems, and applications as soon as patches are available. IT managers should also check software and equipment that do not benefit from automatic updates.