nodejs Node.js HTTP/2 re-entrant send can cause heap-use-after-free

A flaw in Node.js HTTP/2 handling allows nghttp2_session_mem_send() to be called re-entrantly while nghttp2_session_mem_recv() is executing, resulting in a heap-use-after-free. This vulnerability affects Node.js 26.x, 24.x, and 22.x.

nodejs Node.js is affected within these supported boundaries:

• 26.5.0 and earlier in the 26.x branch are affected. Node.js 26.5.1 is the corresponding security release.
• 24.18.0 and earlier in the 24.x branch are affected. Node.js 24.18.1 is the corresponding security release.
• 22.23.1 and earlier in the 22.x branch are affected. Node.js 22.23.2 is the corresponding security release.

The CNA data marks the default status as unaffected outside the listed affected boundaries. The Node.js advisory identifies all three active release lines as affected; no additional branch is established by this record.

Node.js HTTP/2 handling can permit nghttp2_session_mem_send() to be called re-entrantly while nghttp2_session_mem_recv() is executing. That overlap can leave the implementation using heap storage after it has been freed, which is the reported CWE-416 use-after-free condition. The supplied assessment establishes network reachability without authentication or user interaction, but it does not identify the exact attacker-controlled HTTP/2 input, frame sequence, endpoint, or callback path that causes the re-entry. The affected scope is the Node.js HTTP/2 subsystem in the three named release branches. The exact allocator state and whether exploitation always ends in a process crash are not established by the available evidence.

Exploitation is remotely reachable through the network according to the supplied assessment. It is described as requiring no authentication and no user interaction, with low attack complexity. The record does not document a public exploit, and the consulted CISA enrichment records exploitation as none. Those status fields do not prove that exploitation is impossible or that no activity occurred outside the recorded scope. The exact HTTP/2 request or frame sequence needed to trigger the condition is not public in the available evidence.

Successful triggering could cause invalid heap access and may terminate or destabilize the Node.js process. The practical technical consequence is loss of availability for the affected service, potentially requiring restart or failover. The supplied assessment indicates no confidentiality or integrity impact and unchanged security scope. It does not establish code execution, privilege escalation, data disclosure, or persistent compromise.

An affected Node.js process could become unstable or terminate when the vulnerable state is reached, causing service interruption for workloads that rely on it. This is primarily an availability concern; the supplied assessment identifies no confidentiality or integrity impact. Internet-facing or otherwise remotely reachable HTTP/2 services should be prioritized for inventory and patching. The available evidence does not establish data exposure, data modification, or a breach scenario.

1. Upgrade the 26.x branch to Node.js 26.5.1, the 24.x branch to 24.18.1, or the 22.x branch to 22.23.2, matching the branch in use.
2. Redeploy or restart services so running processes no longer use the affected runtime, then verify the active binary or package version against the fixed release for that branch.
3. If the upgrade must be staged, prioritize network-reachable HTTP/2 services and verify that no affected runtimes remain in production. The available evidence does not document a specific workaround that provides equivalent protection.

1. Inventory Node.js installations, container images, base images, and embedded runtimes, recording the exact runtime version for each deployment.
2. Compare each recorded version with the affected and fixed boundaries in the affected summary, including parallel release branches rather than assuming that a fix in one branch covers another.
3. Identify deployments that accept or process HTTP/2 traffic and map them to the runtime inventory so remotely reachable exposure is visible.
4. Review process-supervisor and application telemetry for unexpected Node.js exits, restarts, or heap-related failures associated with HTTP/2 traffic. Treat this as precautionary monitoring, not a confirmed indicator of this vulnerability; absence of such events does not prove safety.
5. After remediation, verify the running process version, not only the package or image tag.