Tomorrow, 28 October 2026, Node.js 26 stops being the “Current” release and becomes Active LTS.[1][2][3] If you self-host Node on a VPS, that date is your natural upgrade trigger - and this time it comes with two extra layers of urgency. First, the line you may still be running (v24 “Krypton”) has already lost its Active status: it moved to Maintenance LTS on 20 October 2026.[2][3] Second, the version you would move to - 26.12.1 - is exactly the one that carries the October 21 security release, including the Node2Shell Brotli fix.[5][6]
So the upgrade to 26 and the security patch are the same install. Here is what changes tomorrow, what the migration from 24/22 involves on a real VPS, and the exact commands to get from node -v to a verified patched runtime.
What changes on 28 October 2026
The release working group’s schedule has been stable on these dates for months, and they are worth writing down:[2]
| Line | Released | Status now | Maintenance | End of life |
|---|---|---|---|---|
| v26 | 2026-05-05 | Current → Active LTS on 2026-10-28 | 2027-10-20 | 2029-04-30 |
| v24 (Krypton) | 2025-05-06 | Maintenance (since 2026-10-20) | - | 2028-04-30 |
| v22 (Jod) | 2024-04-24 | Maintenance (since 2025-10-21) | - | 2027-04-30 |
Three practical facts fall out of this table.
v24 is no longer the “current LTS”. As of 20 October it is in Maintenance: it still receives security and critical fixes (24.22.1 shipped on the 21st - more on that below), but no new features, and its end of life is under 18 months away.[2][3] If your production fleet is on 24.x because it is “the Active LTS line”, that framing stopped being true a week ago.
v22 is now the oldest living line. Its maintenance phase began on 21 October 2025, and it reaches end of life on 30 April 2027 - about six months from now.[2][3] It is still getting security releases (22.23.4), but you are now in the zone where a forced migration is a matter of when, not if.
v26 is the line the project wants you on. The official releases page states plainly: “Production applications should only use Active LTS or Maintenance LTS releases."[1] From 28 October, v26 is the Active LTS line, and 26.12.1 is its current patch release.
The cadence pivot: this is the last promotion of an era
There is a longer-term angle hiding inside this specific date, and it changes how you should think about every future Node upgrade - not just this one.
28 October 2026 is the last LTS promotion under the old even/odd model. The project’s own announcement is unambiguous: “Node.js 26 follows the existing schedule. This is the last release line under the current model.” In that model, an even-numbered major (22, 24, 26) was released in April, spent six months as Current, became LTS in October, and lived ~30 months; an odd-numbered major was disposable and died after six months.[4]
Starting with Node.js 27, the schedule changes to one major per year: Alpha for six months (October–March), Current for six months (April–October), then LTS with 30 months of support - and, critically, every release becomes LTS. There is no more odd/even lottery.[1][4] Per the release schedule, v27’s Alpha phase starts the same day v26 enters LTS (28 October 2026), with 27.0.0 due in April 2027 and LTS in October 2027.[2][4]
What this means for your version choice on a VPS:
- The “wait for the even number” heuristic is dead from v27 on. You can no longer rely on a version number’s parity to tell you whether a line is safe to run in production. Every major is an LTS candidate - the question becomes whether it has reached LTS, not whether it will.
- The LTS gate itself is unchanged. Even under the new model, a line is not production-recommended until it passes Current and enters LTS.[1] Adopting a brand-new major on day one stays a bad idea; targeting the October promotion stays the right rhythm.
- v26 is the last line you will ever migrate to “under the old rules”. From 2027, your upgrade cadence is one LTS-eligible major per year, and the schedule gives you that number ten years out: 27 in 2027, 28 in 2028, and so on.[4] Plan for that cadence - annually, in October - rather than the two-year feels-like-forever upgrade cycle most self-hosters are used to.
The security angle: 26.12.1 is the patched version
On 21 October 2026 the Node.js project shipped security releases across all three supported lines at once - the highest severity on each line being HIGH.[5] For the 26.x line, that release was 26.12.1, and it is the version you will be installing tomorrow anyway. The October batch includes, among others:[6]
- CVE-2026-111497 (High) - the Brotli decoder out-of-bounds write, aka Node2Shell, which an unauthenticated remote attacker can reach over HTTP from either side of the connection: a malicious client hitting an Express route that decodes a
Content-Encoding: brrequest body, or a malicious server hitting your built-infetch()when it transparently decompresses a Brotli response. Imperva demonstrated remote code execution against an official unpatched Node 24 image. We cover the mechanics and the VPS-side checks in depth in the Node2Shell guide.[7] - CVE-2026-105482 (High) - DNS names containing a NUL byte are silently truncated by
dns.resolve*()/dns.reverse()instead of rejected, sodns.resolve("trusted.example\0.evil.example")actually queriesevil.example. - CVE-2026-105483 and CVE-2026-106069 (High) - two TLS hostname-verification bypasses (fullwidth-digit and leading-zero IPv4 literals) that let a certificate for one IP authenticate a connection to another.
- Dependency updates on the 26 line: Undici 8.12.2, c-ares 1.34.9, root CA bundle to NSS 3.131.1.[6]
For a self-hosted box this collapses into one sentence: the only way to close the October CVEs is a version bump, and the version bump lands you on the line that becomes production-recommended tomorrow. If you run 26.x, ensure you are on ≥ 26.12.1. If you are on 24.x or 22.x, moving to 26.12.1 closes the same set of holes (plus the fullwidth-digit TLS fix that the 22.x line does not get at all - see the October security release walkthrough).[6]
What to expect when moving from 24/22 to 26
Node 26 is not a rename of Node 24. The v26.0.0 release notes list the headline changes and the removals you can trip over:[8]
- V8 14.6 (Chromium 146) - engine-level behavior changes on top of whatever your app does at the language level.
- Temporal API enabled by default - the new date/time API is on by default; if any dependency shims or polyfills parts of it, test that overlap.
- Undici 8.0 - the built-in HTTP client (
fetch,http.ClientRequestinternals) got a major version bump twice in the 26 line, landing at 8.12.2 in 26.12.1.[6][8] - Removed APIs that code from 2019–2023 may still touch:
http.Server.prototype.writeHeader()is fully removed (usewriteHead()); the legacy_stream_wrap/_stream_readable/_stream_writable/_stream_duplex/_stream_transform/_stream_passthroughmodules are removed; the--experimental-transform-typesflag is removed.[8]
The practical compatibility check for a VPS deploy is short:
# What's actually running in production, not what you think you installed:
node -v
# Does your package.json actually declare a Node range?
grep '"node"' package.json
# "engines": { "node": ">=22" } - bump this to what you verify, e.g. ">=26 <27" or "^26"
# Native modules (sharp, bcrypt, node-gyp builds) must be rebuilt for the new ABI:
npm rebuild
# or, cleanest:
rm -rf node_modules package-lock.json && npm install
Then run your test suite on the new runtime before touching production. The “works in dev, breaks on the box” failure mode on Node majors is almost always one of: a removed legacy API, a native-module ABI mismatch, or a transient dependency that pinned engines to an older major and refuses to install. All three surface in a staging check against 26.12.1 minutes after switching your version manager - much cheaper than finding them at 3am on a live box.
The migration itself: check, install, verify
If you manage Node with nvm (the usual single-tenant VPS setup):
node -v # v24.22.x or v22.23.x - you're in scope
nvm install 26.12.1 # installs the security-fixed Active LTS version
nvm use 26.12.1
nvm alias default 26.12.1 # pin the shell default
node -v # v26.12.1 - confirmed on the new runtime
If you deploy from nvmrc or engines, update those files to 26.12.1 / >=26 <27 so CI and fresh clones land on the same line. If you run Node from a direct binary tarball (common in minimal VPS setups and Dockerfiles):
wget https://nodejs.org/dist/v26.12.1/node-v26.12.1-linux-x64.tar.xz
sudo tar -xJf node-v26.12.1-linux-x64.tar.xz -C /usr/local --strip-components=1
node -v # v26.12.1
Then restart the process manager so the serving process is actually on the new binary - a version bump only counts when the running process was restarted onto it:
pm2 restart <app-name> # a restart, not just a reload
pm2 describe <app-name> | grep uptime # confirm a fresh PID since the switch
For containers, rebuild the image to the new base or runtime tag, then redeploy - the image layer is what matters, and a container built against an older runtime months ago stays on the old binary until it is rebuilt.
Three quick sanity checks after the switch:
node -v # v26.12.1
node -p process.versions.brotli # 1.2.1 - the patched decoder
npm config get registry # sanity: you didn't upgrade through a stale distro mirror
One honest caveat: version 26.12.1 is the current patch on the 26 line as of today’s check of dist/index.json; if a newer 26.13.x has shipped by the time you read this, take the newest 26.x instead - the LTS transition on 28 October does not reset the patch stream, and the security baseline is “≥ 26.12.1”.[3][8]
Which line should your app be on?
- Start something new today? Install 26.12.1 directly - it is the patched version of the line that becomes Active LTS tomorrow.
- On 24.x? You are on Maintenance with ~18 months left. Move to 26 now: you close the October CVEs, get off a line that no longer receives features, and skip the one-migration-per-year cadence starting next year.
- On 22.x? EOL is 30 April 2027 - six months out. Make 26 your target, not 24: moving 24 → 26 within a year just doubles the work.
- Only migrate the risky app? You can stagger: bump the critical/Internet-facing services to 26.12.1 first (they benefit most from the TLS/DNS/Brotli fixes), keep internal tools on 24.22.1 briefly. But set a deadline before April 2027, because that is when the oldest supported line disappears.
The takeaway
28 October 2026 is the date Node.js 26 becomes Active LTS - the last promotion under the old even/odd model, and the date the annual-cadence era effectively begins (v27 Alpha starts the same day per the release schedule).[2][4] Your migration path is unusually clean this time: the version to move to (26.12.1) is also the security-patched version, so the upgrade to Active LTS is the fix for Node2Shell and the other October HIGHs.[5][6] Check node -v, install 26.12.1 via nvm or tarball, run your tests, restart your process manager, verify with node -p process.versions.brotli. Do it once, and you are set until the next October rolls around - which, under the new cadence, is exactly how you should plan it for now on.
Sources
- Node.js - “Node.js Releases” (previous releases page; “Historically (up to Node.js 26), odd-numbered releases… become unsupported after six months, and even-numbered releases… move to Active LTS status”; “Starting with Node.js 27, the release cycle will be annual and every major version will move to LTS status”; “Production applications should only use Active LTS or Maintenance LTS releases”; v26 first released May 05, 2026). https://nodejs.org/en/about/previous-releases - checked 2026-10-27
- nodejs/Release - release schedule, machine-readable
schedule.json(v26: start 2026-05-05, lts 2026-10-28, maintenance 2027-10-20, end 2029-04-30; v24 Krypton: maintenance 2026-10-20, end 2028-04-30; v22 Jod: maintenance 2025-10-21, end 2027-04-30; v27: alpha 2026-10-28, start 2027-04-22, lts 2027-10-20, end 2030-04-30). https://github.com/nodejs/Release/blob/main/schedule.json - checked 2026-10-27 - endoflife.date - Node.js (v26 “Upcoming LTS”, latest 26.12.1 released 21 Oct 2026; v24 Active support ended 20 Oct 2026, security support to 30 Apr 2028; v22 security support to 30 Apr 2027). https://endoflife.date/nodejs - checked 2026-10-27
- Node.js - “Evolving the Node.js Release Schedule” (one major per year from 27.x; Alpha Oct–Mar, Current Apr–Oct, LTS 30 months; every release becomes LTS; “Node.js 26 follows the existing schedule. This is the last release line under the current model”; “Node.js 27 is the first release line under the new schedule”, Alpha begins October 2026, 27.0.0 April 2027, LTS October 2027, EOL April 2030). https://nodejs.org/en/blog/announcements/evolving-the-nodejs-release-schedule - checked 2026-10-27
- Node.js - “Wednesday, October 21, 2026 Security Releases” (new versions for 26.x/24.x/22.x lines on or shortly after 21 Oct 2026; highest severity HIGH on all three lines). https://nodejs.org/en/blog/vulnerability/october-2026-security-releases - checked 2026-10-27
- Node.js - release notes, v26.12.1 (Current) (security release 2026-10-21; High: CVE-2026-106069/106072 TLS non-canonical IP, CVE-2026-105482 DNS NUL bytes, CVE-2026-105483 TLS IP normalization regression, CVE-2026-111497 Brotli; undici 8.12.2, c-ares 1.34.9, NSS 3.131.1). https://nodejs.org/en/blog/release/v26.12.1/ - checked 2026-10-27
- DeploySmith - Node2Shell (CVE-2026-111497): The Critical Brotli RCE and What to Patch on Your VPS (Brotli decoder mechanics, both HTTP sides, VPS checks, Imperva PoC on official Node 24.22.0 image). https://deploysmith.dev/guides/node2shell-brotli-rce-vps/ - checked 2026-10-27
- Node.js - release notes, v26.0.0 (Current) (2026-05-05; Temporal API enabled by default; V8 14.6.202.33 / Chromium 146; Undici 8.0.2;
writeHeaderremoved, legacy_stream_*modules removed,--experimental-transform-typesremoved; build: GCC ≥ 13.2, Python 3.9 dropped). https://nodejs.org/en/blog/release/v26.0.0 - checked 2026-10-27 - Node.js - dist/index.json (latest releases as of check: v26.12.1 on 2026-10-21, v24.22.1, v22.23.4; v26.12.1 still
lts: falseuntil the 28 Oct transition). https://nodejs.org/dist/index.json - checked 2026-10-27