- The Node.js project fixed 16 flaws, seven rated high. Several let an unauthenticated client crash a server or read other connections' memory.
- These are bugs in Node.js code, not risky settings. Two need little beyond a default HTTP/2 server; others depend on handler patterns or optional features.
- Update to 22.23.5, 24.22.3 or 26.13.1. The project lists no workaround, and it does not say whether to rotate TLS keys.
Familiar server behaviour, rarely reviewed
Settings get reviewed; handler behaviour often does not. That includes what a server does when a request arrives and the handler answers early. The Node.js project has fixed 16 vulnerabilities across its 22.x, 24.x and 26.x release lines. Several sit in server behaviour that looks ordinary.
These are bugs in Node.js code, not risky settings. A secure configuration does not remove them. Some need little beyond a default HTTP/2 server. Others also depend on how an application's handlers are written, or on optional features.
The lesson here is that exposure often hides in routine patterns that nobody thinks to audit. Patching is necessary. Knowing which of your services use those patterns tells you where to look first.
What the release contains
The Node.js project rates seven of the 16 flaws as high, six as medium and three as low. Fixed builds exist for each supported line: 22.23.5, 24.22.3 and 26.13.1.
CVE-2026-123863 is the clearest case, on 24.x and 26.x. The project says the trigger is a default HTTP/2 server that answers a request before the client has finished sending its body. It calls that behaviour typical. An unauthenticated client can then make the server abort, over encrypted or plain connections.
CVE-2026-123865 is also reachable on default HTTP/2 servers. A client can leave the server holding memory and open file descriptors for good, and the attacker spends nothing more to keep it that way. CVE-2026-123868 lets one connection tie up far more memory than it sends. The project says a peer pays about 10 bytes per frame while the server keeps about 114.
Other flaws need more. CVE-2026-123874 and CVE-2026-123875 apply to servers that serve files with respondWithFile() or respondWithFD(). CVE-2026-126051 applies to TLS servers using certain callback hooks or addContext(). CVE-2026-123828 requires an application to pass a request's :authority header into altsvc().
How the memory leaks work
Two flaws expose memory that belongs to other people. Both come from a program using memory after it has been released.
In CVE-2026-123864, the HTTPS code is asked to write zero bytes while the server is partway through reading a request. That call decrypts the next incoming record and re-enters the request parser. The server then copies stale or unrelated memory into the response. The project says this can include TLS private keys and other users' requests.
Two handler patterns must line up. The handler must send headers before the request body ends, then finish with data. A separate route must also send back or store a request body for the leak to be read. The project says servers built on plain node:http do not have this flaw.
In CVE-2026-123866, an HTTP/2 stream is closed while a write is still waiting. The response buffer is freed, but the code still points to it. Freed or unrelated memory goes to the socket instead of the response. On 24.x and 26.x builds with a window-size change introduced in 24.22.0 and 26.9.0, the project says a remote client can cause this alone. On every supported line, a server-side action such as a per-stream timeout can also cause it.
Three fixes that did not finish the job
Three entries in the advisory describe earlier repairs that left a gap. CVE-2026-123863 is a variant of CVE-2024-27983. The earlier fix covered only streams still tracked in the session.
CVE-2026-123865 is an incomplete fix of CVE-2026-48937. That repair caught some internal shutdowns but missed those that arrive while a session is already closing. The proxy-credential leak, CVE-2026-123871, follows CVE-2026-48615. That fix hid credentials in one place but missed four error paths.
This is one release, so it shows no wider trend. It does show how patching works in practice. A fix that closes the reported case can leave a nearby one open.
Per the advisory, Chris Rohlf, working with Claude and Anthropic Research, reported five of the issues. Those include CVE-2026-123863 and CVE-2026-123864.
Not only crashes
Two of the TLS flaws concern who is allowed in. CVE-2026-123872 affects servers that apply different client-certificate rules to different hostnames. A client approved for one host can switch hostnames during TLS 1.2 renegotiation and keep its approval. CVE-2026-123867 lets a client trusted by the default certificate authority reach a protected host in a specific setup.
A third, CVE-2026-123877, sits in the https.Agent client code. A cached TLS session approved under a broad trust policy can be reused by a later request that set a stricter one.
What the advisory leaves open
The project lists updating as the fix. The Hacker News reports that the advisory names no workaround for servers that cannot update. It also reports no attacks using these flaws.
The advisory does not say whether servers meeting the HTTPS flaw's conditions should replace TLS keys or other secrets after updating. That decision falls to each organization.
End-of-life lines get no fix. The Hacker News names 20.x and 25.x, and the project says such versions are affected whenever a security release occurs.
Questions to put to your team
Ask which of your services run Node.js directly as an HTTP/2, HTTPS or TLS server, rather than behind a proxy that terminates those connections. The server-side flaws sit in Node.js's own HTTP/2, HTTPS and TLS code, so that is where they matter.
The proxy-credential, https.Agent, zlib and Permission Model fixes are different. They apply wherever those features are used, including services that are not Node.js servers.
Ask which release line each service runs, and whether any is on 20.x or 25.x. Ask who owns the upgrade to 22.23.5, 24.22.3 or 26.13.1.
Ask whether any handler matches the HTTPS conditions: headers sent early, a body echoed back. If so, decide whether to rotate TLS keys. The advisory gives no guidance, so record the reasoning either way.
The patch is the easy part. The harder part is knowing which ordinary-looking server behaviour your services depend on.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Node.js project (OpenJS Foundation).
Follow this story: every update on Node.js security releases
