A trusted internet authority had keys anyone could guess.

eMudhra is an India-based certificate authority. On 17 October 2026, a security researcher reported that the private keys behind eight of its intermediate certificates were weak. Mozilla's Firefox Security Team says the keys "had been compromised". eMudhra's own statement uses the word "weak". Either way, the practical result is the same: anyone could work out the keys.

How weak? Security researcher Scott Helme, who published an analysis on 20 October, wrote: "One of eMudhra's certificate authority private keys is the number 4." He also said he recovered all eight from the public certificates "on my laptop just now, and it took less than a second." A secret key is meant to be one number out of a space too large to search. These were tiny numbers.

eMudhra says the problem came from an April 2025 key-generation ceremony, that it went undetected for about 18 months, and that the exact root cause is still being investigated. Its statement says: "We acknowledge this incident and take full responsibility for it."

When you visit a site over HTTPS, your browser needs to know it is talking to the real site and not an impostor. It relies on certificates, small signed files that say "this key belongs to this website". A certificate authority (CA) is the organization that signs them. Browser makers and operating system vendors decide which CAs to trust. Mozilla, for example, runs a public program that governs which roots go into its trust store.

Trust works as a chain. A root certificate sits in your browser. It signs intermediate certificates, and the intermediates sign the certificates that sit on websites. Whoever holds an intermediate's private key can sign certificates that look valid for any website, including one they do not own.

That is the danger here. Mozilla explains that attackers holding the keys could issue fake HTTPS certificates for sites they do not control, letting them impersonate those sites and possibly read or alter traffic during an interception. Cloudflare puts it the same way: "Because the keys themselves are weak, an attacker can create a forged certificate for any domain."

Times are as published by the organizations involved. We found no primary statements from Apple or Microsoft, so we do not give dates for their actions.

1. 17 OctoberA researcher reports the issue. Chrome's root program receives the report at 18:05 UTC and, by 19:45 UTC, ships a block to Chrome users that needs no update or restart. Mozilla also receives the report and blocks the certificates through Firefox's revocation list, which reached standard installs within about three hours.
2. 18 OctobereMudhra revokes all eight intermediate certificates.
3. 19 OctoberAndroid devices receive an equivalent block through a Google Play Services update.
4. 20 OctoberMozilla and Cloudflare publish their write-ups. Mozilla removes the root from its trust store and ships Firefox and NSS updates. eMudhra posts its first statement.
5. 22 OctobereMudhra offers certificates issued by Sectigo, another authority, as an alternative for all customers.
6. 27 October (expected)Google expects to remove the emSign ECC Root CA G3 root from the Chrome Root Store for devices that rely on it. Some legitimate certificates under that root will stop working then.

What is confirmed

• No confirmed misuse. eMudhra says it is "not aware of any evidence that the weak keys were recovered or exploited". Cloudflare says its security review "has not identified active exploitation of this issue on Cloudflare services".
• Certificate Transparency saw nothing. Chrome says no certificates chaining to these intermediates were logged to Certificate Transparency before the block. Certificate Transparency is a public log of issued certificates, and Chrome requires it, so a forged certificate that skipped the logs would be rejected by Chrome.
• Browsers are covered. Standard Chrome and Firefox installs received the block automatically.
• Scope. eMudhra says the impact is limited to TLS certificates chaining to the distrusted ECC root, and that one US customer ecosystem is affected. None of the statements we read describes customer data being taken.

What is not settled

• The root cause. eMudhra has not confirmed it.
• The numbers. eMudhra's page speaks of eight affected certificates. Chrome's own post refers to eight in one place and six in another without explaining the difference, so we avoid quoting a single count of affected certificates.
• "No evidence" is not "no attack". Helme points out the keys were effectively public for a long time. The checks that exist, revocation and Certificate Transparency, are strong in browsers and weaker elsewhere.

Where the gap is: software that is not a browser

Helme warns that many non-browser clients, such as command-line tools, programming-language libraries and package managers, may trust these certificates without checking revocation or Certificate Transparency. For them, an attacker "on the network path" is enough, and devices that cannot update their trust list stay exposed. Helme's advice is blunt: "Update everything that ships a CA bundle". He also reports that "a simple prompt in an AI agent allowed me to recover the private keys of the CA", which shows how little effort a check like this now takes. Our guide to the AI-agent campaign against 1,200 websites shows the same trend from the attacker side.

• Update browsers and operating systemsKeep Chrome, Firefox, Android and your computers current. Firefox shipped 158.0.1 and 158.0.2 for Android, and Mozilla also updated its NSS library.
• Find your certificate issuerOpen your site, click the padlock, open the certificate details and read the issuer and chain. Developers can run openssl s_client -connect yourdomain.com:443 -showcerts to see the whole chain. Look for eMudhra, emSign or a Sectigo cross-sign.
• Replace any certificate that chains to emSign ECC Root CA G3Chrome tells site owners to get a new certificate from another authority now, before the root is removed. eMudhra offers Sectigo-issued certificates as an option, and you can choose any other trusted authority.
• Update CA bundles in your softwareUpdate the trust lists in your apps, containers and servers, then rebuild and redeploy. Cloudflare notes that a fix in an SDK may not reach the library that actually checks certificates.
• Test the real pathCheck the trust store your background services use. A browser test may not reflect what a server-side job uses.
• Never disable verificationKeep certificate checks on in every environment, including testing and automation.
• Know what you depend onList every certificate you use and where it lives. If you can swap an authority in hours instead of days, an incident like this stays minor. This part is our advice, not part of the vendors' guidance.

The wider lesson is small and practical: trust on the internet rests on a few organizations getting very ordinary steps right. When one slips, the fix depends on how quickly you can see your own dependencies. Related reading: six cheap habits that block the attacks small businesses actually face, and the longer-term cryptography question in harvest now, decrypt later.