CVE-2026-48619

What it actually does

This vulnerability affects Node.js applications that act as HTTP/2 clients. A malicious or compromised HTTP/2 server can send an excessive number of ORIGIN frames to the Node.js client. Because the client does not sufficiently limit or bound processing of these frames, memory consumption can grow until the Node.js process encounters an out-of-memory condition and terminates. The impact is denial of service: confidentiality and integrity are not directly affected, but application availability can be lost if the vulnerable client process crashes or becomes unstable.

Why it matters to the business

Applications built on affected Node.js 22, 24, or 26 releases may be crashed remotely if they connect to a malicious, compromised, or attacker-controlled HTTP/2 endpoint. This can interrupt API integrations, background workers, proxies, data ingestion jobs, service-to-service communication, or customer-facing functionality that depends on outbound HTTP/2 connections. The CVSS score is high for availability impact, but EPSS is currently low and there is no known KEV listing or reported ransomware use, so remediation should be prioritized for internet-connected services and workloads that make HTTP/2 requests to untrusted or third-party servers.

How an attack unfolds

An attacker must be able to make a vulnerable Node.js application establish an HTTP/2 client connection to a server the attacker controls or has compromised. Once the Node.js client connects, the server repeatedly sends ORIGIN frames. The vulnerable client continues processing or retaining frame-related state without an effective limit, causing memory usage to increase. Eventually the process exhausts available memory or reaches its configured V8 heap limit, resulting in fatal allocation errors, process termination, container restarts, worker crashes, or degraded service availability. Exploitation does not require authentication against the Node.js application itself, but it does require influence over the HTTP/2 server endpoint the application connects to or the ability to compromise such an endpoint.

How to fix it

Upgrade affected Node.js runtimes in the Node.js 22, Node.js 24, and Node.js 26 release lines to vendor-fixed versions as soon as patched builds are available from the Node.js project or operating system/package maintainers. No exact fixed versions were provided in the input, so track the official Node.js security release notes and downstream distribution advisories for the corrected versions. As interim mitigations, avoid making HTTP/2 client connections to untrusted endpoints, disable HTTP/2 for outbound client traffic where feasible, prefer HTTP/1.1 for affected integrations, restrict egress to known trusted destinations, and apply process/container memory limits with supervised restarts to reduce blast radius. Where application logic allows, validate and pin outbound destinations rather than accepting arbitrary URLs or redirects that could lead clients to attacker-controlled HTTP/2 servers.

How to confirm the fix worked

Confirm all deployed Node.js runtimes are outside the affected builds in the Node.js 22, 24, and 26 lines once fixed versions are published. Inventory runtime versions using commands such as `node --version`, container image manifests, package manager metadata, CI build outputs, and software composition analysis results. Review application dependencies and code paths that use Node.js HTTP/2 client functionality, including direct use of the `http2` module and frameworks or SDKs that may negotiate HTTP/2 under the hood. Validate mitigation by ensuring outbound HTTP/2 is disabled or restricted where intended, egress policies block untrusted destinations, and vulnerable runtime images are no longer present in registries or deployment manifests. In staging, controlled testing can confirm that malformed or excessive ORIGIN frames no longer cause unbounded memory growth or process termination.

Typical attack path

1. Identify or induce a Node.js application to make outbound HTTP/2 client requests to an attacker-controlled or compromised server.
2. Accept the HTTP/2 connection from the vulnerable Node.js client.
3. Send an excessive or continuous stream of HTTP/2 ORIGIN frames.
4. Force the client process to allocate increasing memory while handling the frames.
5. Trigger an out-of-memory condition, process crash, restart loop, or service degradation.
6. Repeat the behavior to sustain denial of service if the application automatically reconnects or restarts.

How to detect it

To determine whether exploitation may have occurred, review application logs, process supervisor logs, container runtime events, system journals, crash dumps, APM telemetry, and network egress records for Node.js processes that experienced sudden memory growth or out-of-memory termination after outbound HTTP/2 connections. Focus on timelines where a Node.js service connected to unusual, newly seen, third-party, or user-controlled destinations and then crashed or restarted. Look for V8 fatal heap errors, Linux OOM killer messages, Kubernetes OOMKilled events, container restart loops, and spikes in RSS/heap memory. Network telemetry that records HTTP/2 frame types may show unusually high counts of ORIGIN frames from a server to a client before failure. There are no known public threat actors or KEV exploitation reports for this vulnerability, so detection should emphasize behavioral evidence rather than actor-specific indicators.

• FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
• FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
• JavaScript heap out of memory
• Allocation failed - process out of memory
• Killed process node
• Out of memory: Killed process
• OOMKilled
• Reason: OOMKilled
• Exit Code: 137
• node --max-old-space-size
• HTTP2_SESSION_ERROR
• ERR_HTTP2_SESSION_ERROR
• ERR_HTTP2_GOAWAY_SESSION
• ORIGIN frame
• http2 origin
• process out of memory

What your security team should do

• Inventory Node.js 22, 24, and 26 deployments, including containers, serverless functions, build images, developer tooling, and embedded application runtimes.
• Prioritize remediation for services that initiate outbound HTTP/2 connections, especially to third-party, user-influenced, or internet-accessible destinations.
• Track official Node.js security releases and upgrade to the fixed versions immediately when available through upstream or distribution packages.
• Apply temporary mitigations by disabling outbound HTTP/2 where practical, restricting egress to approved destinations, and preventing user-controlled URL fetches from reaching arbitrary hosts.
• Ensure process supervisors, orchestration platforms, and containers enforce memory limits, restart policies, and alerting so exploitation results in contained failures rather than broader service outages.
• Monitor for Node.js out-of-memory crashes, abnormal memory growth, repeated restarts, and suspicious outbound HTTP/2 connections shortly before process failure.
• Add regression tests or dependency checks to prevent reintroduction of affected Node.js runtimes in CI/CD pipelines.