eMudhra CA keys broken: DSC and eSign safe, TLS and code signing not

Eight intermediate certificates from eMudhra, the Indian certificate authority, had private keys so weak that anyone could work them out from the public certificate. CERT-In's advisory CIAD-2026-0050 says each P-384 key had a value smaller than 256, so it could be recovered almost instantly. Scott Helme, who recovered the keys, wrote that one of them "is the number 4," Help Net Security reports. Six of the certificates can issue TLS certificates for websites and two are for code signing. Cloudflare says anyone with the keys could forge a certificate for any domain, and CERT-In warns the code-signing keys could make malware look signed by a trusted publisher.

For Indian companies the first question is whether the DSC on a director's token or the eSign flow in an HR or loan app is affected. CERT-In says no: the problem is limited to eMudhra's internationally trusted business, and the DSC and eSign services regulated by the Controller of Certifying Authorities are not impacted. eMudhra says the same, and adds emSigner, CertiNext and its other products to the unaffected list.

What is affected

The keys were made at a key ceremony on April 30, 2025, and went unnoticed for about a year and a half. eMudhra blames one step of that ceremony, where keys were wrapped and unwrapped. It created an extra set of weak keys alongside the good ones, and the weak set is what went into browser trust stores. It says it has "not yet confirmed the exact root cause."

A researcher known as Wayne found the flaw on October 17. Mozilla and Google blocked the six TLS intermediates that day, Apple followed on October 19 and Microsoft on October 20, per Help Net Security. CERT-In says eMudhra revoked all eight on October 18. eMudhra's own statement gives October 19.

The bigger change for customers is the root. All eight chain to emSign ECC Root CA - G3. Mozilla has removed that root in NSS 3.131.1, and CERT-In says Google's removal from the Chrome Root Store is expected to reach devices on October 27. CERT-In warns that legitimate certificates under that root could then stop being trusted, which can break websites and services. eMudhra has stopped issuing under its G3 root.

How many customers must swap certificates is not settled. Help Net Security puts eMudhra's own estimate at about 30,000 customer certificates to replace. eMudhra's own statement says the root distrust affects "one customer ecosystem in the United States" and gives no number.

Was it exploited?

eMudhra says seven of the eight intermediates were never used in production and none issued certificates. Google found no TLS certificates chaining to the six TLS intermediates in Certificate Transparency logs before it blocked them, CERT-In says. Cloudflare found no active exploitation on its services, and Talos had seen no malicious use. Government sources told The Federal the impact on Indian services was "very limited," and MeitY has set up a team to investigate.

Where the risk is left

Browsers are covered. The gap is software that carries its own list of trusted roots or does not check revocation. BleepingComputer names macOS /usr/bin/curl as one example and lists fixes: Go 1.27.3 and 1.26.10, Python certifi 2026.10.19, Alpine ca-certificates 20261020-r0. Debian's ca-certificates and Node.js were still pending. Cloudflare's cloudflared needs 2026.10.2, and container deployments need the new image. Talos adds VPN clients, proxies, build runners and industrial IoT devices.

Cloudflare's warning for any team hitting certificate errors: do not "resolve these errors by disabling verification."

Related: PHP2Shell: how to patch by where your PHP comes from and the BeyondTrust Remote Support zero-day.