Node.js: HTTP/2 and HTTPS flaws let clients crash servers and read other users' data

What happened

On 11 November 2026 the Node.js project published security releases for its three supported release lines. The fixed versions are 22.23.5, 24.22.3 and 26.13.1. They fix 16 vulnerabilities in Node.js itself, and seven of them are rated high. The releases also update the bundled dependencies llhttp (22.x, 24.x, 26.x), undici (24.x, 26.x) and sqlite (22.x, 24.x).

The most important issues are in the server code that Node.js provides itself for HTTP/2, HTTPS and TLS:

• HTTP/2 server crash (24.x and 26.x): any unauthenticated client can make the Node.js process stop. The server only needs the default HTTP/2 setup and a handler that replies before the request body has fully arrived. The project calls this behaviour typical. The attack works over TLS and over cleartext connections.
• HTTP/2 memory disclosure (all three lines): a server can send a client pieces of its memory, including responses meant for other connections. From 24.22.0 and 26.9.0 onward, a client can trigger this on its own. On 22.x and older 24.x and 26.x builds, it can happen when the server closes a stream partway through a response, for example after an idle timeout.
• HTTPS memory disclosure (all three lines): an unauthenticated client can read memory from other connections, "including TLS private keys and other users' requests", according to the project. This requires a handler that calls res.flushHeaders() before the request body has ended and later calls res.end() with data. To read the leaked memory, the attacker also needs a route that sends back or stores a request body.
• HTTP/2 resource exhaustion (all three lines): a client can make any default HTTP/2 server hold memory and file descriptors permanently.
• HTTP/2 file serving (24.x and 26.x): a client can corrupt server memory when the server serves files with stream.respondWithFile() or stream.respondWithFD(). On all three lines, canceling such downloads can also crash the server (rated medium).
• TLS server crash (24.x and 26.x): a client can crash a TLS server that uses the SNICallback, OCSPRequest, newSession or resumeSession hooks, or server.addContext().
• TLS client-certificate bypass (all three lines): some servers apply stricter client-certificate rules to certain hostnames. On those servers, a client approved for another hostname can switch to a stricter one during TLS 1.2 renegotiation without meeting its rules.

The advisory reports no attacks using these flaws.

Who is affected

• Servers running Node.js 22.x before 22.23.5, 24.x before 24.22.3 or 26.x before 26.13.1.
• End-of-life lines, including 20.x and 25.x, get no fix in this release. The project says such versions are always affected.
• The serious server-side issues only matter where a Node.js process accepts HTTP/2, HTTPS or TLS connections itself. Examples are the built-in node:http2, node:https or node:tls modules, or frameworks that use them to terminate TLS or HTTP/2.
• Plain HTTP servers built with node:http are not affected by the HTTPS memory disclosure.
• The HTTP/2 crash affects only the 24.x and 26.x lines, not 22.x.

You are much less exposed if a reverse proxy such as nginx, Apache, HAProxy or a load balancer terminates TLS and HTTP/2, and Node.js only receives plain HTTP/1.1 from it. You should still update, because the release also contains other fixes and dependency updates.

What to do now

1. Find all Node.js installations. Remember system packages, version managers (nvm, n, Volta), Docker images, CI runners and hosting panels that ship their own Node.js.
2. Update to the fixed version of your line: 22.23.5, 24.22.3 or 26.13.1. If you use distribution or vendor packages (for example NodeSource or your Linux distribution), install the update as soon as your package source provides these versions.
3. Move off end-of-life versions. If you still run 20.x, 25.x or older, upgrade to a supported line. The advisory lists no workaround for servers that cannot update.
4. Rebuild container images with an updated Node.js base image and redeploy them. Updating the host alone does not change the Node.js inside containers.
5. Restart all Node.js processes (systemd units, PM2, Docker containers, etc.) so the new runtime is loaded. Then check that your applications respond normally.
6. Consider rotating secrets if you were exposed. The advisory does not say whether servers that met the conditions for the HTTPS memory disclosure should replace TLS keys or other secrets. If a Node.js HTTPS server of yours matched those conditions and was reachable from the internet, consider renewing its TLS certificate and key.

How to check whether you are affected

• Run node -v on each server, and inside each container (docker exec <container> node -v). Versions below 22.23.5, 24.22.3 or 26.13.1 in their line, or any end-of-life line such as 20.x or 25.x, are affected.
• With PM2, pm2 list and pm2 show <app> show which Node.js binary and version each app uses.
• Check whether your applications terminate HTTP/2 or TLS in Node.js themselves: search the code for http2.createSecureServer, http2.createServer, https.createServer, tls.createServer, respondWithFile, respondWithFD, SNICallback and addContext.
• Check your process manager and system logs for unexpected Node.js restarts or crashes. Repeated aborts of an HTTP/2 server can point to attempts to trigger the crash.

Sources

• https://thehackernews.com/2026/11/nodejs-fixes-16-flaws-including-http2.html