A certificate authority was distrusted. Does your Node app know?

In the week of 18 October 2026 a certificate authority lost the trust of the web. According to the pwn.watch incident tracker, a researcher reported that the private keys of eight eMudhra Global TLS intermediate CAs were cryptographically weak and could be recovered; Mozilla, Chrome, Apple and Microsoft blocked those intermediates, and eMudhra revoked them on 19 October. On 22 October the company announced it is leaving the global SSL/TLS certificate business. If you write PHP or Node.js, your browser was protected by its vendor. Your backend services were protected only if somebody updated them.

What happened, in the company's words and the tracker's

eMudhra's press release says it revoked the affected CAs "within 14 hours of discovery" and disclosed promptly. That figure is the company's own claim. It also says no end-entity certificates were issued from the affected CAs, that its infrastructure was not compromised and no data was breached, and that global SSL/TLS is about 1% of its revenue. Its G1 RSA roots will keep serving customers during the transition, affected customers get replacement certificates free through partners, and revocation and status services stay up until every issued certificate has expired or been replaced.

The pwn.watch tracker adds that the ECC root was distrusted as a precaution, and that runtimes which ship their own trust stores, it names Go, Node.js, Electron, Python's certifi and curl among them, needed emergency CA bundle updates. The Node.js project's October 2026 security release confirms its part: it lists a ca-cert update for the "eMudhra Intermediate CA Compromise" on the 26.x, 24.x and 22.x lines.

Your browser's list is not your server's list

This part is general knowledge about how TLS clients work, not a detail of this incident. A TLS client decides whom to trust from a list of root certificates, its trust store. Browsers and operating systems ship and update their own. Many runtimes and libraries carry a copy of their own instead: Node.js bundles Mozilla's list inside each release, and Python code that uses certifi trusts certifi's file. Other runtimes read the operating system store unless told otherwise, so check the documentation of the one you use rather than assuming.

That is why a distrust reaches people at different speeds. Chrome on your laptop updated itself. A Node service calling a payment API from a Docker image you built in August still carries the list from August, and it will keep trusting a revoked intermediate until the runtime or the bundle inside that image changes.

What to do this week

Update the runtime on every service, then rebuild and redeploy the images, because a new Node.js release on your laptop changes nothing inside an image that is already running. Where Python is involved, update certifi too.

node --version
docker build --pull --no-cache -t my-api .
pip install --upgrade certifi

If a call starts failing with a certificate error after the update, the error is the protection working. Do not set NODE_TLS_REJECT_UNAUTHORIZED=0 or pass rejectUnauthorized: false to make it go away: that turns off verification for every connection the process makes, not just the broken one. Find out which certificate the remote side presents and get it replaced; eMudhra says affected customers receive replacements at no cost.

Next step: open the Dockerfile of your oldest running service, check its base image date, and rebuild it today. Then add certificate expiry and Certificate Transparency monitoring for your own domains, so the next change in who issues them reaches you before your users do.

Source: eMudhra press release, 22 October 2026, and the Node.js October 2026 security releases.