Node.js: 10 triggered vulnerabilities—what updates are needed?

The October 2026 Node.js vulnerability requires upgrading to at least Node.js 22.23.4, 24.22.1, or 26.12.1, depending on the branch in use. Released on October 21, 2026, these versions fix ten CVEs, including four high-severity vulnerabilities. The priority is to inventory each environment, then rebuild and redeploy the applications so that the engine actually being executed is fixed.

Which versions fix the October 2026 Node.js vulnerability?

The Node.js security fixes released on October 21, 2026, are included in versions 22.23.4 LTS, 24.22.1 LTS, and 26.12.1 Current. Any earlier version in the 22.x, 24.x, or 26.x branches must be updated. A branch that has reached end of life does not receive these official fixes.

Node.js est un environnement d’exécution qui permet notamment de faire fonctionner du JavaScript côté serveur. Il peut alimenter une API, le serveur d’un site construit avec Next.js, un traitement automatisé ou un outil interne. La version présente sur le poste d’un développeur ne prouve donc rien sur celle qui tourne en production.

The classic trap is updating Node.js on the host server while the application uses its own runtime in a Docker image. The same issue applies to a deployment artifact, snapshot, or single-executable application: the vulnerable binary may remain embedded there.

Node.js 22.23.4 also updates c-ares to 1.34.9, OpenSSL to 3.5.9, SQLite to 3.53.4, and Undici to 6.29.1. Node.js 24.22.1 includes, among other components, c-ares 1.34.9, OpenSSL 3.5.9, and Undici 7.30.1, according to the Node.js project’s 2026 release notes.

What is the actual risk of the Brotli CVE-2026-111497 vulnerability?

CVE-2026-111497 is an out-of-bounds write in the Brotli decoder integrated into Node.js. Malformed Brotli content can exceed a memory buffer and cause a crash, memory disclosure, or remote code execution. However, exploitation requires the application to decompress attacker-controlled data.

Brotli is a compression algorithm used to reduce data size. An out-of-bounds write means that a program writes beyond the allocated memory area. The potential impact is serious, but running a vulnerable version is not enough to establish that a site is remotely exploitable.

On October 23, 2026, the Cyber Security Agency of Singapore assigned CVE-2026-111497 a CVSS v3.1 score of 9.8 and recommended immediate remediation. Node.js, for its part, classifies the vulnerability as High. These two assessments use different methods or scales; they do not change which versions must be installed.

As of October 23, 2026, Red Hat stated that it had no reliable public evidence of remote code execution. On October 26, 2026, Rapid7 reported that it was not aware of active exploitation and noted that the CVE was not listed in CISA’s Known Exploited Vulnerabilities catalog. This justifies a rapid update, not a claim of widespread compromise.

What fixes the other nine Node.js vulnerabilities?

The October 2026 Node.js updates fix nine additional vulnerabilities: three high-severity, three medium-severity, and three low-severity issues. The risks notably involve DNS resolution, TLS hostname verification, persistent HTTP connections, IPv4 addresses, random values, and certain file permission checks.

The three other high-severity vulnerabilities are CVE-2026-105482, involving null-byte truncation in DNS, as well as CVE-2026-105483 and CVE-2026-106069, two TLS hostname verification bypasses. TLS is the protocol that secures network communications and notably verifies the identity of the server being contacted.

According to the Node.js advisory of October 21, 2026, CVE-2026-105483 affects the 24.x and 26.x branches; the 22.x branch is not listed as affected. This nuance matters during analysis, but it should not lead to delaying the overall fix for a branch that contains other vulnerabilities.

The medium-severity vulnerabilities affect the handling of HTTP keep-alive responses with CVE-2026-105481, non-canonical IPv4 hostnames with CVE-2026-106072, and the repetition of random values in snapshots or single-executable applications with CVE-2026-106074. A keep-alive connection remains open to carry multiple exchanges without systematically reconnecting.

The low-severity vulnerabilities are CVE-2026-106070 in the Node.js 26.x ZipFile API, CVE-2026-106071 in the Node.js 26.x permission model, and CVE-2026-106073 in the permission checks of fs.realpathSync() for the 22.x, 24.x, and 26.x branches. As with the risks related to PHP vulnerabilities, theoretical severity must be considered alongside the functions that are actually exposed.

How do you check Node.js on servers, Docker, and CI?

The inventory for the October 2026 Node.js vulnerability must cover runtimes installed on hosts, running processes, active containers, Docker images, Kubernetes workloads, and continuous integration pipelines. The command node --version is useful, but its output must be recorded in the exact context in which each application runs.

A server may contain multiple Node.js executables. The service’s system account may also use a different path from an administrator’s session. For an agency, the standard practice is to check the binary launched by the process manager rather than stopping at the version displayed in a terminal.

The operational audit should cover these points, in this order:

1. Record node --version, the executable path, and the environment of the service units on each host.
2. Check the version inside each active container with docker exec node --version.
3. Read the Dockerfiles and their base images, including tags that may point to older content.
4. Examine the images declared in Kubernetes workloads and the registries where they are stored.
5. Vérifier les versions Node.js déclarées dans les workflows CI, les outils de build et les fichiers de configuration.
6. Identify snapshots, artifacts, and standalone applications that embed their own runtime.

With Docker, changing only a tag in a file without rebuilding the image leaves existing containers unchanged. This type of discrepancy also explains why the correction of a Docker vulnerability requires controlling the image actually being run, not just the intended configuration.

How can you deploy the fixes without interrupting the application?

Deploying Node.js fixes should go through a test environment, followed by rebuilding the images and artifacts before a gradual redeployment. Node.js processes must be restarted. A batch replacement behind a load balancer keeps the service available when the architecture includes multiple healthy instances.

Start with a usable backup and test the essential workflows: login, payment, email delivery, file import, API calls, and scheduled tasks, depending on the project. Then check the logs, HTTP errors, and resource usage. A runtime update may reveal an outdated dependency, even if the security fix itself remains compatible with the branch.

For a container, rebuild from a corrected base image, push the image with an immutable identifier, and then deploy it. Kubernetes must be prompted to create new pods; restarting an old container based on the same vulnerable image fixes nothing. The same logic applies to CI: deliverables must be regenerated with the corrected runtime.

Honestly, keeping an end-of-life Node.js branch to avoid a repetitive testing campaign postpones the risk until the next security advisory. At this point, it is better to plan a migration to a maintained LTS branch, even if that means separating the immediate fix from application modernization. The choice of architecture, particularly between Astro and Next.js for a web project, must also account for the runtime maintenance policy.

After deployment, check the version again from each active process or container. Keep evidence of the version, the deployed image, the date, and the test results. A simple change in the Git repository does not prove that production has been corrected.

Cadrer l’inventaire, les tests et le retour arrière avant l’intervention évite la plupart des mauvaises surprises. Un regard extérieur peut surtout aider lorsque plusieurs serveurs, conteneurs et pipelines embarquent des versions différentes du même runtime.

FAQ on Node.js fixes from October 2026

Can a Node.js website be hacked remotely?

A vulnerable Node.js site is not necessarily remotely exploitable. CVE-2026-111497 requires the application to decompress attacker-controlled data with Brotli, but updating is still recommended without waiting for proof of exploitation.

Is updating Node.js on the server enough when using Docker?

Updating Node.js on the host does not corrige the engine embedded in a Docker image. The image must be rebuilt from an updated base image, then the containers must be recreated and their version checked.

Which command displays the Node.js version?

The command node --version displays the Node.js version available in the current environment. Run it in the containers as well and under the account used by the service to avoid checking the wrong binary.

Can we stay on an older Node.js branch?

An end-of-life Node.js branch does not receive the security fixes published by the project. A production application should migrate to a supported LTS branch rather than consider its old major version as corrected.