Node.js July 2026 security release: HTTP/2 and Permission Model

On 29 July 2026 the Node.js project shipped security releases for three lines: v22.23.2, v24.18.1 and v26.5.1. The advisory lists 11 CVEs in a table (the page's own summary line says 12, so count from the table), three of them rated High. The release was postponed twice, first from 27 July and then from 28 July, and the project cited infrastructure issues for the last delay.

Most Node advisories read as "upgrade everything." That is the right default. But the individual bugs sit in very different places: an HTTP/2 server, a flag almost nobody sets, a SQLite API that landed recently. Knowing which of those your code touches tells you how urgent the rollout is, and which services go first.

What's affected

Fixed versions: v22.23.2, v24.18.1 and v26.5.1. The release also bumped undici (8.9.0, 7.29.0, 6.28.0 across the three lines) and llhttp (9.4.3). Node 18 and 20 are end of life and got no patches. The project notes that end-of-life versions are always affected when a security release ships.

The advisory page does not map each CVE to a single fixed version, so treat the three release numbers as the floor for each line.

How to check if you're exposed

Start with the runtime version, in every place Node runs: servers, CI images, containers, serverless layers.

node --version
# containers
docker run --rm your-image:tag node --version
# find Node pinned in Dockerfiles and CI config
grep -rnE "node:[0-9]+|setup-node|NODE_VERSION|nvm use" Dockerfile* .github .nvmrc .node-version 2>/dev/null

Then ask which vulnerable code paths your applications actually reach. A rough first pass by grep:

# HTTP/2 servers (CVE-2026-56846, CVE-2026-56848)
grep -rnE "http2\.(createServer|createSecureServer)|require\(.node:http2.\)" src
# Permission Model in use (CVE-2026-58043, -56847, -58039)
grep -rnE "allow-fs-(read|write)|--permission" package.json Dockerfile* .github 2>/dev/null
# HTTPS Agent with client certs or session reuse
grep -rnE "https\.Agent|pfx:" src
# node:sqlite tag store, zlib sync, dns.resolveAny
grep -rnE "createTagStore|zlib\.[a-zA-Z]+Sync|resolveAny" src

A hit means the code is reachable in principle, not that it is exploitable. For HTTP/2, the question is whether the server is exposed to untrusted clients directly or sits behind a proxy that terminates HTTP/2. For the Permission Model, the question is whether you run with it at all. Most services do not.

What to do now

1. Upgrade to v22.23.2, v24.18.1 or v26.5.1. If you are on Node 18 or 20, plan the move to a supported line now, because there is no patch coming.
2. Rebuild base images and redeploy. Updating a developer laptop does not change what production runs.
3. Prioritize services that expose node:http2 to the internet. Those carry the two High HTTP/2 issues.
4. If you run with the Permission Model and rely on it as a boundary for untrusted code, treat CVE-2026-58043 as urgent and review what paths you granted.
5. If you build forwarding proxies on Node, review how they rebuild outbound headers (CVE-2026-58044) and consider rejecting requests that exceed maxHeadersCount outright.
6. Update undici if you pin it separately in package.json, since the bundled copy is not the one your lockfile resolves.

How this could have been avoided

Most of this release is not an "avoid" story, since the bugs are in the runtime. The controls below limit the blast radius and shorten the time to patch.

• Terminate HTTP/2 at a proxy you patch on a schedule. The two High HTTP/2 flaws need a client speaking HTTP/2 to Node directly. A front proxy that speaks HTTP/1.1 to Node removes that path for services that never needed it.
• Cap memory per process and restart on exhaustion. CVE-2026-56846 ends in memory exhaustion. Container memory limits and an orchestrator that restarts the pod turn an outage into a blip.
• Treat the Permission Model as defense in depth, not a sandbox. Three of the CVEs show it leaking at the edges. Run untrusted code in a separate container or VM as well.
• Do not reuse HTTPS Agents across identities. CVE-2026-56850 only bites when one agent serves requests with different client certificates. One agent per identity avoids the collision.
• Track runtime versions as inventory. An end-of-life line is silent exposure. A list of every Node version in production tells you in minutes who needs to move.

Why it matters

A runtime advisory is the hardest kind to triage by severity label alone. Eleven CVEs, three Highs, and the honest answer for a given service is often "two of these apply, nine do not." Teams that cannot tell which is which patch everything at the same pace, or defer everything.

Reachability analysis narrows this by checking whether your code calls the affected function or feature. An app with no http2 server, no Permission Model and no node:sqlite has a short list. An API gateway running HTTP/2 on the edge has a long one. The version bump is the same either way. The order and the urgency are not.

Try it yourself

Pick one service, run the grep block above against it, and write down which of the eleven CVEs it can reach. Then compare that list with what the severity labels alone would have told you.

Click through it at your own pace, or open it full screen.

You can also check the dependencies in a package.json for known CVEs with the free scan. It runs in your browser, the file never leaves your machine, and there is no login.

Quick check

Sources

• Node.js July 2026 Security Releases
• Node.js SECURITY.md