The eMudhra certificate vulnerability concerns eight private keys of intermediate certification authorities made recoverable by a generation flaw in 2025. Chrome and Firefox blocked the six TLS keys in October 2026, but applications, containers, SDKs, and devices using their own trust store must be tested separately. An accepted certificate chain can enable the validation of a fake certificate.
What happened with the eMudhra certificates?
The eMudhra certificate vulnerability stems from eight intermediate authority keys created on April 30, 2025, with insufficient entropy—that is, too little randomness. On October 17, 2026, a researcher demonstrated control of all eight private keys. Mozilla independently recovered one, confirming that exploitation was technically trivial.
An intermediate certification authority is a digital entity authorized by a root authority to sign other certificates. Six compromised keys were used for the TLS protocol, which encrypts HTTPS connections, among other things, and two were used for code signing.
According to CERT-In, the affected P-384 private values were integers smaller than 256. They could therefore be recovered almost instantly from the public keys, whereas a properly generated elliptic key must be impractical to guess.
eMudhra explained on October 21, 2026, that a “wrap/unwrap” script step had created a second set of weak keys, and that similar labels then led to these keys being used in certificate signing requests. As of October 26, 2026, the root-cause investigation was still reported as ongoing. This is therefore the explanation published by the company, not yet an independent final report.
What risk does the eMudhra certificate vulnerability create?
Possession of a compromised intermediate TLS key made it possible to sign fake certificates for any domain, provided that the client continued to trust the eMudhra chain and did not enforce Certificate Transparency. An attacker also had to intercept or divert the connection to present the forged certificate to the target.
Certificate Transparency est un système de journaux publics qui rend contrôlable l’émission des certificats du Web. Google a indiqué le 20 octobre 2026 n’avoir trouvé, avant son blocage, aucun certificat TLS lié aux six intermédiaires compromis dans ces journaux. Ce constat écarte leur usage contre les clients qui imposaient ce contrôle, mais pas contre les clients sans contrôle CT.
eMudhra stated on October 21, 2026, that seven intermediates had never been deployed and that the eighth had issued no end-entity certificates. The company also said it had found no evidence of malicious recovery of the keys before their disclosure. Absence of evidence does not mean evidence of absence, but claiming that an attack occurred would be inaccurate.
The trap for a decision-maker is confusing a compromised certificate with a hacked site. The eMudhra certificate vulnerability affects the trust mechanism: it can facilitate impersonation of a service to certain clients without demonstrating an intrusion into the server, database, or hosting account.
Do Chrome and Firefox already protect your company?
Chrome blocked the six TLS keys through CRLSet on October 17, 2026, at 7:45 p.m. UTC, and Firefox completed its OneCRL rollout at 10:59 p.m. UTC. According to Mozilla, these revocation mechanisms were applied without a restart or a full browser update in standard configurations.
Mozilla subsequently released Firefox 158.0.1, Firefox ESR 115.43.1, Firefox ESR 153.5.1, and NSS 3.131.1 on October 20, 2026. NSS, Mozilla’s security library, removed the root emSign ECC Root CA - G3 for software that uses the Mozilla store without receiving OneCRL. Firefox for Android 158.0.2 followed on October 21, 2026.
Google scheduled the removal of this same root on October 27, 2026, from stable devices using Chrome Root Store, notably to extend protection to clients that do not receive CRLSet. The difference between Chrome and Firefox versions is a reminder that a browser-delivered feature or protection never applies uniformly across an entire fleet.
Here is the operational difference between the main environments affected in 2026.
| Environment | Measure published in 2026 | Verification to perform |
|---|---|---|
| Standard Chrome | CRLSet blocking on October 17 | Check policy receipt and the Chrome Root Store |
| Standard Firefox | OneCRL blocking on October 17, corrected versions on October 20 | Check the version and OneCRL application |
| Application using NSS | Root removal in NSS 3.131.1 on October 20 | Identify and update the embedded NSS version |
| Container, SDK, or Electron application | No universal protection | Test the TLS engine and the authority file actually loaded |
| Embedded device | Depends on the manufacturer and firmware | Test the device, then request a fix from the supplier |
How can you check whether a site or application remains exposed?
Verification of the eMudhra certificate vulnerability must inventory server and client chains containing EM DV/OV/EV TLS CA - G3B, EM DV/OV/EV TLS CA - G3C, their counterparts cross-signed by Sectigo or emSign ECC Root CA - G3. Each test must use the TLS engine and authority store of the actual application.
Opening the site in your personal browser is not enough. An API may work in Chrome while remaining vulnerable from an older Linux container, an Electron application, a payment terminal, or a mobile SDK that embeds its own list of authorities. This is the same kind of environment gap as during the correction of a vulnerability on NAS and Docker.
A usable inventory follows five steps:
- recenser les domaines, API, applications mobiles, conteneurs, automates, VPN et équipements qui ouvrent des connexions TLS ;
- extract the chain presented by each server and search for the relevant eMudhra names, including the copies co-signed by Sectigo;
- identify, on the client side, the TLS library and trust store actually in use;
- tester les connexions avec la configuration exacte de production, puis consigner les connexions acceptées et refusées ;
- prepare to replace legitimate certificates that depend on the removed root before removing it from the fleet.
The independent checker published on October 22, 2026, notably proposes the command curl https://dv-g3b-emudhra.we-have-a-problem.com/. A successful connection indicates that the tested client has accepted the presented chain as trusted. Endpoints without Certificate Transparency and downloadable PEM chains also enable offline validations with OpenSSL.
In the projects we lead, we often see the audit stop at the certificate presented by the public server. The right approach is also to test API consumers: scheduled tasks, mobile applications, Docker images, and business software. Secret management must be examined separately, as illustrated by the securing of API keys after an incident.
Should the eMudhra root be removed immediately?
Removing emSign ECC Root CA - G3 it blocks chains that depend on this root, but it can also interrupt legitimate connections. Google confirmed this risk on October 22, 2026. The operators concerned must first obtain and deploy a certificate linked to another trust hierarchy, then remove the old chain.
Mozilla estimated in Bugzilla on October 21, 2026, that approximately 30,800 unexpired precertificates were linked to the removed G3 root, mainly through two Internet2/InCommon subordinate authorities. These legitimate certificates did not originate from the eight weak intermediates. They illustrate the potential collateral cost of distrusting the entire root.
eMudhra revoked the eight intermediates on October 18, 2026, with the reason caCompromise. The copies co-signed by Sectigo used the same compromised public keys; changing only the certification path therefore does not correct the problem.
On October 22, 2026, eMudhra’s board of directors decided to exit the global SSL/TLS certificate market. The company announced replacement certificates during the transition and the continuation of status services until the issued certificates expire or are replaced. Honestly, maintaining a long-term dependency on this hierarchy is not justified when reissuance through an approved trusted authority is possible.
What action plan can be applied without causing an outage?
Addressing the eMudhra certificate flaw requires separating the client emergency from the server migration. First, the compromised authorities must be blocked in each vulnerable environment, then legitimate certificates must be reissued before removing the G3 root. A gradual deployment with monitoring prevents a security correction from taking down a business API.
From the agency’s perspective, the first step is to create a matrix of “service, client, TLS engine, trust store, owner.” This simple document reveals overlooked dependencies and makes it possible to assign each correction. Without an identified owner, old containers and embedded devices frequently remain outside the scope of the plan.
Plan a rollback for every change, but not a lasting rollback to the compromised trust. On a server, deploy the new chain first and verify it from all representative clients. Across a client fleet, update the trust store or library, check the TLS error logs, then remove the temporary exceptions.
Framing the verification of chains, TLS libraries, and replacement certificates avoids most unexpected outages. An outside perspective can be especially helpful when an application depends on multiple providers, container images, or devices whose entire chain no one person fully manages.
FAQ about the eMudhra incident
Does an HTTPS padlock prove that my certificate is secure?
The HTTPS padlock indicates that a browser has accepted the connection and its certificate. The padlock does not prove that another client, using a different trust store, correctly blocks compromised eMudhra keys.
Which eMudhra certificate names should you look for?
The checks should look for EM DV/OV/EV TLS CA - G3B, EM DV/OV/EV TLS CA - G3C, their copies co-signed by Sectigo, and the root emSign ECC Root CA - G3.
Does updating the browser protect an Electron application?
An update to Chrome or Firefox does not guarantee the protection of an Electron application. The Electron application may bundle its own runtime, TLS library, or separate certificate store, which must be tested and updated.
Is there any evidence of malicious exploitation of the keys?
No malicious exploitation had been confirmed in the information published as of October 27, 2026. eMudhra said it had found no evidence predating the disclosure, while independent key recovery demonstrated that the attack was technically easy.