Node.js fixed two high-severity HTTP/2 vulnerabilities in its July 29, 2026 security releases. CVE-2026-56846 can retain header memory beyond configured session limits in Node 22 and 24. CVE-2026-56848 concerns a re-entrant send path that can cause a use-after-free in Node 22, 24, and 26.

If a Node process accepts untrusted HTTP/2 connections, these are urgent runtime fixes. The practical response is to identify real exposure, update within the current major line, exercise the HTTP/2 boundary, and monitor a canary.

Quick answer

Update affected deployments to Node.js 22.23.2, 24.18.1, or 26.5.1. Rebuild containers, prove the running version, and test concurrent streams, cancellations, large header sets, memory behavior, and graceful shutdown.

node --version
node -p "process.versions.nghttp2"

Node 22 and 24 are affected by both issues. Node 26 is affected by the re-entrant send issue and received its corresponding patch.

Understand the two failure modes

CVE-2026-56846 is a memory-accounting problem. Retained header memory could grow outside the session memory limit that operators expect to contain resource use. A remote peer may therefore create memory pressure and denial of service.

CVE-2026-56848 is a memory-safety problem in a re-entrant HTTP/2 send path. A JavaScript callback can re-enter native HTTP/2 operations while previous work is still active, producing a use-after-free. Node’s advisory rates it high severity.

Both issues sit below normal route handlers. Input validation in Express, Fastify, or an application controller does not replace the runtime patch.

Confirm whether HTTP/2 reaches Node

Search for direct use of node:http2, framework HTTP/2 options, TLS listener configuration, and infrastructure routes that preserve HTTP/2 to the origin.

rg -n "node:http2|require\\(['\"]http2|http2\\.create|allowHTTP1" .

A CDN or load balancer may terminate HTTP/2 and forward HTTP/1.1, which changes direct exposure, but do not assume that from the browser protocol. Inspect the origin listener and load-balancer target configuration.

Internal services also matter. An untrusted tenant, compromised workload, or exposed mesh route can reach an “internal-only” server.

Patch without changing major versions

Move Node 24 to 24.18.1, Node 22 to 22.23.2, and Node 26 to 26.5.1. A security incident is a poor time to combine a major runtime migration with an HTTP stack patch.

Update every version source:

  • Docker base image and digest;
  • .nvmrc or .node-version;
  • CI setup action;
  • serverless runtime selection;
  • infrastructure image definition;
  • one-off workers and scheduled jobs.

Rebuild from a clean base. Restarting an old image does not install the patched runtime.

Test the boundary safely

Do not attempt destructive proof-of-concept traffic against production. In an isolated environment, exercise many short and long-lived streams, cancellations, invalid requests, large but policy-compliant headers, client disconnects, and graceful server close.

Collect:

  • resident memory and heap;
  • event-loop delay;
  • active sessions and streams;
  • process exits and native crashes;
  • request latency and error rate;
  • load-balancer resets.

The goal is regression confidence, not reproduction of memory corruption.

Deploy a canary and verify

Expose one patched instance to representative traffic. Confirm the process-reported version inside the running container or VM, not only the build log.

docker exec api-canary node --version

Compare the canary with the previous release for a normal traffic window. Keep the previous image digest available for operational rollback, but understand that rollback restores vulnerability; use it only if service stability requires immediate containment while investigating.

Temporary controls are not the fix

If patching is delayed, terminate HTTP/2 at a maintained proxy and forward HTTP/1.1 where possible, restrict network access, and tighten process memory and restart policies. These controls may reduce exposure or impact, but they do not correct the vulnerable Node runtime.

Document the owner and deadline. Temporary protocol changes can affect streaming, gRPC, connection counts, and latency, so test them like any production change.

Primary sources

The shortest reliable path is a patch within the deployed major line, followed by focused HTTP/2 tests and runtime verification in the real workload. Application middleware cannot compensate for a flaw in the protocol implementation beneath it.

Keep the focused protocol smoke test in the repository so the next runtime update exercises the same boundary.

Record the patched image digest with it.