Why Eight Weak eMudhra Keys Still Matter for Go, Node.js and Container Trust Stores
eMudhra's weak intermediate keys call for Go, Node.js, container and trust-store checks now, plus a chain check before Chrome's 27 October root removal.
Eight intermediate certificate authority keys from eMudhra, an Indian certificate authority, were weak enough that their private halves could be worked out from the public certificates. An intermediate certificate signs the certificates that websites present, so whoever holds its key could issue certificates that browsers accept. A security researcher reported the problem to the browser root programs on 17 October, and Chrome and Firefox blocked the affected intermediates the same day.
The browser fix came first. For an engineering team the work is a list of libraries, runtimes, container images and servers, each of which decides what to trust on its own schedule. Chrome's removal of the parent root, emSign ECC Root CA - G3, is expected to reach devices on 27 October, Pacific time. Between the browser block and that date, the remaining exposure sits in software that keeps its own list of trusted roots.
The fixes that are already out
Go 1.27.3 and Go 1.26.10 are among the fixes already out. The Go security announcement says the release filters out certificate chains that contain the blocked intermediates, and it lists CVE-2026-111943. The same report says binaries must be rebuilt, that the filter cannot be disabled, and that Go 1.25 and older get no fix. The announcement does not state any of these points, so teams should confirm them in the release notes.
Libraries that ship their own root lists come next. The Hacker News reports that Python's certifi 2026.10.19 and Rust's webpki-roots 1.0.10 drop emSign ECC Root CA - G3 from their bundles. It reports that Homebrew's ca-certificates 2026-09-25_1 excludes emSign ECC Root CA - G3, emSign Root TLS CA - G3 and AAA Certificate Services, and that Composer's ca-bundle 1.6.0 and 1.4.16 distrust the eight compromised intermediates. A project that pins an older version keeps its old root list until it upgrades.
Operating-system packages follow the same pattern. The community tracker maintained by Dennis Jackson lists fixed versions for Linux distribution CA packages, the curl CA bundle, pip, uv, Electron, Bun and several other packages, and some of those entries are still pending. Teams should check their own package versions against that list rather than assume an update has reached them.
On the client side, Mozilla's post confirms Firefox 158.0.1 and the ESR releases 115.43.1 and 153.5.1. Mozilla also says its NSS update protects other applications that use its trust store and do not receive the OneCRL block. Cloudflare's post lists updated WARP and 1.1.1.1 clients and cloudflared 2026.10.2. Chrome's block reached devices through a CRLSet update, without a browser update or restart.
Node.js is the open item
Node.js has merged a fix, but it has not reached a release. A pull request titled to reject chains containing blocked public keys was merged into the main branch on 20 October. It adds a built-in list of key hashes for the eight eMudhra intermediates and rejects any chain that contains one. It does not remove any root.
Because the list is compiled into the runtime, a team gets the block when it runs a Node.js build that contains the change. The pull request says the change needs backporting to every active release line. The Hacker News reports that no Node.js fix has been released yet. Until a patched version ships, a team running Node in production should treat its runtime as unpatched and check it with the steps below.
Containers and self-run servers need their own updates
Cloudflare's post says customers running containers should review their images and their application dependencies, and rebuild affected images. Its post also describes an alternative for Cloudflare Containers users: enabling HTTPS egress interception moves remote-server certificate validation to Cloudflare-managed infrastructure, and containers with that setting are already protected.
Self-run servers that use mutual TLS have the same gap. Cloudflare says those customers should update the trust stores or uploaded CAs that verify client certificates. Applications with bundled or custom trust stores need a separate assessment.
Cloudflare also warns against clearing a certificate error by turning off verification. A successful browser test does not prove that a background service is protected. Teams should test each service through the same TLS path it uses in production.
“A successful browser test does not prove that a background service is protected.”
How to check whether a certificate chains to the removed root
Google's post says website operators with certificates chaining to emSign ECC Root CA - G3 must immediately acquire and install a new TLS certificate from another PKI hierarchy included in the Chrome Root Store.
Six of the eight intermediates are the ones used for websites. A chain that runs through any of them is affected by the block, even before the root removal.
The tracker gives a client test. Running curl against the test hosts dv-g3b-emudhra.we-have-a-problem.com and dv-g3b-aaa-emudhra.we-have-a-problem.com shows whether a client trusts the compromised intermediates; the page says a certificate error means it does not. The same page advises against manual distrust steps for ordinary users, which it describes as workarounds for certain operating systems.
Questions for the certificate provider and host
Google's post says eMudhra has committed to working with affected subscribers to migrate customers off the impacted root. A team that buys certificates from eMudhra should ask which hierarchy its current certificate uses and when the replacement will be issued.
Teams should also ask their hosting provider or CDN whether origin or client certificate checks have changed, and whether it will warn them about certificates that will stop working. Cloudflare says it is updating its Automatic SSL/TLS handling to notify customers who still use the distrusted certificates, because those certificates would otherwise cause breakages.
Google's post does not say whether any clients were exposed before the 17 October block. It says no TLS certificates chaining to the six intermediates had been logged to Certificate Transparency before the block, and that CT logs were updated to reject certificates chaining to the compromised CAs. It also says Google reviewed its other root store keys and found no shared weak-entropy issue, and that the Chrome Root Program is still deciding whether to keep eMudhra's remaining CA certificates in the store.
