CVE-2026-56846

What it actually does

The vulnerability is a remote denial-of-service flaw in Node.js HTTP/2 processing affecting Node.js 22.x and 24.x. A remote, unauthenticated client can send crafted HTTP/2 traffic that causes retained header blocks to consume memory outside the intended maxSessionMemory accounting. Because the memory use is not properly bounded by the session memory limit, repeated or sustained requests can drive excessive process memory growth, eventually causing the Node.js process to slow, terminate from out-of-memory conditions, or be killed by the operating system/container runtime. The impact is availability only; the provided details do not indicate data disclosure or code execution.

Why it matters to the business

Public-facing services, APIs, gateways, and backend applications built on affected Node.js 22.x or 24.x versions may be taken offline by a network attacker without authentication. Successful exploitation can cause application crashes, service restarts, degraded performance, failed customer transactions, increased infrastructure costs from autoscaling, and potential incident response disruption. The CVSS score is high for availability impact, but EPSS is currently low and there is no CISA KEV listing or known ransomware association in the supplied data, so remediation should be prioritized for internet-exposed HTTP/2 services and high-availability production systems rather than treated as confirmed active exploitation.

How an attack unfolds

An attacker identifies a Node.js service that accepts HTTP/2 connections and is running an affected Node.js 22.x or 24.x release. The attacker establishes one or more HTTP/2 sessions and sends crafted request patterns involving header blocks that remain retained by the HTTP/2 implementation while not being fully accounted for by maxSessionMemory. By repeating this behavior across streams or sessions, the attacker causes the Node.js process memory footprint to grow beyond expected limits. As memory pressure increases, garbage collection overhead rises, response latency increases, and the process may eventually abort with an out-of-memory error or be terminated by the host, container orchestrator, or process manager. The attacker can repeat the traffic to keep the service unstable after restart.

How to fix it

Upgrade affected Node.js 22.x and 24.x deployments to fixed vendor packages. For Red Hat packages, update nodejs22-main to 22.23.2-2.3.hum1 or later and nodejs24-main to 24.18.1-0.1.hum1 or later as provided in RHSA-2026:48305. Rebuild and redeploy application images that bundle affected Node.js runtimes, including base images, serverless layers, CI build images, and container images. If immediate patching is not possible, reduce exposure by disabling HTTP/2 where operationally feasible, terminating HTTP/2 at a patched reverse proxy or load balancer, enforcing strict connection/session limits, applying request header size limits, setting aggressive idle/session timeouts, rate-limiting suspicious clients, and ensuring process/container memory limits and automated restarts are in place. These mitigations reduce impact but should not replace upgrading Node.js.

How to confirm the fix worked

Confirm runtime versions on hosts, containers, and build artifacts with commands such as `node --version` and package-manager inventory checks. Verify Red Hat package versions show nodejs22-main at 22.23.2-2.3.hum1 or later, or nodejs24-main at 24.18.1-0.1.hum1 or later. Confirm deployed application images were rebuilt after the runtime update rather than only updating the base image repository. Test whether services still negotiate HTTP/2 where expected and verify any temporary HTTP/2 disabling or reverse-proxy mitigation is actually active. Monitor memory behavior under controlled HTTP/2 load testing to ensure process memory remains bounded and the service no longer terminates due to memory exhaustion. Review SBOMs, container manifests, package locks, and vulnerability scanner output to ensure no affected Node.js 22.x or 24.x runtime remains in production or externally reachable environments.

Typical attack path

1. Discover an exposed service that supports HTTP/2 and is likely implemented with Node.js 22.x or 24.x.
2. Open HTTP/2 connections to the target service without needing credentials or user interaction.
3. Send crafted HTTP/2 requests with header block behavior that causes retained memory to evade maxSessionMemory limits.
4. Repeat the request pattern across streams, sessions, or multiple clients to increase memory consumption.
5. Trigger high memory pressure, garbage collection thrashing, process termination, container OOM kills, or service restarts.
6. Continue sending traffic after recovery to sustain denial of service.

How to detect it

Look for evidence of attempted or successful denial of service against Node.js services that accept HTTP/2. Relevant sources include application logs, Node.js stderr/stdout, process manager logs, container runtime events, Kubernetes events, system logs, reverse proxy/load balancer logs, WAF/CDN logs, and APM metrics. Investigate unexplained memory growth in Node.js processes, sudden increases in garbage collection time, repeated process exits, container OOMKilled events, HTTP 502/503/504 spikes, and bursts of HTTP/2 sessions or streams from a small number of source IPs. In proxy or load balancer telemetry, look for unusually high HTTP/2 connection counts, high stream churn, large or abnormal header activity, repeated resets, or traffic concentrated immediately before application memory exhaustion. Because the vulnerability is a resource-exhaustion condition, indicators are behavioral rather than a unique payload signature; correlate HTTP/2 traffic spikes with Node.js memory pressure and crashes. If named threat actors or campaigns are later reported, enrich detections with their infrastructure, but none are provided in the input.

• JavaScript heap out of memory
• FATAL ERROR: Reached heap limit Allocation failed
• FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed
• Allocation failed - JavaScript heap out of memory
• OOMKilled
• Killed process
• Out of memory: Killed process
• container killed due to memory usage
• exit code 137
• ERR_HTTP2_SESSION_ERROR
• ERR_HTTP2_STREAM_ERROR
• ERR_HTTP2_ERROR
• HTTP/2 session closed
• GOAWAY
• RST_STREAM
• HTTP 502
• HTTP 503
• HTTP 504

What your security team should do

• Prioritize patching internet-facing Node.js services that accept HTTP/2 traffic, especially APIs, web front ends, edge services, and high-availability systems.
• Upgrade Red Hat nodejs22-main to 22.23.2-2.3.hum1 or later and nodejs24-main to 24.18.1-0.1.hum1 or later; rebuild and redeploy all dependent application artifacts.
• Inventory Node.js 22.x and 24.x usage across hosts, containers, serverless runtimes, CI/CD images, and base images to identify hidden exposure.
• Temporarily disable HTTP/2 or terminate it at a patched reverse proxy/load balancer for systems that cannot be upgraded immediately.
• Apply rate limits, concurrent stream limits, connection limits, header size limits, and idle timeouts for HTTP/2 traffic at edge controls.
• Add monitoring and alerting for abnormal Node.js memory growth, OOM kills, frequent restarts, and spikes in HTTP/2 sessions or streams.
• Review recent logs for unexplained process crashes or memory exhaustion on HTTP/2-enabled Node.js services since publication on 2026-08-04.
• Track vendor advisories for any change in exploit maturity, EPSS movement, or KEV status, but do not wait for active exploitation before remediating exposed services.