nodejs Node.js HTTP/2 memory accounting flaw enables remote memory exhaustion

A flaw in Node.js HTTP/2 handling can cause HTTP/2 retained header blocks evade maxSessionMemory and enable remote memory exhaustion. This vulnerability affects Node.js 24.x and 22.x.

• nodejs Node.js 24.18.0 and versions less than or equal to 24.18.0 are identified by the CNA as affected. The corresponding upstream release containing the fix is 24.18.1.
• nodejs Node.js 22.23.1 and versions less than or equal to 22.23.1 are identified by the CNA as affected. The corresponding upstream release containing the fix is 22.23.2.
• The affected data sets the default status to unaffected outside the listed ranges, but it does not independently establish the boundaries of every downstream package or custom build.

The affected component is Node.js HTTP/2 handling. During HTTP/2 session processing, retained header blocks can evade maxSessionMemory accounting, allowing memory associated with a session to exceed the intended limit. This is an uncontrolled resource consumption weakness consistent with CWE-400. The confirmed precondition is network reachability to a service that processes HTTP/2; the record does not establish the exact frame sequence, header pattern, or internal allocation path, so those implementation details remain unknown.

The flaw is network-reachable against Node.js services that process HTTP/2. The supplied assessment indicates that authentication and user interaction are not required and that attack complexity is low. Exploitation is not established in the supplied record; the available CISA assessment records exploitation as none, while public_exploit is marked false. This describes the current evidence and does not prove that every environment is free from targeting.

A remote attacker may cause retained header blocks in an HTTP/2 session to escape the intended memory accounting. The resulting technical effect may be unexpected memory consumption, degraded service, or interruption of the Node.js process and workloads sharing the host. The available record limits the confirmed impact to availability and provides no evidence that the flaw directly enables data access or data modification. Actual severity for an environment depends on whether HTTP/2 is enabled and exposed, as well as the memory limits assigned to the workload.

The flaw can cause a Node.js process to consume more memory than intended for an HTTP/2 session. Possible consequences include degraded performance, worker restarts, or service interruption when available memory is exhausted. Internet-facing HTTP/2 services may therefore affect the availability of APIs, gateways, or dependent applications. The available evidence concerns availability and does not confirm data disclosure or data modification.

1. Upgrade affected deployments to Node.js 24.18.1 for the 24.x branch, or Node.js 22.23.2 for the 22.x branch. These are the upstream security releases identified as containing the fix for this issue.
2. Restart or replace long-running Node.js processes so the corrected code is loaded by the runtime serving HTTP/2.
3. If Node.js is supplied by an operating-system vendor or another distributor, apply its corresponding security update and verify the package mapping in that distribution. Upstream version numbers do not by themselves establish downstream package boundaries.
4. If immediate patching is not possible, temporarily reduce exposure of affected HTTP/2 services as a risk-reduction measure. The record provides no vendor-confirmed workaround, so this should not be treated as a fix.

1. Inventory deployed Node.js runtimes and identify processes that expose HTTP/2 endpoints or accept HTTP/2 sessions.
2. Compare the runtime version in use with the affected and fixed branch boundaries listed in affected_summary.
3. Prioritize review of HTTP/2 services reachable from the Internet and operating without authentication.
4. Review memory telemetry for unusual process growth, memory pressure, or worker restarts during HTTP/2 traffic. Treat this as precautionary monitoring, not as a confirmed indicator of compromise.
5. After updating, verify through runtime or software inventory that the process actually serving HTTP/2 is running a fixed release. The available record provides no named log signature or IOC.