Node.js July 2026 security release: your fast-patch playbook and version matrix

Summary. On Wednesday, July 29, 2026, after two postponements, the Node.js project shipped security releases for its three supported lines, as v26.5.1, v24.18.1 and v22.23.2, fixing 11 CVEs with the highest severity rated HIGH in every line. The project pre-announced the drop on July 21, and it landed nine days after the July 2026 Next.js security release, an unusual stretch in which both major JavaScript release trains shipped high-severity patches within two weeks. If you run Node in production, the job is small but time-sensitive: confirm which line you are on, move to the newest patched build, and gate it in your pipeline. The cost of skipping it is not abstract. IBM put the 2025 global average cost of a data breach at $4.44 million, down from $4.88 million a year earlier, while India recorded the highest average of any country at ₹220 million, up 13% year over year. Node.js 20 reached end of life on April 30, 2026, so anyone still on it has no official patch path from the project at all.

Update, 2 November 2026. This guide was first written before the fixes went live. The release slipped twice and shipped on July 29, 2026, not July 27, as v26.5.1, v24.18.1 and v22.23.2, with 11 CVEs, which we have added below. A newer security release followed on October 21, 2026, so the build to run today is the newest on your line: v26.13.0, v24.22.2 or v22.23.4. Node.js 26 is now Active LTS and Node.js 24 is in Maintenance LTS. For choosing a line, see Node.js 24 vs 26 vs 27. If you are on 22.x, see our Node.js 22 end-of-life guide.

This is a working guide for backend and platform teams, not a news recap. It covers what shipped, which version you should be on, what these releases usually contain (with the June 18, 2026 release for comparison), and a step-by-step patch playbook for bare-metal, Docker, CI and serverless. It closes with the end-of-life trap that quietly leaves a large share of production traffic exposed, and what the numbers mean for teams operating under India's DPDP Act.

What shipped on July 29, 2026

The Node.js security team followed its pre-announcement model. On July 21 it published a notice that new versions of the 26.x, 24.x and 22.x release lines would ship on or shortly after Monday, July 27, to address one or more security issues, with the highest severity rated HIGH. It then postponed twice, to July 28 for more testing and validation, and to July 29 because of infrastructure issues. That advance notice is the point of the program: it gives operations teams a date to plan a maintenance window around instead of scrambling when the patch appears.

Two facts matter before you touch anything. First, all three currently supported lines are affected, so there is no "my line is safe" exception in this release. Second, the release fixed 11 CVEs, three rated High, five Medium and three Low, in builds v26.5.1, v24.18.1 and v22.23.2. It also updated the bundled undici (8.9.0, 7.29.0 and 6.28.0 respectively) and llhttp (9.4.3). The three High issues were:

• CVE-2026-56848: a re-entrant send in HTTP/2 handling causes a heap use-after-free. It affects 26.x, 24.x and 22.x.

• CVE-2026-56846: retained HTTP/2 header blocks can evade maxSessionMemory limits and exhaust memory remotely. It affects 24.x and 22.x.

• CVE-2026-58043: Permission Model path matching can over-grant filesystem access, so a process allowed one path can reach paths outside the allowlist. It affects 26.x, 24.x and 22.x.

The five Medium issues are HTTPS Agent reuse of mTLS identities across PFX certificates (CVE-2026-56850), HTTPS Agent session reuse that can skip hostname verification (CVE-2026-58040, an incomplete fix for the June CVE-2026-48934), node:sqlite iterator replay that can re-execute writes (CVE-2026-58041, 26.x and 24.x only), a dns.resolveAny() abort on large DNS responses (CVE-2026-58042) and a node:zlib crash on a spoofed TypedArray length (CVE-2026-58045). The three Low issues are two Permission Model write bypasses (CVE-2026-56847 and CVE-2026-58039) and HTTP header truncation that can enable request smuggling through forwarding proxies (CVE-2026-58044).

The July drop was notable for its company. Vercel shipped the July 2026 Next.js security release nine days earlier, on July 20, patching nine vulnerabilities including four rated high severity across Next.js 16.2 and 15.5. For teams running a Next.js frontend on a Node runtime, that meant two upgrades close together. We break the framework side down separately in our analysis of the Next.js July 2026 security release; this guide stays on the runtime.

The version matrix: which line you are on and what to do

Start here. The single most useful thing you can do in the first five minutes is establish which release line every production and build environment is actually running, then map each to an action. As of November 2, 2026 the supported lines are 22.x (Maintenance LTS), 24.x (Maintenance LTS) and 26.x (Active LTS). Everything at 20.x and below is end of life. The July builds have since been superseded by the October 21, 2026 security release (v26.12.1, v24.22.1 and v22.23.4), also rated HIGH, so run the latest release shown below.

Two takeaways. If you are on 26.x or 24.x, you are on a line the Node.js team supports for production, and this is a routine point upgrade. If you are on 20.x or older, the July release does not help you, because the project does not build patches for end-of-life lines. That is the trap covered later.

For teams weighing a larger platform decision rather than a point upgrade, the runtime choice itself is worth revisiting periodically; our Bun versus Node.js backend runtime decision lays out where each fits. And with Node.js 27 in alpha since October 2026 and due on April 22, 2027 under a new once-a-year cadence, the upgrade rhythm has changed, which we cover in the Node.js one-release-per-year LTS cadence guide.

What a Node.js security release usually contains

The July fixes above follow the pattern of the release before them. The June 18, 2026 drop is a useful comparison, and it shows why "highest severity HIGH" deserves a same-week response.

That release fixed twelve distinct CVEs across the same three lines, patched in v22.23.0, v24.17.0 and v26.3.1. Two were rated HIGH:

• CVE-2026-48933, a WebCrypto AES integer overflow that crashes the process when the input to subtle.encrypt() is a multiple of 2 GiB, a remote denial-of-service condition affecting Node.js 22, 24 and 26.

• CVE-2026-48618, a Unicode dot-separator handling flaw that allows a TLS wildcard-depth authentication bypass through a mismatch between resolver and verifier hostname normalization, again across all three lines.

The medium-severity set in that release was heavily TLS and HTTP/2 focused, and it is instructive because these are exactly the components an internet-facing Node service exposes. It included CVE-2026-48928 (uppercase SNI context matching leading to an mTLS authorization bypass), CVE-2026-48934 (TLS host identity verification bypass via session reuse with a different server name), CVE-2026-48930 (embedded-nul hostnames causing silent authority rebinding), CVE-2026-48619 (unbounded memory growth in node:http2 clients via attacker-controlled ORIGIN frames), CVE-2026-48937 (HTTP/2 sessions that never clean up after a GOAWAY on invalid protocol errors), and CVE-2026-48615 (proxy credentials leaked in ERR_PROXY_TUNNEL error messages). Several lower-severity permission-model bypasses rounded it out.

The June release also bumped bundled dependencies to close public vulnerabilities: llhttp to 9.4.2, nghttp2 to 1.69.0 and OpenSSL to 3.5.7 across all lines, plus undici to 8.5.0, 7.28.0 and 6.27.0 on the 26.x, 24.x and 22.x builds respectively. That detail matters for one reason: a Node security release is not only about your application code. It ships fixes to the TLS stack, the HTTP parser and the HTTP client that your dependencies call into, which is why "we do not use WebCrypto" is not a reason to skip a release. The plain version of the lesson: with Node, patching the runtime patches a batch of your transitive attack surface at once.

The July 29 release looks structurally similar. HTTP/2, TLS hostname checks and HTTP parsing feature again, alongside Permission Model fixes and undici and llhttp updates, so network-facing components were involved and it warranted a same-week upgrade.

The fast-patch playbook

Here is the sequence we use to move a fleet onto a new Node patch build without breaking production. It is deliberately boring. Security upgrades inside a line (for example 24.17.0 to a later 24.x) are patch or minor bumps with a strong compatibility guarantee, so the risk is low and the main work is verification, not code changes.

1. Inventory. Get an authoritative list of what is actually running. node -v on hosts is not enough, because build images, CI runners, Lambda layers and base Docker images all pin their own versions. Grep your Dockerfile, .nvmrc, package.json engines field, CI config and infrastructure-as-code for pinned Node versions in one pass.

1. Read the advisory. The July CVEs are on the Node.js security page, so note which components are involved and whether any affect only a subset of lines. In June, for example, one HTTP/2 cleanup issue affected only 22.x and 24.x, and one permission-model issue affected only 26.x. Component scope tells you how urgent your specific exposure is.

1. Upgrade in a branch and run your suite. Bump the pinned version, rebuild, and run unit, integration and end-to-end tests. Within an LTS line, breakage is rare; when it happens it usually traces to a native addon compiled against a specific ABI, so watch your node-gyp and prebuilt-binary dependencies.

1. Roll out progressively. Ship to staging, then a canary slice of production, then the fleet. Keep the previous image tagged so rollback is one deploy, not a rebuild.

1. Gate it so you do not regress. Add a CI check that fails the build if the runtime is an unpatched or end-of-life version. This is the step most teams skip, and it is the one that stops the same gap reopening next quarter.

The mechanics differ by environment. Use this as a per-surface checklist.

If your frontend and backend share a runtime, sequence framework and runtime upgrades together so you take one maintenance window, not two. Our guide to the wider 2026 web platform for developers sets this regular-patch reality in the context of the year's other browser and runtime changes.

The end-of-life trap that leaves you exposed

The uncomfortable part of this release is not the three supported lines. It is everything below them. Node.js does not evaluate or patch end-of-life versions, and the project has been explicit about why. Its own guidance states that new CVEs now include end-of-life releases in their applicability by default, "until we have specific information that indicates a CVE does not apply to an end-of-life release line."

The reasoning is a resourcing one, and a Node.js maintainer put it bluntly. As Node.js Technical Steering Committee member Matteo Collina explained in the project's guidance on end-of-life CVEs, "all past Node.js releases are vulnerable or will soon be. This CVE highlights that risk for your organization." He was describing why the project issues CVEs that flag old lines rather than auditing each one, because Node.js is maintained by volunteers with funding sufficient only for the current releases.

This has three practical consequences for anyone still on Node.js 18, 20 or earlier:

First, there is no fix coming from the project. The July advisory's patched builds are 26.x, 24.x and 22.x. A production service on Node 20, which reached end of life on April 30, 2026, gets nothing. The vulnerability is real, the fix exists for supported lines, and it will never be backported to your runtime.

Second, your scanners will keep flagging you, correctly. Because Node.js now marks end-of-life lines as affected in new CVE ranges, a Node 18 or 20 deployment will light up vulnerability scanners with no clean remediation path other than upgrading. This is deliberate. The Technical Steering Committee noted that Node.js 16, end of life since 2023, still records roughly 11 million downloads a month, and that teams running it often assume they are safe because nothing tells them otherwise. Marking the CVEs is how the project tells them otherwise.

Third, your only supported options are to migrate or to pay for extended support. The OpenJS Foundation runs an Ecosystem Sustainability Program that offers commercial support for lines past their maintenance phase, and vendors such as HeroDevs sell never-ending-support builds for end-of-life Node. Both are legitimate bridges. Neither is a substitute for a migration plan, and both cost more than staying current.

The blunt engineering judgement: the real cost of an old Node runtime is almost never the upgrade itself, which within a supported line is a version bump and a test run. It is the migration you deferred until a HIGH-severity CVE forced it during an incident instead of during a sprint.

India-specific considerations

For teams operating in India, the runtime-currency question sits directly under the country's data-protection regime. India's Digital Personal Data Protection Act, 2023 (DPDP Act) expects organisations that handle personal data to apply reasonable security safeguards. Running an end-of-life runtime with unpatched, publicly listed CVEs is difficult to defend as a reasonable safeguard once a patched, supported version exists.

The financial stakes are higher here than almost anywhere. IBM's 2025 Cost of a Data Breach report put India's average breach cost at ₹220 million, roughly ₹22 crore, the highest national average in the study and up about 13% year over year, even as the global average fell to $4.44 million. A same-week runtime patch is one of the cheapest controls on that risk. For Indian SaaS and fintech teams especially, the practical rule is simple: keep every production service on a supported Node line, gate it in CI, and treat the regular Node and framework advisories as a standing calendar item, not an interrupt.

FAQ

How eCorpIT can help

eCorpIT builds and maintains production Node.js and JavaScript backends for teams that cannot afford an unplanned security scramble. We run runtime inventories across your application images, CI runners and serverless layers, put automated version and end-of-life gates into your pipeline, and plan end-of-life migrations before a CVE forces them mid-incident. As a CMMI Level 5 and ISO 27001:2022 certified engineering organization, we design these upgrade and patch processes aligned with DPDP Act requirements. If you want a second set of senior eyes on your Node estate, talk to our team.

References

1. Node.js — Wednesday, July 29, 2026 Security Releases

1. Node.js — Wednesday, October 21, 2026 Security Releases

1. Node.js — Release index (dist/index.json)

1. Node.js — Thursday, June 18, 2026 Security Releases

1. Node.js — Updates on CVE for End-of-Life Versions

1. Node.js Release Working Group — release schedule

1. Node.js end-of-life and release dates

1. Next.js — July 2026 Security Release

1. IBM — 2025 Cost of a Data Breach: navigating the AI rush

1. IBM — India records highest average cost of a data breach in 2025

1. CVE-2026-48933 — Node.js WebCrypto AES integer overflow (DoS)

1. CVE-2026-48618 — Node.js TLS wildcard-depth authentication bypass

1. HeroDevs — Node.js version support and end-of-life dates

1. Help Net Security — global average data breach cost now $4.44 million

Last updated: November 2, 2026.