Node.js 22, 24 and 26: security fixes to deploy now

The Node.js project published security updates for all three maintained release lines on July 29, 2026. They fix eleven vulnerabilities, including three high-severity issues in HTTP/2 and the Permission Model. Teams running an exposed Node server, relying on permission isolation or building applications in containers should verify the version that is actually deployed.

Patched releases are 22.23.2 LTS, 24.18.1 LTS and 26.5.1 Current. Editing package.json alone does not update them: Node is the runtime, commonly supplied by a base image, CI runner, managed service or host installation.

The short answer

These numbers are minimum thresholds for this security batch. If a newer maintained patch in the same line is available at deployment time, prefer it after validation. End-of-life lines do not receive the same guarantees and should be migrated.

Three high-severity issues come first

CVE-2026-56846 affects HTTP/2 header memory handling. Retained headers can bypass maxSessionMemory, allowing a remote client to increase memory consumption until the service becomes unavailable. It affects releases 22 and 24.

Exposure is clearest when a Node service terminates Internet-facing HTTP/2 connections. A reverse proxy may reduce risk if it terminates HTTP/2 and enforces its own limits, but teams must verify that architecture. Some proxies pass the protocol through, and alternative network paths may still reach the application.

CVE-2026-56848 is a use-after-free in reentrant HTTP/2 sending. A specific sequence can reuse memory after it has been released, leading to a crash or undefined behavior. Releases 22, 24 and 26 are affected. A frontend is not proof of immunity if the backend still accepts HTTP/2.

The third high-severity flaw, CVE-2026-58043, affects the Permission Model. Path prefixes interpreted with radix-like logic can grant broader filesystem access than intended. It affects all three lines. Applications using --permission, --allow-fs-read or --allow-fs-write to isolate code should treat it as a failure of a security boundary.

TLS and mTLS expose different identity risks

Medium-severity CVE-2026-56850 concerns identity reuse in an HTTPS Agent configured with multiple PFX certificates for mutual TLS. A connection can reuse a client identity that does not match the next request. In a system where the certificate identifies a tenant, partner or access tier, the authorization impact may be more important than the word “medium” suggests.

CVE-2026-58040 concerns TLS session resumption. Under specific conditions, a reused session can skip a new hostname verification. Risk depends on how connections, agents and destinations are pooled. Services contacting multiple domains through shared pools or custom TLS settings should revisit their tests.

Published severity is therefore a starting point, not an exact measurement for every system. A medium issue placed on a critical identity boundary may deserve priority over a high issue that cannot be reached in the deployed architecture.

DNS, SQLite and zlib can terminate a process

Several medium-severity fixes cover conditions capable of crashing or corrupting a workload:

• CVE-2026-58042 can abort a process when dns.resolveAny() receives more than 256 A records;
• CVE-2026-58045 uses a spoofed TypedArray length passed to synchronous zlib APIs and can cause a crash;
• CVE-2026-58041 affects SQLTagStore in node:sqlite, where a stale iterator can unexpectedly re-execute a write.

The SQLite issue applies to releases 24 and 26. The other two affect all patched lines. Exploitability depends on whether untrusted data can reach the vulnerable API. Applications resolving user-supplied domains, decompressing external content or exposing a SQLite access layer should trace that path explicitly.

A repeatable crash is a security incident when a remote actor can trigger it. Automatic restarts shorten one outage, but an attacker can repeat the request, drain queues and increase infrastructure cost.

Low severity does not always mean negligible

Two low-severity issues allow trace_events and process.report to write outside paths allowed by the Permission Model. They may not provide broad filesystem access, but they contradict the expected destination allowlist. On a platform executing third-party code, a report may create or overwrite a file in an unintended location.

Another low-severity flaw sits in the HTTP parser. Truncated headers can produce interpretation differences and contribute to request desynchronization when a Node server acts as a forwarding proxy. This is more specialized than a conventional web server scenario, but Node-based gateways and internal tooling need to assess it.

Bundled dependencies, including Undici and llhttp, were updated in the releases as well. Teams should read the notes for their exact line instead of assuming the eleven CVEs describe every behavior change.

Find every Node runtime that actually runs

Inventory is often harder than the update. A repository may declare Node 24 in .nvmrc while the production container still uses an older 22 image. GitLab runners, serverless functions, migration jobs and static-generation tools can each contain another copy.

The review should include:

1. final service images, running node --version inside each container;
2. build images, because malicious scripts may execute during npm install;
3. CI runners and job containers;
4. scheduled tasks, workers and administration commands;
5. serverless functions and managed runtimes;
6. hosts that execute Node tooling in production;
7. cached registry images that could be redeployed later.

A container scanner can locate a vulnerable package, but it does not prove which binary starts or which flags are enabled. Conversely, node --version confirms the active engine but misses dormant copies. Both views are required.

Updating an image without retaining the old digest

Changing FROM node:24-bookworm-slim and rebuilding may not update the base if a cache or mirror still supplies an old digest. Pull the recent base explicitly, invalidate the relevant layer when necessary, then inspect the resulting image.

For images pinned by digest, the operation must be deliberate: replace the digest with the corrected one, rebuild, sign or attest according to policy, and update the deployment manifest. Digest pinning prevents invisible changes but requires teams to renew the reference for security fixes.

The npm lockfile does not pin Node itself. engines, packageManager, .nvmrc and .tool-versions document or partly control development environments; the Dockerfile or platform configuration determines the runtime that ships.

A seven-step rollout

A patch release is intended to minimize compatibility changes, but it still deserves a controlled deployment:

1. inventory services, prioritizing HTTP/2 exposure and Permission Model use;
2. rebuild with 22.23.2, 24.18.1, 26.5.1 or a later maintained patch;
3. run unit, integration, TLS, proxy and load tests;
4. verify native modules and operating-system image compatibility;
5. deploy to a small portion of instances;
6. monitor errors, memory, latency, restarts and TLS failures;
7. complete rollout and remove old images from redeployment paths.

Rollback should target a known and prepared image, but restoring a vulnerable runtime can only be temporary. If an application regression appears, isolate the change, fix it or disable the affected feature instead of remaining on the old version indefinitely.

Verify after deployment

A successful pipeline is not final proof. Query the process that actually started. An internal diagnostic endpoint, observability inventory or container command can expose process.version without publishing it to the Internet.

Also confirm that every replica runs the new digest and no old pod is waiting behind an autoscaler. A nightly task that starts infrequently may escape immediate observation; update its image before its next run.

For HTTP/2, watch per-session memory, abnormal closes and restarts. For TLS and mTLS, test multiple hostnames and client certificates. For the Permission Model, add negative tests proving that a neighboring path outside the allowlist remains forbidden.

Operational checklist

• record the version in every runtime, not only in the repository;
• move to at least 22.23.2, 24.18.1 or 26.5.1;
• prefer a maintained LTS line for production;
• rebuild images from a base that is demonstrably updated;
• test HTTP/2, TLS, mTLS and permissions according to exposure;
• roll out gradually with memory and crash metrics;
• verify image digest and process.version after startup;
• update CI, workers, cron jobs and managed functions too;
• prevent accidental redeployment of an old image;
• plan migration away from any end-of-life line.

This release does not require an application redesign. It requires operational discipline: know the runtimes, rebuild from a fixed base and verify what is truly running. HTTP/2 flaws provide the most direct remote scenarios, while Permission Model and mTLS issues can reach central trust boundaries. Waiting for the next routine dependency cycle would leave those risks open for no technical benefit.