CVE-2026-56848

Overview

Node.js is a JavaScript runtime built on the V8 JavaScript engine. It uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, and it is widely used to build scalable server-side and networking applications.

A use-after-free vulnerability (CVE-2026-56848) has been identified in the Node.js HTTP/2 implementation, where nghttp2_session_mem_send() can be called re-entrantly while nghttp2_session_mem_recv() is still executing. The nested call frees session state that the outer call is still using, producing a heap use-after-free. A remote attacker who can open an HTTP/2 connection to an affected server can trigger the condition and crash the process, causing a denial of service.

Per MITRE CWE-416: the product "reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation." Depending on what reoccupies the freed memory, the consequences range from a process crash to undefined behavior.

This issue affects all users on the active 22.x, 24.x, and 26.x release lines below the patched versions. Node.js states that End-of-Life versions are always affected when a security release occurs, and HeroDevs has confirmed the flaw reaches the End-of-Life 16.x, 18.x, and 20.x lines.

Details

Module Info

• Product: Node.js
• Affected packages: nodejs/node (the Node.js runtime itself)
• Affected versions:
  
  • 22.x <= 22.23.1
  • 24.x <= 24.18.0
  • 26.x <= 26.5.0
  • All End-of-Life release lines, including 16.x, 18.x, and 20.x
• GitHub repository: https://github.com/nodejs/node
• Published packages: https://github.com/nodejs/node/releases
• GitHub Security Advisory: GHSA-679w-638g-xf9h
• Package manager: n/a (Node.js ships as a runtime distribution rather than a registry package)
• Fixed in: Node.js NES v16.20.14, v18.20.19, and v20.20.4

Vulnerability Info

This High-severity vulnerability is found in the http2 module of the Node.js runtime, in every release below the patched version of each line.

Node.js implements HTTP/2 on top of the bundled nghttp2 library. Incoming bytes are handed to nghttp2_session_mem_recv(), which parses frames and fires callbacks back into Node.js as it goes. Once that call returns, Node.js calls nghttp2_session_mem_send() to collect the bytes the session wants to write back out. The library expects these two calls to run one after the other and does not support one being invoked from inside the other.

In affected versions, work performed by a callback during the receive call can start a send while the receive is still on the stack, for example when a stream is reset part-way through frame processing. The nested send tears down session state that the still-running receive call holds a pointer to, and the outer call then reads heap memory that has already been freed. Because HTTP/2 sessions are established by any client that connects, the sequence is reachable remotely without authentication or user interaction. The CVSS vector recorded by the Node.js project scores confidentiality and integrity impact as none and availability as high, so the demonstrated outcome is a crash of the Node.js process rather than data disclosure.

The upstream fix (commit daa6d25e3d, "http2: defer rst stream while in scope") defers the stream reset until the receive call has returned, so the send can no longer run nested inside it.

Note: The affected code path lives entirely in the http2 module, so applications that never create an HTTP/2 server or client session do not reach it.

Mitigation

The Node.js 16, 18, and 20 release lines are past their End-of-Life dates and will not receive an upstream fix for this issue. For more information see here.

Users of the affected components should apply one of the following mitigations:

• Upgrade to a currently supported Node.js release line at or above the patched version (22.23.2, 24.18.1, or 26.5.1).
• Migrate affected applications away from the End-of-Life Node.js release lines.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

• hahahkim (reporter)
• mcollina (remediation developer)