> ## Content Index > Fetch the complete content index at: https://cms.thedarkwebnews.com/llms.txt > Use this file to discover other available public pages before exploring further. # Node.js Fixes 16 Vulnerabilities, Including HTTP/2 Crash and HTTPS Memory Leak That Can Expose TLS Private Keys - URL: https://cms.thedarkwebnews.com/node-js-fixes-16-vulnerabilities-including-http-2-crash-and-https-memory-leak-that-can-expose-tls-private-keys/ - Published: 2026-11-12T08:46:19.000Z - Updated: 2026-11-12T08:46:19.000Z - Author: Darkintel Team - Tags: Vulnerability, Patch The Node.js project has released security updates that fix 16 vulnerabilities in the runtime, seven of them rated high. The most serious flaws are in Node.js’s built-in HTTP/2, HTTPS, and TLS server code. They let unauthenticated clients crash servers, corrupt memory, or read memory from other connections, which can include TLS private keys and other users’ requests. Fixed versions are available for all three supported release lines: **22.23.5**, **24.22.3**, and **26.13.1**. **HTTP/2 crash (CVE-2026-123863)** An unauthenticated client can crash a Node.js server that uses the built-in HTTP/2 support on the 24.x and 26.x lines. The only condition is a default HTTP/2 server that replies before the request body has fully arrived, which the Node.js project describes as typical behavior. The attack works over both TLS and cleartext connections. **HTTP/2 memory disclosure (CVE-2026-123866)** A second HTTP/2 flaw can make a server send a client pieces of its memory, including responses meant for other connections. It affects all three supported lines. From 24.22.0 and 26.9.0 onward, a client alone can trigger it. On 22.x and older 24.x and 26.x builds, it can still be triggered when the server itself closes a stream partway through a response, for example after an idle timeout. **HTTPS memory leak exposing TLS keys (CVE-2026-123864)** A separate flaw in Node.js HTTPS servers can let an unauthenticated client read memory from other connections. According to the project, this can include TLS private keys and other users’ requests. It affects all three supported lines. Exploitation requires a request handler that calls `res.flushHeaders()` before the request body has fully arrived 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. Plain HTTP servers built with `node:http` are not affected. **Other high-severity flaws** | CVE | Severity | Impact | Affected lines | Conditions | | --------------- | -------- | ---------------------------------------------------------------------------------------------------------- | ---------------- | --------------------------------------------------------------------------------------------------- | | CVE-2026-123865 | High | Client makes the server hold memory and file descriptors permanently | 22.x, 24.x, 26.x | Any default HTTP/2 server | | CVE-2026-123874 | High | Client can corrupt server memory | 24.x, 26.x | Server sends files with stream.respondWithFile() or stream.respondWithFD() | | CVE-2026-123875 | Medium | Canceling file downloads can crash the server | 22.x, 24.x, 26.x | Same file-serving functions as above | | CVE-2026-126051 | High | Client can crash a TLS server | 24.x, 26.x | Server uses the SNICallback, OCSPRequest, newSession or resumeSession hooks, or server.addContext() | | CVE-2026-123872 | High | Client approved for one hostname can switch to a stricter one without meeting its client-certificate rules | 22.x, 24.x, 26.x | TLS server with stricter client-certificate rules for some hostnames, during TLS 1.2 renegotiation | **Who should be concerned** All eight flaws above are in Node.js’s own HTTP/2, HTTPS, and TLS server code. They matter most where a Node.js process accepts these connections directly, rather than sitting behind a reverse proxy or load balancer that terminates TLS and HTTP/2\. Node.js powers a huge number of web applications and APIs, so organizations should check exposure across their whole fleet. **No workaround, and end-of-life versions stay vulnerable** The advisory’s only fix is to update to the patched version for each line, and it lists no workaround for servers that can’t update yet. End-of-life lines, including **20.x** and **25.x**, get no fixes, and the project says such versions are always affected. Organizations still running them should plan to migrate to a supported line. **Exploitation status** The advisory does not report any attacks using these flaws. It also doesn’t say whether servers that met the conditions for the HTTPS flaw (CVE-2026-123864) should replace their TLS keys or other secrets after updating. **Discovery** According to the advisory, five of the flaws, including CVE-2026-123863 and CVE-2026-123864, were reported by Chris Rohlf in collaboration with Claude and Anthropic Research. **Recommendations** - Update to **Node.js 22.23.5, 24.22.3, or 26.13.1**, depending on your release line. - Migrate any services still running end-of-life versions (20.x, 25.x, or older) to a supported line. - First prioritize internet-facing Node.js services that terminate HTTP/2 or HTTPS/TLS connections themselves. - Check your code for HTTPS handlers that call `res.flushHeaders()` before the request body has fully arrived. If any such server was exposed, consider rotating its TLS private keys and other secrets as a precaution after updating. - Review TLS servers that use per-hostname client-certificate rules, SNI callbacks, or session-resumption hooks, and HTTP/2 servers that serve files with `respondWithFile()` or `respondWithFD()`. - Rebuild and redeploy container images and bundled applications that ship their own Node.js runtime, since updating the host system alone won’t patch them. We will update this post if active exploitation is reported.