CVE-2026-48937

What it actually does

The flaw affects the Node.js HTTP/2 server implementation in the supported Node.js 22 and Node.js 24 release lines. After a server sends an HTTP/2 GOAWAY frame to signal that a connection should be winding down and no new streams should be accepted, the server may continue accepting data on that connection. An unauthenticated remote client can abuse this behavior to keep server-side HTTP/2 sessions active and consume connection, memory, CPU, or application-processing resources longer than intended. The impact is availability degradation rather than data theft or data modification.

Why it matters to the business

Public-facing services built on affected Node.js 22 or Node.js 24 HTTP/2 servers may be more susceptible to low-complexity denial-of-service activity. Successful exploitation could cause degraded response times, worker exhaustion, elevated infrastructure costs, or partial service outages. The CVSS score indicates moderate severity, EPSS is currently low, and the issue is not listed in CISA KEV, so this should be prioritized based on exposure: internet-facing HTTP/2 Node.js services should be patched promptly, while internal-only services can follow standard patch cycles with monitoring.

How an attack unfolds

An attacker connects to a Node.js service over HTTP/2 and causes or waits for the server to send a GOAWAY frame, which normally tells the peer that the connection is closing or will not accept additional streams. Instead of stopping interaction as expected, the attacker continues sending HTTP/2 data on the same connection. Because the vulnerable server can continue accepting that data, the attacker can repeat this across many connections or streams to hold resources open and increase server workload. At scale, this can reduce available capacity for legitimate users, especially where connection limits, reverse-proxy protections, or application-level request timeouts are weak.

How to fix it

Upgrade affected Node.js 22 and Node.js 24 deployments to a vendor-provided patched release once available for the relevant release line. Where exact fixed versions are not provided in the advisory data, track the official Node.js security releases and update all runtimes, containers, base images, buildpacks, and serverless/runtime images that package Node.js. If immediate upgrade is not possible, reduce exposure by disabling HTTP/2 where it is not required, terminating HTTP/2 at a patched reverse proxy or load balancer, enforcing strict connection and stream limits, applying idle/read timeouts, limiting request body size and rate, and using DDoS or WAF controls capable of HTTP/2-aware rate limiting. Ensure application dependencies and deployment images do not pin vulnerable Node.js 22 or 24 patch versions.

How to confirm the fix worked

Confirm the runtime version used in production, containers, CI images, and packaged applications with `node --version` and compare it against the Node.js security advisory fixed versions for the active release line. Validate that internet-facing endpoints either run a patched Node.js release or do not expose HTTP/2 directly. From the network edge, verify whether ALPN negotiates `h2` and confirm that reverse proxies or load balancers enforce connection, stream, and idle-timeout limits. In a non-production test environment, reproduce expected GOAWAY behavior and confirm that data sent after GOAWAY is rejected, ignored, or the connection is closed rather than processed. Monitor after patching for reduced long-lived HTTP/2 sessions and absence of post-GOAWAY DATA-frame handling.

Typical attack path

1. Identify a Node.js-backed service that accepts HTTP/2 traffic, typically over TLS using ALPN h2.
2. Open one or more HTTP/2 connections to the target service.
3. Trigger normal connection wind-down behavior or wait for the server to send a GOAWAY frame.
4. Continue sending HTTP/2 data after the GOAWAY frame instead of closing the connection.
5. Repeat the behavior across multiple connections to consume server resources.
6. Sustain the traffic until legitimate requests experience latency, errors, or service unavailability.

How to detect it

Look for signs of resource-exhaustion attempts against HTTP/2 endpoints rather than file-system artifacts, since exploitation does not require writing files or running commands. Useful telemetry includes load balancer and reverse-proxy access logs, HTTP/2 frame-level logs if available, Node.js application logs, APM traces, connection metrics, CPU and memory metrics, and DDoS/WAF events. Investigate spikes in long-lived HTTP/2 connections, connections where GOAWAY is followed by additional DATA frames, repeated stream resets, elevated concurrent session counts from a small set of client IPs, increased event-loop lag, memory growth, worker restarts, 502/503/504 responses, and traffic patterns where request volume is modest but connection duration and server resource use are high. Because generic Node.js does not emit a universal exploitation log line, prioritize behavioral detections at the proxy, packet-capture, or HTTP/2 telemetry layer.

• HTTP/2 DATA frames observed after GOAWAY on the same connection
• GOAWAY followed by DATA on same HTTP/2 session
• ALPN=h2 with unusually long-lived connections
• ERR_HTTP2_GOAWAY_SESSION
• ERR_HTTP2_INVALID_SESSION
• ERR_HTTP2_STREAM_ERROR
• HTTP/2 connection duration spike
• HTTP/2 concurrent streams spike
• HTTP/2 sessions with repeated GOAWAY frames
• 503 Service Unavailable during HTTP/2 connection surge
• 504 Gateway Timeout during HTTP/2 connection surge

What your security team should do

• Inventory all services using Node.js 22 or Node.js 24 and determine which ones expose HTTP/2 to untrusted networks.
• Prioritize patching or compensating controls for internet-facing Node.js HTTP/2 services, API gateways, and high-traffic applications.
• Update Node.js runtimes, container base images, buildpacks, and deployment artifacts to patched vendor releases as soon as available.
• If patching is delayed, disable direct HTTP/2 support or terminate HTTP/2 at a hardened and patched proxy with strict connection controls.
• Add HTTP/2-aware monitoring for unusually long-lived sessions, high concurrent stream counts, excessive DATA frames, and traffic continuing after GOAWAY.
• Review load balancer, reverse proxy, and application timeout settings to ensure idle, read, body-size, and connection-duration limits are enforced.
• Prepare operational runbooks for temporarily rate-limiting or blocking abusive HTTP/2 clients during service degradation.