Independent Reporting · Not Legal or Security Advice · Verify With the Breached Company · Editorial Policy

eMudhra Certificate Fix in Node.js: 3 TLS Bugs and a Trust Store Update

When Node.js shipped its security release on October 21, 2026, two of the fixes were about the same question: can your app trust the server on the other end of an HTTPS connection? One was a trust-store update aimed at the compromised eMudhra certificate keys. The other was a set of three TLS bugs in how Node matches a certificate to a hostname or IP address.

Where it stands: The fixed builds are 26.12.1, 24.22.1 and 22.23.4. As of October 20, Cloudflare and Ars Technica both reported no sign that the eMudhra keys had been abused, but the cleanup across non-browser software was still under way.

Both problems sit in the same layer of trust. A forged certificate and a sloppy hostname check lead to the same outcome: a connection your code believes is genuine, made to a server that is not who it says it is.

What is the eMudhra certificate compromise?

It is the discovery that private keys behind eight eMudhra intermediate certificates were so weak that anyone could recover them. eMudhra is a certificate authority (CA) based in India: a company that vouches for websites by signing their certificates.

An intermediate certificate sits between a trusted root and the website certificates it signs. Whoever holds its private key can sign new certificates that software will accept. Cloudflare put the danger bluntly: with keys this weak, an attacker could forge a certificate for any domain and use it to pose as a real server.

How weak? Security researcher Scott Helme, as reported by The Register, found that one of the private keys “is the number 4.” Ars Technica reported that the compromised keys ranged from 3 to 8 bits in size, where Ars says a normal key of that type carries roughly 384 bits of entropy.

How did the eMudhra story unfold?

Over four days, from a private report to a Node.js release. The dates below come from the outlets and vendors named in each row. This was a separate incident from the PHP2Shell flaws patched on October 21.

When (UTC) What happened Source
Oct 17, 20:06 Mozilla receives the report about eight compromised keys The Register, quoting Mozilla
Oct 19, ~17:00 Cloudflare becomes aware and starts patching Cloudflare
Oct 20 Browsers and major apps block the certificates Ars Technica
Oct 21 Node.js ships a CA certificate update for the compromise Node.js

The Register reported that eMudhra had revoked the certificates and that many open source projects had issued updates so their software would no longer recognize them. eMudhra had not answered The Register’s questions at the time of its report.

What did Node.js change in its trust store?

Node’s advisory lists a CA certificate update on all three supported branches, labelled specifically as addressing the eMudhra intermediate CA compromise. A trust store is the list of certificate authorities a program will accept; Node carries its own bundled list.

The 24.22.1 release notes show two related changes. One updates the root certificates Node carries to NSS 3.131.1, the certificate set maintained by Mozilla’s NSS project. The other, a TLS change, makes Node reject certificate chains that contain blocked public keys.

The intended effect: a patched Node build refuses certificate chains that run through the bad eMudhra keys, at least for apps relying on Node’s own list. An unpatched build gets no such protection from Node.

What were the three TLS hostname bugs?

They were flaws in how Node decides whether a certificate matches the address you asked for, and two were rated high. TLS (Transport Layer Security) is the protocol behind HTTPS; part of its job is confirming that the certificate a server presents was issued for the name or IP you dialed.

  • CVE-2026-105483 (high): a hostname bypass when the IP is written in fullwidth digits. It affects the 26 and 24 branches.
  • CVE-2026-106069 (high): a second bypass, triggered when a hostname only loosely maps to an IP.
  • CVE-2026-106072 (medium): non-canonical IPv4 hostnames could let a certificate’s DNS names authenticate an IP endpoint.

The release notes describe the fixes as rejecting non-canonical IP addresses and correcting an IP normalization regression. We are not going beyond that level of detail. What matters for defenders is the shared theme: unusual ways of writing an address could slip past a check that should have failed.

Why do the two fixes belong together?

Because each one closes a different path to the same failure: accepting the wrong server. A forged eMudhra-signed certificate attacks the question of who signed the certificate. A hostname bypass attacks the question of whom it was issued to.

Neither is easy to use against a random target. Ars Technica noted that abusing compromised certificates requires an adversary-in-the-middle position, where the attacker sits between your app and the real server. That bar is lower on shared networks such as public Wi-Fi.

Filippo Valsorda, a cryptography maintainer for the Go language, told Ars the incident would be “a massive cleanup job, bigger than Heartbleed,” pointing to the long tail of containers, devices and tools that ship their own copies of trusted roots.

What should Node.js users check?

Upgrade the runtime, then confirm your apps are actually using the updated trust data. Cloudflare’s advice applies directly: updating an SDK alone may not change the trust policy underneath it.

  1. Upgrade Node. Run node -v, then move to 26.12.1, 24.22.1 or 22.23.4 depending on your branch.
  2. Rebuild containers. Images built before October 21 still hold the old runtime and the old certificate list.
  3. Check the operating system too. If your app is configured to use the system certificate store rather than Node’s bundled list, the OS needs its own update.
  4. Audit custom CA bundles. Apps that pass their own CA list, or add extra CAs, need that list reviewed by hand.
  5. Do not switch off verification. Cloudflare warned against clearing new certificate errors by disabling verification. In Node that includes setting NODE_TLS_REJECT_UNAUTHORIZED to 0.

For the rest of what the release fixed, including the Brotli remote-code-execution bug, see our full Node.js security release breakdown. If you manage your own certificates, our guide on what to do if your SSL certificate is compromised covers reissuing and revocation.

Cloudflare said its own security review found no active exploitation of the eMudhra issue on its services, and Ars Technica reported no certificate transparency log entries showing the keys used maliciously.

Frequently Asked Questions

What happened with the eMudhra certificates?

Private keys for eight intermediate certificates belonging to India-based certificate authority eMudhra were found to be weak and compromised. Mozilla received the report on October 17, and browsers and many software projects moved to stop trusting those certificates.

Does Node.js trust the eMudhra certificates after the update?

The October 21, 2026 Node.js releases include a CA certificate update that the project labels as addressing the eMudhra intermediate CA compromise, on the 26, 24 and 22 branches. Node versions without that update still carry the old trust data.

What is a TLS hostname bypass?

It is a bug in the check that confirms a certificate belongs to the name or address you connected to. If that check can be bypassed, a certificate issued for something else could be accepted. Node rated two such bugs high in this release.

Were the eMudhra keys used in attacks?

Ars Technica reported no sign in certificate transparency logs of the keys being used maliciously, and Cloudflare said its review found no active exploitation on its services. Neither statement proves no misuse happened elsewhere.

Should I turn off certificate checks if my Node app starts failing?

No. Cloudflare specifically warned against fixing new certificate errors by disabling verification, because that removes the protection the updates restore. Find which certificate chain is failing and replace it.

Sources


This article is news reporting and general security information based on the public sources listed above, as they stood on the dates shown. Incident details often change as investigations continue; check the affected company’s own status page and notices for the latest. Data Breach Radar is not affiliated with any company named here.

Owed money from a settlement? Check what is open at OpenClassActions.com. Caring for someone with dementia? Find practical guides at HelpDementia.com. Working out a skin routine? Evidence-based answers at AcneAdvocate.com. Forgot the name of a movie? Identify it at FindThisMovie.com.

We use cookies to run this site, measure how it’s used, and show ads. Choose “Essentials only” to limit cookies to what the site needs to work. Privacy Policy. Cookie Policy.