On Saturday, October 17, 2026, at 18:05 UTC, the Chrome Root Program received a report from a security researcher who identifies only as "Wayne": eight intermediate certificates from an Indian certification authority, eMudhra (operating under the emSign brand), had private keys generated with such weak cryptographic entropy that anyone could recover them by testing only 256 possible values.
Instead of simply reporting the issue to vendors, the researcher did what everyone would do: signed a test message with each of the eight compromised keys and sent the proofs directly to the security teams at Mozilla, Microsoft, Apple, and Google. The result was a weekend response that forced emergency updates across the world's entire software base.
What went wrong
eMudhra is a trust certification authority that issues TLS certificates for thousands of websites, governments, and financial services in India and other emerging markets. The problem traces back to April 2025, when a defective script generated a second set of P-384 private keys that were significantly weaker. By mistake, these weak keys were selected for certificate signing because they had visually similar labels to the correctly generated keys.
The result was catastrophic. All eight keys had values smaller than 2⁵⁶ — or roughly less than 72 quadrillion — which, in practical terms, means anyone with access to a modern home computer can test all possible values in minutes. The researcher Flüpke published one of the compromised keys on GitHub: the private key value for eMudhra's "EM OV TLS CA – G3C" certificate was simply the number 4.
Why intermediate certificates are worse than leaf certificates
Losing a leaf certificate key — the kind a site like google.com or your bank uses — is a local problem. The domain administrator generates a new key pair, requests a replacement, and the old certificate expires or is revoked. It's simple.
An intermediate certificate is different. Intermediaries exist to keep root keys offline and protected in hardware security modules (HSM). The root delegates signing authority to the intermediary, which issues certificates to the public. An attacker who controls an intermediary's private key inherits all the trust placed in that branch of the hierarchy. They can mint valid TLS certificates for any domain and skip domain validation checks that legitimate CAs enforce.
Moreover, these intermediate certificates were cross-signed by Sectigo's AAA Certificate Services — meaning a client could build a valid trust chain that passed through a different root. If a browser rejected only the eMudhra root, an attacker could still present a chain running through Sectigo.
Browser response
Mozilla reacted quickly. It received the report at 20:06 UTC on October 17 and pushed a blocklist update through Firefox's OneCRL system on its Remote Settings infrastructure by 22:59 UTC. This forces Firefox to reject the specific certificates regardless of their cryptographic validity or expiration date.
Google Chrome also blocked the six compromised intermediaries authorized to issue certificates that day, through a CRLSet update. Because this update blocks by SPKI (Subject Public Key Info), Chrome users were immediately protected against all certificates sharing those keys, without requiring a browser update or reboot.
Apple added protections on October 19, and Android received an equivalent update through Google Play Services.
The hidden problem: the long tail of embedded software
Here is the part nobody tells you about in the reports: browsers can push emergency blocklists to hundreds of millions of users within hours. The rest of the internet is much slower and more fragmented.
On October 19, the Go team released emergency security updates, versions 1.27.3 and 1.26.10, assigned CVE-2026-111943. Unlike a web browser that relies on the host operating system's certificate store, Go's standard `crypto/x509` library implements its own certificate verification logic and bundles its own trust verification mechanisms.
This creates real work for enterprises. If a backend microservice was compiled with an older version of Go, updating the toolchain on the host does nothing for the running binary, which already contains the old verification logic. Securing the environment means finding every compiled Go binary, updating the build pipeline, recompiling against the patched toolchain, and redeploying to production.
An administrator can patch every Windows and macOS workstation and still have dozens of internal API clients, CI/CD pipeline runners, and containerized applications that never saw Mozilla's OneCRL updates or Apple's. In those environments, a successful TLS handshake only shows that the client accepted the certificate under its outdated validation rules. It says nothing about whether the connection is secure.
What eMudhra needs to prove now
Certificate Authorities are expected to maintain separation of duties, multi-person authorization, and heavily audited hardware security modules. Eight intermediary keys compromised at the same time points to a systemic failure, not an isolated accident.
The company attributed the problem to a script error, but that raises questions that need answering: why did the script generate keys so weak? Why were weak keys with similar labels selected over the correct ones? Why didn't entropy validation block this operation?
eMudhra has already revoked the eight compromised certificates and suspended issuing new certificates under its G3 root. The company has committed to working with impacted subscribers to migrate customers off the affected root, emSign ECC Root CA - G3.
The web's entire trust system depends on the premise that each CA is impenetrable. With eight keys broken by a defective script, that premise seems more like a hope than a guarantee — and leaves one question unanswered: how many other CAs in the world still operate with equivalent flaws, waiting for someone to discover them?
Sources: BleepingComputer, Google Security Blog, The CyberSec Guru
✓ Independent sources cross-checked and verified before publishing
