If your servers run Node.js and terminate HTTPS or HTTP/2 themselves, the security release of 11 November 2026 deserves a slot in this week's schedule. The Node.js project shipped fixes for all three supported release lines, and The Hacker News counts 16 vulnerabilities in this batch. Two groups stand out: bugs that crash the process, and bugs that make the server send another connection's data.

Which Node.js versions contain the fix

The fixed releases are 22.23.5, 24.22.3 and 26.13.1, covering the 22.x, 24.x and 26.x lines. The official advisory also lists bundled dependency updates: llhttp (22.x, 24.x, 26.x), undici (24.x, 26.x) and sqlite (22.x, 24.x).

If you still run a line older than 22.x, the advisory does not list it in this round. Check the support schedule in our post on Node.js 26 reaching LTS and the new release calendar to see whether your line is still maintained.

HTTP/2 flaws: one anonymous client can take a server down

CVE-2026-123863 (high) affects 24.x and 26.x. It needs nothing more than a default HTTP/2 server whose handler replies before the request body has fully arrived, a pattern Node.js itself calls typical. The attacker does not need to authenticate, and it works over both TLS and cleartext.

CVE-2026-123865 lets a client leak memory and file descriptors permanently: sockets sit in CLOSE_WAIT while HTTP/2 state stays in memory. The server does not fall over at once; it slowly runs out of resources, which makes it hard to spot from error logs alone.

There are also several use-after-free and buffer-overflow bugs in HTTP/2, including cases where an app uses respondWithFile() or respondWithFD() (CVE-2026-123874) or passes the :authority header to session.altsvc() (CVE-2026-123828).

Memory disclosure: a risk to user data

This group matters most to businesses. CVE-2026-123864 (high, affecting 22.x, 24.x and 26.x) lets an unauthenticated client read memory that belongs to other connections, which by the advisory's description can include TLS private keys and other users' requests. The conditions: a handler calls res.flushHeaders() before the request body ends, then calls res.end() with a non-empty chunk; reading the leaked memory also needs a route that echoes or stores a request body. Plain node:http is not affected.

CVE-2026-123866 can likewise make the server write freed memory, including other connections' response buffers, to a peer. If your system handles personal data, an incident like this is both a technical bug and a data breach. Sending less sensitive data through the application layer, for example by masking personal information early, limits the damage; our AI Masking solution is one option for that.

TLS: client-certificate checks can be bypassed

Two flaws concern per-hostname mutual TLS:

  • CVE-2026-123872: a client changes the servername during TLS 1.2 renegotiation and carries its authentication over to a more strictly protected host.
  • CVE-2026-123867: when server.addContext(host, { ca }) is called with a context that has no server certificate, the host-specific CA is never installed and the handshake falls back to the default CA.

Both matter only if one Node.js server applies different client-certificate policies to different hostnames. Separately, CVE-2026-126051 can crash the process on servers that use SNICallback, OCSPRequest, newSession, resumeSession or server.addContext().

Proxy credentials leaking into logs

CVE-2026-123871 (medium) is mundane but real: several ERR_PROXY_INVALID_CONFIG error paths print the raw proxy URL, username and password included. That message can reach stderr, container logs, log aggregation and crash-reporting services. If you configure proxies through environment variables, review old logs.

Checking your systems in one afternoon

Work through it in this order.

  1. Find the running version. On the host and inside containers:

```bash
node --version
docker exec <container-name> node --version
```

  1. Compare against the fixed releases. You need at least 22.23.5, 24.22.3 or 26.13.1, depending on your line.
  2. Check whether Node.js faces the internet directly. If Nginx or a load balancer already terminates TLS and HTTP/2, the attack surface shrinks considerably, but you should still update.
  3. Search your code for the affected features:

```bash
grep -rnE "node:http2|require\('http2'\)|respondWithFile|respondWithFD|altsvc|addContext|SNICallback|flushHeaders" src/
```

  1. Rebuild container images. Pin a specific tag, such as the 24 or 26 line, and build with --pull to fetch the new base layer. A long-running old image will not patch itself.
  2. Review logs. Search for ERR_PROXY_INVALID_CONFIG and rotate the proxy password if it ever appeared.
  3. Test before production. Run your suite, especially upload, streaming and file-download routes, then watch CLOSE_WAIT connection counts and RAM after rollout.

What about Next.js apps

Next.js runs on Node.js, so self-hosted servers need the runtime update. Most deployments put Nginx or another reverse proxy in front instead of exposing Node.js HTTP/2 directly, so the real exposure depends on your architecture. Even so, bumping the runtime is far cheaper than investigating a leak later.

Next step

List every Node.js service you run, note its line and version, and schedule upgrades by how exposed each one is. If you want a team to audit or operate this for you, see the Node.js and Next.js work on Besoft's projects page.

References

  • Node.js, "Wednesday, November 11, 2026 Security Releases" (11 Nov 2026): https://nodejs.org/en/blog/vulnerability/november-2026-security-releases
  • The Hacker News, "Node.js Fixes 16 Flaws, Including HTTP/2 Bugs That Crash Servers and Leak Other Connections' Data" (12 Nov 2026): https://thehackernews.com/2026/11/nodejs-fixes-16-flaws-including-http2.html