Node.js vulnerabilities, November 2026: 16 flaws and how to update

The Node.js vulnerabilities fixed on November 11, 2026: HTTP/2 and TLS risks, the bugs found with Claude, and how to update with nvm, Docker and CI.

Published

Data futura

Reading Time

19 min

On November 11, 2026 the Node.js project published the security releases 22.23.5, 24.22.3 and 26.13.1, which fix 16 Node.js vulnerabilities: 7 high, 6 medium and 3 low severity. Almost all of them live in two modules every web server relies on, HTTP/2 and TLS, the encryption behind HTTPS.

Five reports carry an unusual signature: the official blog thanks Chris Rohlf "in collaboration with Claude and Anthropic Research". For developers, though, the news is a single one: if your server runs an earlier version, it must be updated and restarted.

In this guide we look at what the releases fix, how the most serious flaw works, who found the bugs and how, how to check the version that actually runs, and how to update Node with nvm, Docker and CI.

What the November 11, 2026 Node.js security releases fix

The November 11, 2026 security releases fix 16 vulnerabilities across all three Node.js release lines that are still supported: 22, 24 and 26. The 7 high-severity issues affect HTTP/2 and TLS and, in almost every case, can be triggered remotely without authentication.

Affected lines vary from flaw to flaw: some exist only in 24 and 26, others in 22 as well. That is why the project's advice applies to everyone: move to the latest version of your line. Here are the seven high-severity ones:

The 7 high-severity Node.js vulnerabilities fixed on November 11, 2026
CVE	Module	What it allows	Lines
CVE-2026-123863	HTTP/2	An unauthenticated client terminates the server	24, 26
CVE-2026-123864	HTTPS	Reading memory of other connections	22, 24, 26
CVE-2026-123865	HTTP/2	Sessions never cleaned up: memory and open files stay in use	22, 24, 26
CVE-2026-123866	HTTP/2	Sending already freed response memory to the client	22, 24, 26
CVE-2026-126051	TLS	Terminating a TLS server during the handshake	24, 26
CVE-2026-123872	TLS 1.2	Switching host during renegotiation to bypass client certificates	22, 24, 26
CVE-2026-123874	HTTP/2	Corrupting server memory through respondWithFile()	24, 26

Some dependencies were updated along with the fixes: llhttp 9.4.4, the Node HTTP parser, on every line; undici, the HTTP client behind fetch(), on 24 and 26; sqlite on 22 and 24.

16 or 17?

The security blog lists 16 CVEs, while the release notes list 17 (the extra one is CVE-2026-123873, low severity, in the Permission Model). This article uses the blog count, the same one used by the security press.

The most serious flaw: reading memory from other HTTPS connections

CVE-2026-123864 lets an unauthenticated client read memory belonging to other connections, including TLS private keys and other users' requests. It affects HTTPS servers on Node 22, 24 and 26; the cleartext HTTP server, node:http, is not affected.

How it works under the hood

The heap is the memory where the Node process keeps request data. The problem comes from re-entrancy: a function is called again while it is still running.

When JavaScript code, while the body of a request is being read, triggers a zero-byte TLS write, Node immediately decrypts the next TLS record. The HTTP parser, llhttp_execute(), then restarts while it is still in the middle of the body. The result is a use-after-free, the use of memory that was already released, with an out-of-bounds heap read: the server copies that memory into the request body.

No exotic code is needed: two common calls in the same handler and a route that echoes or stores the body are enough.

How to recognize an exposed handler

According to the advisory, the conditions are a handler that calls res.flushHeaders() before the body has ended and later closes with res.end() passing some data. Here is the pattern, a simple "echo" server:

JavaScript

// server.mjs
import https from 'node:https';
import { readFileSync } from 'node:fs';

const options = {
  key: readFileSync('key.pem'),
  cert: readFileSync('cert.pem'),
};

https
  .createServer(options, (req, res) => {
    res.flushHeaders(); // ⚠️ headers sent before the body has ended
    const parts = [];
    req.on('data', (chunk) => parts.push(chunk));
    req.on('end', () => {
      res.end(Buffer.concat(parts)); // ⚠️ end() with data: echoes the body
    });
  })
  .listen(8443);

JavaScript

// server.mjs
import https from 'node:https';
import { readFileSync } from 'node:fs';

const options = {
  key: readFileSync('key.pem'),
  cert: readFileSync('cert.pem'),
};

https
  .createServer(options, (req, res) => {
    res.flushHeaders(); // ⚠️ headers sent before the body has ended
    const parts = [];
    req.on('data', (chunk) => parts.push(chunk));
    req.on('end', () => {
      res.end(Buffer.concat(parts)); // ⚠️ end() with data: echoes the body
    });
  })
  .listen(8443);

flushHeaders() sends the headers right away instead of waiting for the first chunk of the response: it is useful, for example, when the response is slow to arrive. The code is correct and legitimate: the flaw is in Node, not here. But if your project has a similar pattern over HTTPS, the update cannot wait.

Should TLS keys be rotated?

The advisory does not say. If a server with this pattern was exposed to the Internet, discuss with whoever owns security whether to rotate keys and secrets after updating.

HTTP/2: four high-severity flaws that crash or drain a server

Four of the seven high-severity vulnerabilities are in the node:http2 module. They can be triggered remotely without authentication and, in several cases, default settings are enough.

CVE-2026-123863: a handler that responds before the body ends, a typical case, is enough to fail an internal check and terminate the process
CVE-2026-123865: a protocol error during shutdown leaves the session dangling, with memory and sockets never released
CVE-2026-123866: if a stream is closed while a write is waiting, the server can send already freed memory
CVE-2026-123874: with respondWithFile() or respondWithFD() a client can make the server use an already freed object

respondWithFile() is the node:http2 method that sends a file as the response. The medium-severity CVE-2026-123875 involves it too: cancelling a few downloads is enough to crash the server.

Two of these flaws, 123863 and 123865, are incomplete fixes of problems already patched: CVE-2024-27983 and CVE-2026-48937. It is a common pattern with memory bugs: a fix covers the reported case, but not every path that leads to the same state.

TLS and client certificates: when authentication is not enough

Four flaws involve TLS. Three affect mTLS (mutual TLS), the setup where the client also presents a certificate to identify itself: they matter if you apply different rules to different hosts on the same server. The fourth crashes the server during the handshake.

CVE-2026-123872 (high): with TLS 1.2 a client authorized for one host can renegotiate under another name and carry its authentication along
CVE-2026-123867 (medium): a per-host context with only a client CA and no server certificate falls back to the default CA
CVE-2026-123877 (medium): https.Agent reuses a TLS session between a request without ca and one with ca: []
CVE-2026-126051 (high): with hooks such as SNICallback, a client can terminate the server during the handshake

Among the medium ones there is also CVE-2026-123871: in four ERR_PROXY_INVALID_CONFIG error messages the proxy URL ended up in the logs with username and password.

Who found them: Chris Rohlf, Claude and Anthropic Research

Five of the 16 reports carry the same sentence on the Node.js blog: "Thank you, to Chris Rohlf in collaboration with Claude and Anthropic Research for reporting this vulnerability". Three are high severity (123863, 123864, 123874), one medium (123875) and one low (123862, in zlib).

This fact deserves a precise reading. In the official credits the reporter is a person, who worked with Anthropic's model. The fixes were written by Matteo Collina, a member of the Node.js Technical Steering Committee, and the releases were prepared by the project team. AI helped find the bugs; verifying, fixing and shipping them is still human work.

The other 11 reports come from different researchers: Tim Perry (pimterry) signs three, while Trail of Bits, credited together with OpenAI, signs a Permission Model flaw.

How a vulnerability reaches a release

The path is described in the Node.js security policy (SECURITY.md):

Private report: via HackerOne, usually acknowledged within 5 days
Validation: the issue is checked against every supported version
Private fix: patches stay out of the public repository until the announcement
Embargo and CVE: a date is chosen, typically 72 hours after the CVE is issued
Publication: releases, mailing list announcement and blog post

How to check the Node.js version that actually runs

To know whether you are exposed, check the Node version that runs the server, not just the one on your laptop. The fixed versions are 26.13.1, 24.22.3 and 22.23.5, or later on the same line.

The basic check is one command:

Terminal

# terminal
node -v
# v22.23.4 → needs updating

Terminal

# terminal
node -v
# v22.23.4 → needs updating

The catch is that the local version often differs from production. Also check:

Docker images: the tag in the Dockerfile, for example node:26 or node:24-alpine
CI: the version set in the pipeline
Hosting: the version chosen in the dashboard or configuration file
.nvmrc: the file that pins the project version

A script that stops CI on an old version

So you do not have to rely on memory, you can make CI fail when the version predates the fixes. This script uses process.versions.node:

JavaScript

// scripts/check-node.mjs
// Minimum versions with the November 11, 2026 fixes
const MINIMUM = { 22: '22.23.5', 24: '24.22.3', 26: '26.13.1' };

const current = process.versions.node; // e.g. "22.23.4"
const [major] = current.split('.').map(Number);
const minimum = MINIMUM[major];

if (!minimum) {
  console.error(`Node ${current}: unsupported line, upgrade to 26`);
  process.exit(1);
}

const compare = (a, b) => {
  const x = a.split('.').map(Number);
  const y = b.split('.').map(Number);
  for (let i = 0; i < 3; i++) if (x[i] !== y[i]) return x[i] - y[i];
  return 0;
};

if (compare(current, minimum) < 0) {
  console.error(`Node ${current}: update to at least ${minimum}`);
  process.exit(1);
}
console.log(`Node ${current}: ok`);

JavaScript

// scripts/check-node.mjs
// Minimum versions with the November 11, 2026 fixes
const MINIMUM = { 22: '22.23.5', 24: '24.22.3', 26: '26.13.1' };

const current = process.versions.node; // e.g. "22.23.4"
const [major] = current.split('.').map(Number);
const minimum = MINIMUM[major];

if (!minimum) {
  console.error(`Node ${current}: unsupported line, upgrade to 26`);
  process.exit(1);
}

const compare = (a, b) => {
  const x = a.split('.').map(Number);
  const y = b.split('.').map(Number);
  for (let i = 0; i < 3; i++) if (x[i] !== y[i]) return x[i] - y[i];
  return 0;
};

if (compare(current, minimum) < 0) {
  console.error(`Node ${current}: update to at least ${minimum}`);
  process.exit(1);
}
console.log(`Node ${current}: ok`);

On Node 22.23.4 the script prints "update to at least 22.23.5" and exits with code 1, so the pipeline stops. On Node 20 or 25 it reports the unsupported line. At the next security release you only need to update the MINIMUM object.

How to update Node.js with nvm, Docker and CI

Updating Node.js means installing the latest version of your line, updating every place where the version is written and restarting the processes. As long as a process stays up, it keeps using the old runtime.

With nvm

With nvm, the most widely used Node version manager, you install the version and make it the default for new shells:

Terminal

# terminal
nvm install 26.13.1
nvm alias default 26.13.1
node -v   # v26.13.1

Terminal

# terminal
nvm install 26.13.1
nvm alias default 26.13.1
node -v   # v26.13.1

If the project has an .nvmrc file, update it with the new version: nvm use and nvm install read it when you do not pass a version.

With Docker

The official images already have tags with the fixed versions, for example node:26.13.1-alpine, node:24.22.3-alpine and node:22.23.5-alpine. You can check the version inside an image like this:

Terminal

# terminal
docker pull node:26.13.1-alpine
docker run --rm node:26.13.1-alpine node -v

Terminal

# terminal
docker pull node:26.13.1-alpine
docker run --rm node:26.13.1-alpine node -v

If the Dockerfile uses a generic tag such as node:26, rebuilding the image pulls the latest 26. With an exact tag the change is explicit and visible in code review.

With package.json

The engines field declares the Node versions the project works with:

JSON

{
  "engines": {
    "node": ">=26.13.1 <27"
  }
}

JSON

{
  "engines": {
    "node": ">=26.13.1 <27"
  }
}

Careful: according to the npm documentation, without the engine-strict option the field only produces warnings. To actually block an old version you need the check script or a version pinned in CI.

Node 20 and 25: what to do on an end-of-life line

If you use Node 20 or Node 25 you will not receive any fix. Node 20 reached end of life on April 30, 2026, Node 25 on June 1, 2026. The advisory is explicit: end-of-life versions are always affected when a security release ships.

Status of the Node.js release lines in November 2026
Line	Status	Fixed version
Node 26	Active LTS	26.13.1
Node 24	Maintenance LTS	24.22.3
Node 22	Maintenance LTS, until April 2027	22.23.5
Node 20 and 25	End of life	None: switch line

If you are starting from Node 20, the longest-lived choice is Node 26, supported until April 2029. Jumping several major versions needs testing: the breaking changes of each major are in the release notes.

Frequently asked questions about the November 2026 Node.js vulnerabilities

I only use HTTP/1.1 without TLS: do I need to update?

Yes. The most serious flaw affects HTTPS and many others affect HTTP/2, but the same release also fixes zlib, proxy error messages and the Permission Model. And every future security release builds on this one: falling behind makes later updates harder.

Is updating dependencies with npm update enough?

No. The flaws are in the Node runtime, not in npm packages. npm update does not change your Node version: you need to install the new version and restart the processes.

Are the flaws already being exploited?

The official advisory does not mention active attacks. It does not say the opposite either: so the usual rule applies, update as soon as possible, starting with servers exposed to the Internet.

Which bugs did Claude find?

Five, reported by Chris Rohlf with Claude and Anthropic Research: CVE-2026-123863, 123864 and 123874 high severity, 123875 medium and 123862 low. Four are in HTTP/2 and HTTPS, one in zlib.

Conclusion

The Node.js vulnerabilities fixed on November 11, 2026 are many and some are serious, but the answer is simple and has no alternative: update your line and restart. That five reports came out of work with an AI model says a lot about how bug hunting is changing; the rest of the path, fixing and shipping, is the same as ever.

Update: 26.13.1, 24.22.3 or 22.23.5, or later
Restart: the fix only applies to processes started afterwards
Check everywhere: laptop, Docker, CI, hosting and .nvmrc
Block old versions: a CI script costs a few lines
Leave end-of-life lines: Node 20 and 25 no longer get patches

If Node is new to you, start with what Node.js is and how it works. To see a Node.js server in action there is the guide to building a real-time chat with Node.js, while the case of X and streaming SSR with React shows how much work a Node server does in production.

Which Node version runs your project in production, and how long does it take you to update it? Share your experience in the comments!

Sources

Node.js — November 11, 2026 Security Releases: the official advisory with every CVE, the affected lines and the credits
Node.js 26.13.1 (LTS): release notes with the fixes and updated dependencies
Node.js 24.22.3 (LTS) and Node.js 22.23.5 (LTS): release notes of the other two lines
Node.js Release schedule: status and end-of-life dates of every line
Node.js security policy: how to report a vulnerability and how the embargo works
nvm: installing and using the version manager