On October 17, 2026, a security researcher reported that the private keys of eight intermediate certificate authority certificates operated by India’s eMudhra had effectively been compromised. The keys were so poorly generated that anyone could recover them in seconds, and whoever holds them can issue browser-trusted HTTPS certificates for any website on the internet. Within less than two hours, Google Chrome had pushed an emergency block. Mozilla’s Firefox followed the same evening; Apple and Microsoft acted within days.
The short version: eight eMudhra (emSign brand) intermediate CA keys — six for TLS and two for code signing — were generated with crippled randomness during a key ceremony in April 2025 and can be recovered almost instantly. The browsers have blocked the affected certificates, eMudhra has revoked them, and Chrome will remove the emSign ECC Root CA – G3 root from its trust store on the morning of October 27, 2026. No real-world exploitation has been reported, but servers and software outside the browser world still need manual trust-store updates.
How the compromise was discovered
The report landed on Saturday, October 17, 2026, at 18:05 UTC. A researcher identified only as “Wayne” contacted the Chrome Root Program with an extraordinary proof: he had signed the message “We have a problem here – Wayne” with each of the eight private keys, demonstrating control of all of them. Mozilla received its own report at 20:06 UTC and independently recovered the keys that same evening.
What makes this case unusual is that nobody had to break in. There was no breach of eMudhra’s infrastructure, no malware, no stolen password. The keys were simply generated so weakly that reverse-engineering them was trivial — the security failure was baked in from the moment of creation.
The key-generation failure that made recovery trivial
According to Mozilla’s investigation, documented by Mozilla’s Dennis Jackson in the Bugzilla incident report, the affected P-384 private keys — created during a key ceremony on April 30, 2025 — “all used integers less than 256.” In plain terms, instead of containing securely randomized values across the curve’s full range, each key was effectively zero except for its final byte. That collapses the search space to a few hundred candidates, which a computer can enumerate almost instantly.
eMudhra’s preliminary explanation points to a key ceremony script involving a wrap/unwrap test. The company said it had initially generated legitimate keys, but a flaw in the test code produced a second set of weaker keys — and because the key labels were similar, the weaker keys were mistakenly selected for the certificate signing requests. This is an important distinction: the cryptography itself was not broken, and there is no evidence of an intrusion. The keys were just catastrophically weak from birth.
Which certificates are affected
The eight compromised intermediates break down as follows: six TLS intermediates covering domain-validated, organization-validated, and extended-validation certificates (across eMudhra’s G3B and G3C issuance lines for its European and US operations), plus two organization-validated code-signing intermediates. They chain under emSign Root TLS CA-G3 up to emSign ECC Root CA-G3 — a root present in the Chrome, Apple, and Mozilla trust stores. Cross-signed variants of the compromised intermediates also exist under Sectigo’s AAA Certificate Services; Sectigo has since confirmed revocation of those cross-signs.
One mitigating fact from eMudhra: the company says only one of the eight intermediates was ever fielded in production, and none of them had issued end-entity certificates to customers. That limits the blast radius, but anyone holding the recovered keys could still mint new certificates chaining to a widely trusted root — which is exactly why the browsers moved so fast.
How browsers and vendors responded
The response timeline shows how seriously the industry treats a CA key compromise:
- October 17, 18:05 UTC — Researcher “Wayne” reports the compromised keys to the Chrome Root Program.
- October 17, 19:45 UTC — Chrome ships a CRLSet update blocking the six TLS intermediates, one hour and forty minutes after the report.
- October 17, 22:59 UTC — Firefox completes its OneCRL block for all eight intermediates, under three hours after Mozilla received the report.
- October 18 — eMudhra revokes the eight certificates; Sectigo revokes the affected cross-signed certificates.
- October 19 — Apple blocks the certificates; Android devices and Chromebooks receive the block via Google Play Services.
- October 20 — Microsoft blocks the certificates; Firefox 158.0.1, Firefox ESR releases, NSS 3.131.1 and Go fixes ship; Cloudflare completes its mitigations; Google and Mozilla publish their incident disclosures.
- October 21 — Node.js ships security releases (22.23.4, 24.22.1, 26.12.1) that reject TLS chains containing the blocked keys.
- October 27 (morning, PDT) — Chrome removes the emSign ECC Root CA – G3 root from the Chrome Root Store entirely. Google notes that “some legitimate certificates chaining to this root will cease to function in Chrome as a result.”
Mozilla is likewise removing the signing root from NSS, its certificate library, which protects the many applications that rely on Mozilla’s trust store.
This is not the only certificate scare of recent weeks — earlier in October, attackers issued 12 unauthorized certificates for Google and YouTube domains by compromising country-code registries, a story we covered in detail — but a CA’s own keys being recoverable by anyone is a more fundamental failure. Read our earlier breakdown of that incident: Google Certificate Hijack Explained: How Attackers Issued 12 Unauthorized Certificates for Google and YouTube Domains.
Has anyone been attacked?
So far, no. In its October 21 update, eMudhra said it is “not aware of any evidence that the weak keys were recovered or exploited by anyone before the issue was disclosed.” Certificate Transparency logs show no entries for these intermediates since they were created in April 2025, which means browsers that enforce Certificate Transparency could not have been attacked through forged certificates.
There is a caveat, though. Many clients outside the browser ecosystem do not enforce Certificate Transparency — background services, IoT devices, internal tools, and older software may trust the compromised chains without the browser-level protections. Those environments are exactly where a forged certificate would do the most damage, silently impersonating a server to intercept or modify traffic.
What to do now
For everyone: make sure your browsers and operating systems are fully updated — the protections ship through normal updates, but only if they are installed. Chrome, Firefox, Edge, and Safari users are covered once updates land; Firefox users on standard configurations received the block automatically within hours of the report. Keeping your browser current is always worth doing; our recent roundup of the latest fixes is here: Chrome 155 and Firefox 158 Security Update: 114 Flaws Fixed as Mozilla Launches Firefox Enterprise.
For website owners and hosting providers: check whether any certificate you run chains to emSign ECC Root CA – G3. If it does, replace it with a chain from another widely trusted root before October 27, when Chrome’s root removal will cause those certificates to stop working in Chrome. Google has published guidance on the replacement chain.
For system administrators and developers: update trust stores in servers, containers, and applications that do not consume browser revocation feeds. That means deploying NSS 3.131.1 or newer for software using Mozilla’s trust store, patching OS CA bundles (Ubuntu has published updates), rebuilding container images so headless tools stop trusting the compromised chains, and installing the Node.js October 21 security releases if you run Node in production. Cloudflare has completed mitigations on its side, but the rule of thumb stands: test non-browser services through their actual TLS path, and do not assume a browser test covers background processes.
Emergency patching has been the theme of this week — the same day browsers moved on eMudhra, PHP administrators were racing to install fixes for two critical remote code execution flaws — and the lesson is the same in both cases: when the vendor ships the fix, install it the same day. Our coverage of that story: PHP2Shell Explained: Two Critical PHP RCE Flaws (CVE-2026-109618, CVE-2026-109619).
Frequently asked questions
What is eMudhra, and what does it do?
eMudhra is a Bengaluru, India-based digital security company that operates a publicly trusted certificate authority under the emSign brand, alongside its European and US operations. Like other public CAs, its certificates are trusted by default in major browsers and operating systems, which is what makes a key compromise so consequential.
Can an attacker really create certificates for any website with these keys?
Yes — in principle. With a compromised intermediate CA key, an attacker can issue certificates for any domain that chain up to a trusted root, and browsers would accept them as legitimate. That enables impersonating websites and intercepting or modifying encrypted traffic, provided the attacker can also position themselves on the network path. This is why every major browser vendor pushed emergency blocks within days.
Should I avoid websites that use eMudhra certificates?
No special action is needed for ordinary browsing. Chrome, Firefox, Safari, and Edge have blocked or distrusted the compromised certificates through updates, and eMudhra revoked them. As long as your browser is up to date, the protections are automatic.
What happens on October 27, 2026?
Chrome will remove the emSign ECC Root CA – G3 root certificate from the Chrome Root Store. Any remaining legitimate certificates chaining to that root will stop working in Chrome. Google says this step is aimed at protecting consumers of the Chrome Root Store that do not process revocation updates. If you operate a site on an eMudhra chain, migrate to another CA’s chain before that date.
How do I check whether my site uses an affected certificate?
Inspect your site’s certificate chain in your browser’s developer tools or with a command-line tool, and look for any issuer chaining up to emSign ECC Root CA – G3. If it does, reissue your certificate from a different certificate authority and deploy the new chain before October 27.
Was any customer data stolen in this incident?
There is no indication of data theft. This was a key-generation defect, not a network intrusion, and eMudhra reports no evidence that the weak keys were recovered or exploited by anyone before disclosure. The incident is about the potential to forge trusted certificates, which the industry moved to eliminate before it could be used.