October 2026 Node.js vulnerability: affected versions and the update to apply

By Mouhamed BANKOLE, CEO at ITNET Technologies · Updated October 27, 2026 · Reading time: 8 min

On October 21, 2026, the Node.js project released security updates fixing ten vulnerabilities, four of them rated high, across the 22, 24 and 26 release lines (nodejs.org announcement). The most severe, CVE-2026-111497, is scored 9.8 out of 10 by Singapore's Cyber Security Agency and can lead to remote code execution (CSA alert). If you run an API, a Next.js site, a bot or a tool like n8n on a server, this Node.js vulnerability most likely affects you. Here is what is confirmed, which versions are affected, how to check yours and what to do today.

In short

• Node.js fixed ten vulnerabilities on October 21, 2026, four of them rated high, on the 22, 24 and 26 release lines.
• The safe versions are Node.js 26.12.1, 24.22.1 and 22.23.4 or later; end-of-life versions are also affected and no longer receive fixes.
• The most severe flaw (CVE-2026-111497) affects Brotli decompression and can lead to remote code execution; a public proof of concept exists.
• On a VPS or dedicated server, updating is your job, including inside your Docker images.
• Check your version with node -v, update, restart your processes and rebuild your containers.

Contents

1. What happened with Node.js on October 21, 2026?
2. Which Node.js versions are affected?
3. Which flaw is the most severe?
4. What does this change for your applications?
5. How do you check your Node.js version?
6. What should you do today?
7. How do you update Node.js on a VPS or in Docker?
8. Who has to apply the update, depending on your hosting?
9. What if your Node.js version is no longer supported?

What happened with Node.js on October 21, 2026?

On October 21, 2026, the Node.js project shipped patched releases for its three supported release lines, fixing ten vulnerabilities (nodejs.org). The fixes landed on the same day as PHP's, a day that French tech outlet Next called a "black day" for cybersecurity (Next).

What is confirmed by official sources:

• ten CVEs are fixed: four high, three medium and three low (nodejs.org);
• the 22, 24 and 26 lines are affected, though not all to the same degree (nodejs.org);
• Hong Kong's CERT rates these flaws as high risk and reports a public proof of concept for CVE-2026-111497 (HKCERT);
• Singapore's agency advises updating immediately (CSA).

What is not confirmed so far: none of the sources consulted reports active exploitation of these flaws (nodejs.org, CSA).

Which Node.js versions are affected?

Every Node.js version released before the October 21, 2026 fixes is affected, including end-of-life versions that the project no longer patches (nodejs.org).

Sources: nodejs.org announcement and HKCERT bulletin.

The four high-severity flaws, according to the vendor (nodejs.org):

Which flaw is the most severe?

The most severe is CVE-2026-111497, an out-of-bounds write in the Node.js Brotli decoder, scored 9.8 out of 10 under CVSS v3.1 by Singapore's agency (CSA).

What we know about it:

• it is triggered when an application uses node:zlib to decompress Brotli data supplied by a third party (nodejs.org);
• possible consequences are a crash, leaked process memory or remote code execution (nodejs.org);
• a public proof of concept exists, which makes it the most urgent fix according to HKCERT (HKCERT).

Analysis: the most exposed applications are those that accept compressed content from outside (APIs, proxies, automation tools that fetch web pages). Since you cannot audit every dependency, updating remains the only reliable answer.

What does this change for your applications?

If your server runs an unpatched Node.js version, an attacker could crash your applications, read part of their memory or, in the worst case, run code on the server.

The concrete risks:

• downtime: an API, site or bot that keeps crashing;
• leaked secrets: API keys, tokens and environment variables held in memory;
• server takeover and lateral movement to your databases;
• bypassed TLS checks for the certificate-related flaws, which affect your applications' outgoing connections.

Typical affected uses: server-rendered Next.js or Nuxt sites, Express or Fastify APIs, self-hosted automation tools such as n8n, bots and workers. To gauge the stakes for a self-hosted AI app, see our guide to hosting an AI application.

How do you check your Node.js version?

Run node -v in a terminal on the server: it prints the exact version, which you compare with the table of fixed versions.

Depending on your setup:

1. directly on the server: node -v;
2. inside a Docker container: docker exec <container> node -v, for each container;
3. with a version manager (nvm, fnm): nvm ls lists every installed version;
4. in your CI: check the image or action that installs Node.js, often pinned to an old version.

Pro tip: a server can have several Node.js versions. Also check the one used by your process manager (PM2, systemd), not just the one in your shell session.

What should you do today?

Install the fixed version for your release line, restart every Node.js process, then rebuild and redeploy your containers.

The action list, in order:

1. take stock of the servers, containers and pipelines that use Node.js;
2. read the vendor's release notes before installing (nodejs.org);
3. test in a staging environment if your application is critical;
4. take a snapshot of the server before updating;
5. update to 22.23.4, 24.22.1 or 26.12.1;
6. restart your processes (PM2, systemd): an updated but not restarted Node.js stays vulnerable;
7. check with node -v and watch the logs.

How do you update Node.js on a VPS or in Docker?

The method depends on how Node.js was installed: system package manager, version manager or Docker image.

The most common cases:

• system packages (distribution or Node.js repository): update the nodejs package with your system's package manager, then restart the services;
• nvm or fnm: install the new version of your line, make it the default and restart your processes with it;
• Docker: update the base image tag (for example node:22 to the latest 22.x), rebuild the image without cache and redeploy;
• continuous integration: update the version declared in your configuration files so the next builds use the fixed release.

On a Wayhost VPS, full root access lets you apply these updates yourself, and instant snapshots can be created from the customer area before the operation (checked on October 27, 2026).

Who has to apply the update, depending on your hosting?

On a server you manage yourself, VPS or dedicated, updating Node.js is up to you; on a managed platform it is normally the provider, but check which version you run.

For demanding or numerous applications, a Wayhost physical server offers dedicated CPUs, NVMe storage and included DDoS protection (checked on October 27, 2026). For a brochure or WordPress site with no server-side Node.js, shared web hosting leaves system updates to the host. If you are weighing these options, our guide what is a VPS? compares them.

What if your Node.js version is no longer supported?

Move to a supported release line, because the Node.js project states that end-of-life versions are also affected and will not be patched (nodejs.org).

To prepare the move:

• list your dependencies and check that they work with Node.js 22 or 24;
• run your tests on the new version in a separate environment;
• prefer an LTS line (22 or 24) for production;
• schedule future upgrades so you never sit on an abandoned line again.

The same logic applies to PHP, whose critical flaws were fixed the same day: see our article on the PHP vulnerability and the update to apply.

Frequently asked questions

What is the October 2026 Node.js vulnerability?

It is a batch of ten vulnerabilities fixed by the Node.js project on October 21, 2026, four of them rated high. The most severe, CVE-2026-111497, affects Brotli decompression and can lead to remote code execution. A public proof of concept exists.

Which Node.js versions should you install?

Versions 26.12.1, 24.22.1 and 22.23.4, or later, fix these flaws. Pick the one for your current release line to limit compatibility risks. End-of-life lines do not get a fix.

How do you know if your server runs a vulnerable version?

Run node -v on the server and in each container. Compare the result with the fixed version for your line. Any lower version is vulnerable.

Is the vulnerability being actively exploited?

The official sources consulted do not report active exploitation so far. However, a public proof of concept exists for the most severe flaw. The risk of attacks therefore grows as long as servers stay unpatched.

Do you need to restart after updating Node.js?

Yes. Processes that are already running keep using the old version in memory. Restart your services and check the version used by PM2 or systemd.

Are your Docker containers safe if the server is up to date?

No. Each container ships its own Node.js version, separate from the server's. You need to update the base image, rebuild it and redeploy the container.

Is your WordPress site affected?

Usually not, because WordPress runs on PHP rather than Node.js. It can be if you use server-side Node.js tools. Do check your PHP version though, since it was patched the same day.

Key takeaways

• Ten Node.js vulnerabilities were fixed on October 21, 2026, four of them rated high.
• Versions 26.12.1, 24.22.1 and 22.23.4 or later fix them.
• CVE-2026-111497 is the most urgent: possible code execution and a public proof of concept.
• On a VPS or dedicated server, it is up to you to update, restart and rebuild your containers.
• End-of-life versions are no longer patched: you need to migrate.

To run your Node.js applications with full root access and snapshots before every update, explore Wayhost VPS.

Article written by Mouhamed BANKOLE, CEO at ITNET Technologies.