Node.js July Security Releases: What Actually Shipped

The Node.js July 2026 security release finally landed on Wednesday, July 29 — two days later than planned, after two consecutive one-day slips. It patches 11 CVEs across the 22.x, 24.x, and 26.x release lines: three rated HIGH, five MEDIUM, and three LOW, per the project’s own advisory. The fixed versions are v22.23.2, v24.18.1, and v26.5.1.

This is the what-shipped follow-up to our July 25 patch-week preview, which covered the pre-disclosure announcement — release expected on or shortly after July 27, maximum severity HIGH, no CVE numbers yet. Every one of those open questions is now resolved, and the answers change what you should patch first.

Below: the full CVE list with the project’s own severity labels, why two of the three HIGH bugs still have no published CVSS score, the two subsystem patterns worth flagging, and a patch-order matrix built for teams running Next.js and API workloads on Node 22, 24, or 26.

On July 29, 2026, the Node.js project published new versions of all three active release lines: v22.23.2 on the 22.x line, v24.18.1 on 24.x, and v26.5.1 on 26.x. The accompanying security advisory enumerates 11 CVEs — 3 HIGH, 5 MEDIUM, and 3 LOW by the project’s own severity labels — spanning HTTP/2, the Permission Model, the HTTPS Agent, and the node:sqlite, dns, and node:zlib modules.

The release also refreshes two bundled dependencies across all three lines: undici moves to 8.9.0, 7.29.0, and 6.28.0 per line, and llhttp moves to 9.4.3. If you pin or audit transitive HTTP internals, those bumps ride along with the runtime upgrade.

One scoping note that has not changed since June’s Node.js security release: Node 20 and every earlier line are End-of-Life and receive no patches from this release. If you are still running Node 20 in production, the July CVE list is another entry in the growing pile of unfixed exposure — the only remediation is a line upgrade.

The release was originally planned for on or shortly after Monday, July 27. It slipped twice, and the project documented both slips on the advisory itself. The first update, dated July 27, reads: “The Node.js project is delaying the planned security releases until Tuesday, July 28, 2026 due to the need for additional testing and validation.” The second, dated July 28: “The Node.js project is delaying the planned security releases until Wednesday, July 29, 2026 due to infrastructure issues.”

Two consecutive one-day slips, for two different stated reasons — first validation, then infrastructure. That is a scheduling fact, not a severity signal: Node.js has slipped security-release dates before without it saying anything about fix quality. If anything, delaying a security release to finish testing is the behavior you want from a runtime your production traffic depends on.

The more useful lesson is operational. Even a project as mature as Node.js — one that pre-announces its security releases with dates and severity ceilings, the same discipline Vercel adopted with its monthly Next.js security-release program — cannot guarantee the date. Teams that scheduled a patch window for Monday morning got the actual artifacts on Wednesday. Build slack into patch windows that key off pre-announcements; treat the announced date as the earliest possible start, not a commitment.

Three of the eleven CVEs carry the project’s HIGH label, and they split cleanly into two threat models: remote attackers hitting your HTTP/2 surface, and untrusted code escaping the sandbox you built with --permission.

The two HTTP/2 bugs matter most if Node terminates HTTP/2 traffic directly — no reverse proxy or load balancer downgrading to HTTP/1.1 in front. The use-after-free (CVE-2026-56848) deserves particular respect: use-after-free bugs in a network-facing parser are the classic raw material for remote code execution, even when no public exploit exists yet. The Permission Model bug (CVE-2026-58043) inverts the threat model — it is not about attackers outside your process but about code inside it that you deliberately sandboxed, which is exactly the scenario teams running AI-generated or third-party code under --permission care about.

Here is a detail most same-day coverage papers over: as of publication, only one of the three HIGH CVEs has a numeric CVSS score in any public vulnerability database we could check. CVE-2026-58043 carries a 7.5 (HIGH) with vector CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N — scored by HackerOne and surfaced via the NVD entry, though NVD’s own enrichment was still pending. The two HTTP/2 HIGHs, CVE-2026-56846 and CVE-2026-56848, had no published NVD record at all at release time — reserved-but-not-yet-published status, which is normal in the first days after a Node.js security release.

That gap has a practical consequence: any tooling, dashboard, or policy that gates patching on a numeric CVSS threshold will simply not see two of the three most serious bugs in this release. If your vulnerability-management process keys off NVD scores, the July release is a live demonstration of why severity labels from the upstream project — plus your own exposure analysis — have to drive urgency in the window before enrichment lands.

Sort the 11 CVEs by subsystem instead of severity and two patterns jump out. First: HTTP surfaces account for three of the eleven — both HTTP/2 HIGHs plus a LOW-severity HTTP parser header-truncation bug (CVE-2026-58044) that can enable request smuggling. Second: the Permission Model also accounts for three — the HIGH path-matching over-grant plus two LOWs where trace events (CVE-2026-56847) and process reports (CVE-2026-58039) can write outside the allowlist.

The Permission Model cluster is the one we have not seen anyone else frame as a pattern. Three separate boundary-enforcement bugs in the same feature area, in one release, is a signal about maturity: --permission is a genuinely useful sandboxing primitive, but its allowlist-enforcement edge cases are still being found — one HIGH and two LOWs in July alone. If your architecture treats --permission as a hard security boundary for untrusted code, this release touches your threat model three separate times, and it is reasonable to expect further findings in the same area over the coming release cycles as scrutiny of the feature increases.

The remaining mediums are conditional. Two sit in the HTTPS Agent — reused mTLS identities across PFX certificates (CVE-2026-56850) and session reuse that can skip hostname verification (CVE-2026-58040) — and only bite if you do client-certificate auth or share agents across outbound TLS connections. The node:sqlite iterator-replay bug only matters if you use that module; the dns.resolveAny() abort only if you do bulk any-record lookups; the node:zlib crash only if untrusted input reaches the sync APIs.

A flat CVE list tells you what was fixed; it does not tell you what to do first. The matrix below re-sorts all 11 CVEs by the question that actually drives urgency for a typical Next.js or API deployment on Node 22, 24, or 26: does this code path run in your service at all? Severity labels are the nodejs.org advisory’s; the applicability column is our own synthesis from each CVE’s affected subsystem.

The honest summary of that matrix: for most Next.js deployments sitting behind Vercel, a CDN, or an HTTP/1.1-terminating load balancer, none of the three HIGHs is directly reachable from the internet — and you should still patch this week, because runtime upgrades get harder the longer you defer them and the mediums cover code paths that have a way of appearing in dependencies you did not audit.

Node.js also shipped a security release on June 18, 2026 — v22.23.0, v24.17.0, and v26.3.1 — covered in our June patch guide. Set the two releases side by side and July is slightly smaller by count but heavier at the top: 11 CVEs against June’s 12, with three HIGHs against June’s two.

The repeat-surface point is the one to internalize. HTTP/2 is a complex, stateful protocol implemented on top of nghttp2, and its memory-accounting and stream-lifecycle edges keep producing HIGH-severity findings — two more this month. Projecting forward, the reasonable operating assumption is that HTTP/2 termination in Node will continue to attract security research and continue to produce patch-now CVEs. Architecturally, that strengthens the case for terminating HTTP/2 at a hardened proxy layer and speaking HTTP/1.1 to Node — not because Node is uniquely weak, but because it narrows the runtime surface you have to re-patch every month.

Four exposure profiles cover most production Node estates. Find yours and act accordingly — the upgrade itself is a patch-level bump within your current line (22.x → v22.23.2, 24.x → v24.18.1, 26.x → v26.5.1), so the change risk is low.

Whatever your profile, verify the runtime actually moved: check node --version in the deployed environment, not just the Dockerfile or the engines field. Managed platforms roll runtime patches on their own schedule, and a surprising number of “patched” estates are running the old binary a month later. This is the kind of recurring, checklist-driven work we fold into our web development engagements as standing patch discipline rather than a quarterly scramble — and if you are building agentic systems that execute generated code under --permission, runtime patch latency becomes a security property of the whole system, something we treat as a first-class constraint in AI transformation work.