Node.js Just Shipped 10 Security Fixes: Is Your Server Still Running the Old Version?

What the October 2026 Node.js security release fixes

The Node.js Project published updates for the 22.x, 24.x and 26.x release lines. The release addresses 10 vulnerabilities: four high, three medium and three low severity. The most serious issues include DNS input validation, TLS hostname and certificate validation, and a Brotli decoder out-of-bounds write that can permit remote code execution in affected conditions.

Some fixes are in dependencies bundled with Node.js, including Brotli. Patching the operating system alone is not enough when your application runs inside a Node.js binary or container image. End-of-life versions are affected whenever a security release occurs.

The fixed Node.js versions

Upgrade Node.js 22 installations to 22.23.4 or later, Node.js 24 installations to 24.22.1 or later, and Node.js 26 installations to 26.12.1 or later. Choose the latest supported patch release available for your line.

Node.js 20 reached end of life on April 30, 2026 and will not receive these fixes. Treat this as both a patching task and a supported-platform migration: plan a move to Node.js 22 or 24, test compatibility, then remove the old runtime from servers, images and build agents. Node.js 26 becomes LTS on October 28, 2026.

Why the vulnerabilities matter

The release includes high-severity flaws affecting DNS names and non-canonical IP representations during TLS validation. It also fixes a Brotli decoder memory-safety issue that may allow remote code execution when an application processes attacker-controlled compressed data.

The practical risk depends on your application, network clients, parsers and permissions. Node.js published no workaround that replaces installing the fixed release, so update and restart affected processes.

Step 1: Find every Node.js runtime

Run node -v on each server, but also check Dockerfiles, container registries, Kubernetes deployments, CI runners, build images, serverless settings, process managers and tools such as nvm, Volta, fnm and asdf. A service can keep using an old binary even after a newer version is installed on the same machine.

Record the runtime version, owner, deployment path and restart method. This turns a security alert into a patchable inventory.

Step 2: Update your deployment

For Docker, replace exact old pins such as node:20.20.1 with a supported fixed line, then pull, rebuild and redeploy. A representative workflow is docker compose pull, docker compose build --pull and docker compose up -d. Confirm the runtime version inside the running container.

For nvm, install a fixed version such as nvm install 22.23.4 and update the project's version file. For NodeSource or other packages, use the vendor's update workflow and verify the installed package revision. Old OS repositories often lag behind supported Node.js releases.

Step 3: Restart, then verify

A running Node.js process continues using the binary that started it. Restart services after deployment with your process manager, such as pm2 restart all or systemctl restart your-service. For containers, recreate the container so the new image is running.

Verify node -v inside the running environment, review health checks and logs, and exercise critical endpoints. Keep rollback available, but do not leave the old runtime running indefinitely.

A practical patch checklist

Identify Node.js versions across production, staging, CI and local build images. Patch supported 22.x, 24.x or 26.x installations, rebuild immutable artifacts, restart applications and verify the live binary. Remove or block unsupported Node.js 20 and older images from your pipeline.

For the long term, pin runtimes in one obvious place, update them through a tested pull request, subscribe to Node.js security announcements and schedule a recurring patch day. Add runtime-version checks to deployment health checks.

Frequently asked questions

Does an automatic OS update fix Node.js inside Docker? No. Container images carry their own runtime and must be rebuilt.

Is installing a new Node.js version enough? No. Existing processes must be restarted, and every server, container, CI runner and build image must be checked.

Can I stay on Node.js 20? It is end of life and does not receive these fixes. Plan a supported migration to Node.js 22 or 24.

Are fixes only relevant to public web servers? No. Internal APIs, workers, CI systems and services processing untrusted data can also be exposed.

The bigger lesson: runtime patching needs an owner

Node.js security work is normal operations, not an occasional emergency. A reliable process has an inventory, supported-version policy, reproducible builds, automated tests, a restart plan and post-deployment verification. Apptheka Solutions can help inventory runtimes, update deployment pipelines and plan a tested migration from an end-of-life release.