November 11 Node.js Security Updates for Supported and End of Life Versions

Key Takeaways

• Node.js plans High-severity fixes for 22.x, 24.x, and 26.x on or shortly after November 11.
• Upstream treats end-of-life versions as affected but ships no fixes for them.
• ELS for Runtimes is preparing backported fixes for eight end-of-life Node.js lines across supported distros.
• Restart every Node.js app after updating, and verify end-of-life backports by package release, not node --version.

Node.js has scheduled its next round of security releases for Wednesday, November 11, 2026, or shortly after. New versions are coming for the 22.x, 24.x, and 26.x lines, and the project rates the most serious issue in each line as High. CVE IDs and technical details stay under wraps until the releases go out, so any early claims about specific attack methods deserve a healthy dose of suspicion.

For teams running Node.js through alt-nodejs packages, the announcement is only half the story. That includes CloudLinux hosting servers as well as the Debian, Ubuntu, Alpine, and Enterprise Linux hosts covered by TuxCare’s Endless Lifecycle Support (ELS) for Node.js. A fix published on nodejs.org doesn’t, by itself, patch anything running on those systems. Updated packages have to be built, published, and installed, and running applications have to be restarted before the fix takes effect. Most of the prep work can happen now, well before any details drop.

The end of life lines upstream won’t patch

The upstream release covers 22, 24, and 26 only. The Node.js advisory states that end-of-life versions are always affected when a security release occurs, even though upstream no longer ships fixes for them. That doesn’t mean every old line carries every newly fixed bug, but nothing running Node.js 20, 18, or older should be treated as safe just because its version isn’t on the release list.

That gap is exactly what ELS for Runtimes covers. TuxCare’s ELS team is preparing backported fixes for eight end-of-life alt-nodejs lines, Node.js 10, 12, 14, 16, 18, 19, 20, and 23, so an application pinned to an older runtime can take this round’s fixes as a package update instead of an emergency migration. Backporting is real engineering work – the fix has to be adapted to code that upstream no longer maintains – but the plan is to ship these builds on November 11 alongside everything else, shortly after the upstream release. The ELS for Runtimes documentation lists which Node.js versions are covered on each operating system.

Which repositories carry the fixed builds

On CloudLinux, Node.js Selector runs on alt-nodejs packages, and the Node.js version is picked per application, not per server or even per account. That’s how one hosting server quietly ends up running three or four Node.js versions side by side, including some that are no longer supported upstream.

The same alt-nodejs packages also go out through TuxCare’s repositories for ELS customers, covering Debian 10 through 13, Ubuntu 18.04 through 26.04, and Alpine 3.23 and 3.24, plus TuxCare-signed builds for Enterprise Linux. They install under /opt/alt/, next to whatever Node.js the distro already ships, and update through the usual yum, apt, or apk workflow. Node.js 23 builds are only offered on Debian 12, Debian 13, and Alpine.

When the updated packages will be available

CloudLinux plans to start building as soon as Node.js publishes the fixes and expects to release updated alt-nodejs packages later the same day. That covers 22, 24, and 26 along with the end-of-life lines on every CloudLinux version from 6 through 10, and the TuxCare repository builds go out in the same run. That plan hangs on the upstream release, so it’s a target rather than a fixed delivery time.

CloudLinux hosts have two other Node.js package types with their own update paths. On cPanel servers running CloudLinux 8, ea-nodejs22 also comes from the CloudLinux repositories, but it’s built from cPanel’s package. Its fix depends on cPanel publishing an updated version first and CloudLinux then making the matching package available. The operating system’s native nodejs packages take a separate route again, through the regular RHEL and AlmaLinux-based OS updates. Any runtime installed outside these channels needs checking on its own, since an alt-nodejs update won’t touch it.

Prep work worth doing before Wednesday

On CloudLinux, subscribe to the CloudLinux status page for this release. CloudLinux plans to share an ETA early on Tuesday, November 10, then post progress updates every few hours until the packages are available. ELS customers on other distros can watch for fixed builds in TuxCare’s list of available Node.js fixes.

Next, take inventory. Run whichever of these matches the host’s package manager (RPM, DEB, or APK):

rpm -qa 'alt-nodejs*'
dpkg -l 'alt-nodejs*'
apk info | grep alt-nodejs

That shows which versions are installed, not which applications use them. On CloudLinux, check Node.js Selector as well to see the version assigned to each application. Elsewhere, systemd units, PM2 configs, and container images can each point at a different binary, so check those too. One app missed during the update window can keep running an old runtime while everything else looks current.

Then plan for restarts, because the package update alone isn’t enough. Installing an updated package replaces the binary on disk, but a running Node.js application keeps using the old one until it restarts, whatever the package manager says.

Applications managed through Node.js Selector can be restarted from its interface or with this command, using the account name and application root:

cloudlinux-selector restart --json --interpreter nodejs --user <user> --app-root <app_root>

Anything running outside Node.js Selector gets restarted the way that service is normally managed. Afterward, this lists every running Node.js process with its start time, so anything that started before the update stands out:

ps -eo pid,lstart,args | grep -E '[n]ode( |$)'

On servers hosting many applications, work out the restart order ahead of time and coordinate with application owners where downtime matters. A planned, staggered restart beats a rushed one on release night.

What to do once the packages land

When the relevant alt-nodejs packages are out, apply them through your normal package management process and restart the affected applications. Then confirm each app came back up cleanly and is running the updated runtime. A successful package install isn’t proof that every application has picked up the fix.

End-of-life lines need one extra check. The 22, 24, and 26 packages move to the new upstream releases, so their version number changes as expected. A backport works differently, adding the fix on top of the existing version, so the upstream Node.js version stays the same and only the package release number changes. On those lines, node --version looks identical before and after the update, so compare the installed package release against the fixed build CloudLinux or TuxCare publishes instead. Scanners that only compare version strings can trip over the same thing and flag a patched backport as vulnerable.

The Node.js advisory will carry the vulnerability details and fixed upstream versions once the releases are public. On an alt-nodejs host, though, the practical question is simpler. Has the updated package been installed, and has the app been restarted on it? For the lines upstream has left behind, ELS for Runtimes keeps the fixes coming, so migrations can happen on a schedule the team picks instead of one an advisory picks for it.

Get ELS for Runtimes →

References

Node.js, “Wednesday, November 11, 2026 Security Releases”

CloudLinux status page, “Node.js security releases, November 11, 2026”

TuxCare Documentation