Mozilla and Google announced their responses on October 20, 2026, after a problem was discovered in eight intermediate certificate authorities (CAs) operated by eMudhra, a digital certificate issuer: the private keys used to sign certificates could easily be recovered by third parties. In software that continues to trust the flawed keys, an attacker able to intercept traffic could use forged certificates to impersonate a destination and read or tamper with communications. Major browsers have already moved to block the problematic certificates, but applications that use their own certificate validation may need separate updates.
There are two main countermeasures: rejecting only the keys and certificates of the problematic intermediate CAs, or removing the root certificate above them from the trust list. The latter has a much broader impact and could make legitimate sites using unaffected certificates unreachable. That is why users need to update their apps' validation mechanisms, while site operators may need to switch certificates as necessary.
Secret values below 256 allowed forged CA signatures
Of the eight intermediate CA certificates in which the problem was found, six are used for TLS connections to websites and the other two are for code signing. According to Mozilla's public investigation record, a reporter identified as Wayne presented signatures created with each private key, proving the keys could actually be recovered. The core of the problem is that the private keys of intermediate CAs were within reach of third parties.
In HTTPS, browsers and other clients normally verify a chain of signatures that starts from a trusted root CA and runs through an intermediate CA to the destination site's certificate. This is called a certificate chain, and it is used to judge whether a certificate was issued by a legitimate CA. If a third party obtains an intermediate CA's private key, however, they can impersonate that CA and sign new certificates. Unlike the theft of a single website's certificate, this could allow certificates that spoof any site to be issued, so the impact is far broader.
The problem was that the secret value used in P-384 elliptic curve cryptography was an integer below 256 in all eight cases. This value should be chosen at random from an extremely large range. The affected keys, however, were almost entirely zeros apart from the final byte, so they could be recovered easily by checking candidate values. A Mozilla representative also said they independently recovered the private key without knowing the method the reporter used. This means the P-384 algorithm itself was not broken; the flaw lay in the key generation process.
According to eMudhra's statement of October 21, the affected keys were created in a key generation procedure carried out on April 30, 2025. The company explained that, during the wrap/unwrap process used to protect and move keys securely, a weak key was generated separately from the intended strong key, and the weak one was exposed. Hardware security modules (HSMs) were used for key generation, but the detailed root cause has not yet been determined. It is therefore not possible to conclude that the HSM itself was defective.
eMudhra says that seven of the eight were not used in production, and that none, including the remaining one, had issued end-entity certificates to customers. It also says it is not aware of evidence that the private keys were recovered or abused before the problem was disclosed. However, this is a statement about the company's legitimate certificate issuance and the evidence of abuse confirmed so far. It must be distinguished from the technical risk that a third party could recover the weak private keys and create forged certificates; it has not been proven that no abuse occurred.
Chrome and Firefox blocked quickly; Android needed an additional fix
According to Mozilla's announcement of October 20, the company received the report at 20:06 UTC on October 17 and, by 22:59 that day, had finished distributing blocking information to Firefox users with default settings. The response used a mechanism called OneCRL, which is used to reject revoked certificates. OneCRL can distribute certificate blocking information without a browser update or restart. Here too, protection reached default-configuration Firefox within about three hours of the report.
On October 20, Mozilla also released Firefox 158.0.1 and the long-term support releases Firefox ESR 115.43.1 and ESR 153.5.1. These updates are intended to deliver protection to users who could not receive OneCRL blocking information because of custom settings or other reasons. On the 21st, Mozilla released Firefox 158.0.2 for Android as well, fixing an issue in which the bundled blocklist was not applied properly right after launch on some devices. This shows that what matters is not only whether blocking information was received, but also whether the browser actually applies it.
Meanwhile, according to Google's explanation of October 20, Chrome reflected a "CRLSet" update to block the affected keys at 19:45 UTC on October 17. CRLSet matches hashes of the Subject Public Key Info (SPKI) contained in certificates, so certificates that use the same public key can be rejected together. As a result, Chrome users were protected without updating or restarting the browser.
An equivalent update was distributed to Android devices and others through Google Play Services at around 22:00 UTC on October 19. Google said that most Android devices had received the update at the time of the announcement, and that restarting a device can prompt an immediate update. However, even if Chrome and the relevant Android certificate validation are protected by these measures, not every app on a device necessarily uses the same mechanism.
Certificate Transparency (CT) also plays an important role in assessing the impact. CT records issued TLS certificates in public logs, making fraudulent issuance easier to detect. According to Google, no TLS certificates chaining to the six affected intermediate CAs had been recorded in CT logs by the time the block was put in place. For that reason, Google says forged certificates issued from these intermediate CAs could not have been abused in clients that enforce CT requirements, such as Chrome. On the other hand, this protection does not automatically extend to apps that do not enforce CT, and the risk differs depending on how certificates are validated.
Block the flawed certificates, or remove the root certificate
Even if a CA revokes a certificate, that alone does not mean all software will reject it. The app doing the validation must check the latest revocation information and reflect the result properly. According to advice for software operators published by Mozilla's Dennis Jackson, eMudhra revoked the affected certificates on October 18, and Sectigo, which was involved in cross-signing, did so on the 19th.
Jackson explains that clients that reliably check the latest revocation information and enforce "fail-closed" behavior, rejecting the connection if the check cannot be completed, need no additional action. Clients that do not check revocation information, or that behave "fail-open" by allowing connections even when the check fails, need countermeasures. In other words, even when revocation has been completed on the CA side, dangerous certificates may still be accepted depending on how the software in use validates them.
One possible measure is to individually reject the certificates or public keys of the problematic intermediate CAs. This makes it easier to confine the impact to the problematic certificates. For software that has no mechanism for blocking individual intermediate CAs, however, removing the root certificate above them from the trust list is also an option. Legitimate intermediate CAs unrelated to this problem also exist under the same root CA, so removing the root certificate could make it impossible to connect to sites using certificates issued by those CAs.
Based on the companies' official announcements, the mechanisms of the countermeasures and what to check after updating are summarized below.
| Measure / target | Scope of blocking and update method | What to check after updating |
|---|---|---|
| Chrome CRLSet | Matches the affected Subject Public Key Info (SPKI) and blocks certificates using the same key | Chrome's protection does not necessarily apply to apps that use a different certificate validation mechanism |
| Firefox OneCRL and browser updates | Blocks the affected certificates, and delivers protection through browser updates to environments that cannot receive OneCRL | Also confirm the additional update to 158.0.2 on Android, and distinguish between receiving blocking information and actually applying it |
| NSS 3.131.1 and Chrome Root Store updates | Remove emSign ECC Root CA - G3 from the trust list |
Check whether destinations using legitimate certificates chaining to the same root need to migrate |
This table compares the measures announced by each company and is not the result of independent behavior testing. What matters is that the scope of impact differs between individually blocking the keys or certificates of intermediate CAs and removing the root certificate above them from the trust list. In addition, whether update information has reached an app, and which certificate validation mechanism that app actually uses, must be checked separately.
eMudhra says the private key of the root CA itself was not affected by this problem. Even so, Mozilla and Google are proceeding with removal of the root certificate in order to protect software that cannot block the dangerous intermediate CA keys individually. Mozilla has indicated that it will remove the root from its trust list in NSS 3.131.1, and Google has decided to remove it from the Chrome Root Store. The impact is broader than blocking only the problematic intermediate CAs, but it also serves as a countermeasure for clients that cannot use individual blocking information.
Per-app certificate validation and site-side certificate migration are needed
In response to the problem, Cloudflare is asking developers to check which mechanism their apps actually use to validate TLS certificates. According to the company's technical explanation of October 20, apps that connect to external APIs and the like may delegate certificate validation to a variety of mechanisms, including HTTP libraries, language runtimes, the OS, and custom trust configurations. Updating only the SDK an app uses therefore does not necessarily change the settings or behavior of the mechanism that actually validates certificates.
For example, even if the OS trust store is updated to reject the affected certificates, that change may not take effect if an app bundles its own certificate store. Cloudflare updated the shared trust stores and base images it uses, and individually assessed apps with their own trust stores and applied the necessary measures. It also combined reloads, restarts, and image redeployment to reflect the updates in running environments. For cloudflared, used with Cloudflare Tunnel, it advised updating to version 2026.10.2 and asked that fixed images be redeployed in container environments.
Verification after updating also needs to be done on the TLS validation path the app actually uses. Cloudflare points out that even if a problem is resolved in a browser on the same machine, services running in the background are not necessarily protected. Likewise, if validation succeeds with curl but the app in question uses a different certificate validation mechanism, that result cannot be used as proof that the app is safe. If certificate validation starts to fail, validation must not be disabled to restore connectivity. Disabling validation would destroy the very authentication of the destination that this update is meant to restore.
Website operators, meanwhile, need to act to avoid situations in which removal of the root certificate makes legitimate connections impossible. In its October 20 announcement, Google said that for all devices that rely on the Chrome Root Store, it plans to apply the removal of emSign ECC Root CA - G3 on the morning of October 27 (Pacific Daylight Time, PDT). In early-release versions such as Chrome Canary and Chrome Beta, the change will be applied even earlier. Google urges operators of sites using TLS certificates chaining to that root to promptly obtain and deploy certificates from another trusted CA included in the Chrome Root Store.
In an additional announcement on October 22, eMudhra also said it would offer customers certificates issued by Sectigo as an alternative. Even sites that do not use certificates issued by the problematic intermediate CAs may need to migrate to avoid losing connectivity if they use legitimate certificates chaining to the root CA slated for removal. In other words, the response is not complete once dangerous certificates are rejected; it also includes migrating certificates so that necessary connections are maintained.
On the user side, apps, their dependent libraries, and certificate stores need to be updated so that the flawed keys are reliably rejected. At the same time, site operators need to migrate certificates as necessary so that legitimate connections are not lost through removal of the root certificate. Ahead of the Chrome Root Store change scheduled for October 27, a key condition for judging the response complete is whether both sides have checked their certificate validation paths in actual production environments and are achieving both the blocking of dangerous certificates and the maintenance of legitimate connections.