On November 3, 2026, the Node.js project announced that it will ship new versions of the 26.x, 24.x and 22.x lines "on or shortly after" Wednesday, November 11. The notice rates the most severe issue fixed in each of the three lines as high. Technical details are published only with the releases, as the project usually does.
The announcement itself notes that end-of-life versions are always affected when a security release happens. They do not get the fix.
Which versions get the fix
According to the official schedule, as compiled by endoflife.date, the most common lines stand like this:
Line | Status in November 2026 | End of fixes |
|---|---|---|
Node 26 | Active LTS since October 28 | April 30, 2029 |
Node 24 | Maintenance LTS since October 20 | April 30, 2028 |
Node 22 | Maintenance LTS | April 30, 2027 |
Node 25 | End of life since June 1, 2026 | no fix |
Node 20 | End of life since April 30, 2026 | no fix |
Teams on 22, 24 or 26 get a patch release within their current line, which is usually a small update. Teams still on Node 20, or left on 25 after it ended in June, get nothing on November 11: the issue stays open until the application moves to another line.
This is the second security release in three weeks. The October 21 release fixed, among others, a high-severity issue in which dns.resolve*() truncated names containing a NUL character (CVE-2026-105482) and two high-severity issues in TLS certificate hostname checks for IP addresses written in non-canonical form (CVE-2026-105483 and CVE-2026-106069). The November notice does not say whether the new issues are related.
Who needs to act
Any application running Node.js in production: APIs, queue workers, server-side rendering in frameworks such as Next.js and Astro, and also the build pipeline, which runs Node even when the final site is static. The actual risk depends on which module is affected, and that has not been disclosed.
On a managed platform, the provider updates the runtime. Check its documentation for when the fixed version becomes available and whether the switch is automatic or needs a new deploy. With your own Docker images, the fix only arrives when the image is rebuilt from an updated tag; an old image that is already running keeps the old binary.
What to do before November 11
By next Wednesday, the job is to know where each version runs and to make sure a patch update can reach production within a day or two:
- list the Node version of each service, checking
.nvmrc, theenginesfield inpackage.json, theFROMline in Dockerfiles, the CI configuration and the provider settings; - confirm that the pipeline rebuilds images and runs the tests without manual steps;
- set aside a window on November 11 or 12 to apply the new versions, after reading the full announcement.
For teams on Node 20 or 25, the decision is different: a patch update does not help, and moving to 24 or 26 now has a deadline. I wrote about why a supported version still calls for a migration decision. On lines 20 and 25 the delay already has a cost, because each security release makes public one more issue that will not be fixed there.
What is still unknown
The notice does not say how many issues there are, which modules they affect, whether CVEs have been assigned, or whether any is being exploited. It also does not say whether the release includes updates to bundled dependencies such as OpenSSL or Undici, as happened in October. The date may slip, since the text says "on or shortly after" November 11. In October, the announcement page was updated with the list of issues when the versions shipped, so that is where the details should appear.
If your company is weighing something similar, reach me on LinkedIn or WhatsApp.
