Half of the Node.js servers we meet in India are on a version that has already stopped getting security fixes. Nobody decided that. The app was built on Node 18 or 20, it kept working, and nothing forced an upgrade. Node2Shell is the thing that forces it.
If you need to upgrade Node.js after Node2Shell (CVE-2026-111497), this is how we would think about it: what is fixed, what is not, and how to avoid breaking production on the way.
Which Node.js versions got the fix
The October 2026 security releases, published on 21 October, are:
- 26.x: fixed in 26.12.1
- 24.x: fixed in 24.22.1
- 22.x: fixed in 22.23.4
Node 20 and older, 23 and 25 are end of life. They are affected by the flaw and will not get a patch. If you are on one of them, the answer is not “wait for a backport.” It is to move to a supported line.
The same release also fixed several other issues in TLS hostname checking and DNS handling, rated High by Node.js, so this is not an upgrade you will regret taking.
Which target version to pick
Our default is boring: pick the newest even-numbered, supported line that your dependencies are happy with, and go to the latest patch release. For most apps that means 22 or 24. Choose 26 if you are starting something new and your tooling supports it.
Do not jump from 16 to 26 in one commit and hope. Go in steps if the gap is big, run your tests at each step, and read the changelogs for the lines you cross. Native modules (things like image processing or database drivers that compile) are what usually break.
The upgrade that hurts is the one you have postponed four times. Each postponement adds another major version to the gap.
A rollout order that doesn't scare anyone
- Pin it first. Make sure your Dockerfile, CI config, and .nvmrc or engines field all say the same thing, so you are not testing one version and deploying another.
- Rebuild images. A container built last month still contains the old runtime. Changing the tag in a Dockerfile you have not rebuilt fixes nothing.
- Staging first. Run the full test suite, then use the app yourself for ten minutes. Watch memory use. Runtime upgrades sometimes change garbage collection behaviour.
- Roll out one service at a time if you have many, starting with anything that fetches external URLs or accepts compressed request bodies.
- Keep a way back. A previous image you can redeploy in one command is worth more than any amount of confidence.
Other runtimes that bundle Brotli
The root cause sits in Google's Brotli library (versions 1.0.3 through 1.2.0 per the CVE record, fixed in 1.0.10, 1.1.1 and 1.2.1). Node is the headline, but other software that bundles it can be affected. Bun is reported as affected, with 1.4.4 or newer removing the flaw. If you ship anything that vendors Brotli, ask the maintainers or read their changelog.
Make the next one less painful
This will happen again, with a different name. A short list that helps: know which services run which Node version, rebuild base images on a schedule, and put a supported version in your CI so unsupported ones fail loudly. It is dull work. It is also the difference between a calm afternoon and a long weekend.
The background is in our explainer on Node2Shell, and the exposure checklist will tell you which services to do first.
If your Node.js setup needs an upgrade and a cleanup, we do both. Our software development team in Delhi NCR handles runtime upgrades, dependency clean-ups and CI setup for Indian businesses. See our Node.js upgrade and EOL migration work or get in touch and tell us which Node version you are on.