Node.js fixes 16 flaws, including remote HTTP/2 server crashes and an HTTPS bug that leaks other connections' memory

What happened

The Node.js project shipped security releases for its three supported lines on 11 November 2026: v26.13.1, v24.22.3 and v22.23.5. They fix 16 vulnerabilities - by Node.js's own ratings, seven high, six medium and three low. The previous security release came out on 21 October 2026.

Most of the bugs are in the built-in HTTP/2 support (the node:http2 module) and in TLS. The most common impact is a remote server crash without authentication, but several flaws also leak memory: the server sends a client chunks of memory that belong to other connections. The releases also update the bundled llhttp (all three lines), undici (24 and 26) and SQLite (22 and 24).

Five of the flaws were reported by Chris Rohlf in collaboration with Claude and Anthropic Research; others came from independent researchers and Trail of Bits. NVD published the records on the evening of 11 November 2026 in Received status, with CVSS 3.0 scores from the assigning CNA.

Technical details

The most serious high-severity flaws:

• CVE-2026-123864 is a re-entrancy bug in HTTPS request body parsing: a zero-length write triggers premature TLS record decryption, leading to a use-after-free and an out-of-bounds heap read. Node.js says it needs a specific combination: a handler that calls res.flushHeaders() before the request body ends, then res.end() with a non-empty chunk, plus any route that echoes or stores request bodies. Cleartext node:http is not affected.
• CVE-2026-123863 is a variant of the older CVE-2024-27983 that the original fix missed. An HTTP/2 stream still holding header buffers outlives its session, and a memory accounting assertion kills the process. No authentication is needed, and it works over both TLS and cleartext HTTP/2.
• CVE-2026-123872: during TLS 1.2 renegotiation a client can change the server name (SNI) and carry its existing authentication over to a host with a stricter client certificate policy.
• The other high-severity HTTP/2 bugs lead to use-after-free (CVE-2026-123866; CVE-2026-123874, where serving files with respondWithFile() or respondWithFD() is the only precondition) or gradual exhaustion of memory and file descriptors (CVE-2026-123865, an incomplete fix for CVE-2026-48937).

The medium-severity flaws include a certificate validation bypass in https.Agent through TLS session reuse (CVE-2026-123877), per-host CA overrides in server.addContext() failing open to the default CA (CVE-2026-123867), and proxy credentials leaking into error messages (CVE-2026-123871). Node.js has not published proof-of-concept code, and neither do we.

Who is affected

• Node.js 26.x before 26.13.1, 24.x before 24.22.3 and 22.x before 22.23.5. Some flaws (such as CVE-2026-123863 and CVE-2026-123874) affect only 24 and 26.
• The most exposed are internet-facing servers that handle HTTP/2 or HTTPS themselves - http2.createSecureServer(), http2.createServer(), https.createServer().
• End-of-Life versions are always affected, according to Node.js, and will not be fixed.

To quickly check your version and HTTP/2 usage:

node -v
grep -rnE "createSecureServer|http2\.createServer|respondWithFile|flushHeaders" --include=*.js --include=*.ts --exclude-dir=node_modules .

In Docker, the Node.js version comes from the image - check the tag (node:24, node:22-alpine and so on), pull it again and rebuild. For distribution packages, follow your distribution's security advisory.

How to tell if you were compromised

Node.js has not published indicators of compromise and does not mention exploitation. A few practical pointers:

• Repeated process crashes with assertion messages (CHECK_EQ, ERR_INTERNAL_ASSERTION) or restarts by your process manager (pm2, systemd, Kubernetes), especially alongside HTTP/2 traffic.
• A growing number of sockets in CLOSE_WAIT and rising memory use: ss -tan state close-wait | wc -l.
• You will not see the CVE-2026-123864 leak in your logs. If your app meets the conditions above and was reachable directly over HTTPS, assume data may have leaked.
• Pull suspicious IP addresses out of your logs with our IOC extractor - it runs entirely in your browser.

What to do

1. Upgrade to Node.js 26.13.1, 24.22.3 or 22.23.5 (or your distribution's fixed package) and restart every process - running apps stay vulnerable until they restart. Rebuild container images.
2. Confirm the version with node -v in production.
3. If your app meets the conditions for CVE-2026-123864 (HTTPS terminated in Node.js, res.flushHeaders() before the body ends, a route that echoes request bodies), rotate your TLS key after upgrading and get a new certificate. That is our recommendation, not a Node.js instruction.
4. Until you can deploy the update, it makes sense to let a reverse proxy (nginx, HAProxy, a CDN) terminate HTTPS and HTTP/2 and forward only HTTP/1.1 to Node.js. This too is our inference from the flaw descriptions - Node.js lists no workarounds.
5. Using mTLS (client certificates)? Review your server.addContext() setup and TLS 1.2 renegotiation - CVE-2026-123872 and CVE-2026-123867 apply to you.

Timeline

Updates

• 12 Nov 2026 - first version of this article.