Node.js July 29, 2026 Security Releases Fix 11 Vulnerabilities: What Businesses Should Check

On July 29, 2026, the Node.js project published security releases for all three of its supported release lines. Together they fix eleven vulnerabilities, three of them rated high severity, in the runtime that executes a large share of modern web application backends, APIs and build tooling.

Node.js is rarely something a business owner thinks about directly. It sits underneath the application, and it is updated separately from the application's own code. That separation is why runtime updates are easy to miss: the product keeps working, nobody files a ticket, and the server quietly falls behind. If your product depends on Node.js development, whether for the whole backend or only for a server-rendered front end, it is worth confirming that these releases, or later ones, are in place.

This article summarizes what was fixed, which versions contain the fixes, who is most exposed, and what to ask your developers.

What Node.js released on July 29, 2026

The Node.js security release announcement lists fixed versions for each supported line: Node.js 22.23.2, Node.js 24.18.1 and Node.js 26.5.1. The announcement notes that the releases were postponed twice, first for additional testing and then because of infrastructure issues, before shipping on Wednesday, July 29.

According to the announcement, the 24.x and 22.x lines each receive fixes for eight issues (two high, four medium, two low), and the 26.x line for seven (one high, four medium, two low). The releases also update two bundled components that handle HTTP traffic, undici and llhttp.

These are the minimum safe versions, not the latest ones. The project's release status page shows that all three lines have received further updates in September 2026, so a team patching today should move to the newest release in its line rather than stop at the July numbers.

The high severity issues in plain terms

Two of the three high severity items concern HTTP/2, the protocol most browsers use to talk to modern web servers. The announcement describes CVE-2026-56846 as a way for a remote party to make an HTTP/2 server hold more memory than its configured limit allows, leading to memory exhaustion; it affects the 24.x and 22.x lines. CVE-2026-56848 is a memory-safety error in HTTP/2 handling that affects all three lines. In practical terms, both threaten availability: a service that runs out of memory or crashes is a service your customers cannot reach.

The third, CVE-2026-58043, is in the Node.js Permission Model, an optional feature that lets developers restrict which files a Node.js process may read or write. The announcement says that a flaw in how paths are matched could grant access outside the intended list. This matters only to applications that have switched the feature on and rely on it as a security boundary. Two of the low severity fixes close similar gaps in the same feature.

The medium and low severity fixes

The five medium issues are more varied. Two relate to outbound HTTPS connections made by a Node.js application: one where a client certificate identity could be reused across requests that were meant to use different certificates, and one where a reused TLS session could skip hostname verification. The announcement describes the second as an incomplete fix for an earlier CVE. These are relevant to systems that call other services using mutual TLS, which is common in payment, banking and business-to-business integrations.

The remaining medium items are a data-handling error in the built-in SQLite module (26.x and 24.x only) and two ways to crash a process, one through an unusual DNS response and one through the compression module. Among the low severity items, the announcement lists an HTTP parser issue that could enable request smuggling, a class of problem that arises when a proxy and the application behind it disagree about where one request ends and the next begins.

We are not describing how any of these could be triggered. Your developers can read the announcement for the technical detail.

Who is most exposed

Exposure depends on how your application is deployed, and it is worth being precise instead of assuming the worst.

Many production Node.js applications sit behind a load balancer, a content delivery network or a reverse proxy such as nginx. In that arrangement the outside world speaks HTTP/2 to the proxy, and the proxy often speaks plain HTTP/1.1 to Node.js. If that describes your setup, the HTTP/2 issues may not be reachable from the internet. If Node.js itself terminates HTTP/2 connections, or your services talk to each other over HTTP/2 or gRPC, they are directly relevant.

The Permission Model fixes apply only if your team uses that feature. The outbound HTTPS fixes apply mainly where client certificates are in use. The crash issues are relevant to almost any deployment, although their impact is an interruption, not a data breach. This is guidance for prioritizing the conversation, not a reason to skip the update: your developers are the ones who can say which cases apply.

The larger risk: unsupported Node.js versions

The announcement includes a sentence that deserves more attention than the CVE list: end-of-life versions are always affected when a security release occurs. No fixes were issued for them.

The release status page lists Node.js 20 and Node.js 18 as end-of-life, along with the short-lived Node.js 25 line. It lists 24 and 22 as LTS (long-term support) lines and 26 as the current release, and it states that production applications should only use Active LTS or Maintenance LTS releases. The same page notes that commercial support for versions past that phase is available through OpenJS Foundation partners.

For a business, this is usually the real finding. An application built two or three years ago and left alone is quite likely to be running Node.js 18 or 20. It cannot receive the July fixes by a simple update; it needs a move to a supported line, which involves testing the application and its dependencies against the newer runtime. That is a small project, not a patch, and it is better scheduled than discovered during an incident.

What this means for your business

If your application runs on a supported line and your team patches the runtime routinely, this release is ordinary maintenance. Applying it typically means rebuilding and redeploying the application with the newer Node.js version, which is low risk within the same release line.

If nobody can tell you which Node.js version is in production, that is the issue to resolve first. Check every place Node.js runs, not only the main server: container base images, serverless functions, build pipelines, scheduled jobs and internal tools. On managed platforms, the provider may supply the runtime, but you often still choose the major version, and an old choice stays old until someone changes it.

What to ask your developers

• Which Node.js version is each of our services running in production, and is each at or above 22.23.2, 24.18.1 or 26.5.1?
• Is anything still on Node.js 20, 18 or older? If so, what would it take to move to a supported LTS line, and when can it be scheduled?
• Does Node.js handle HTTP/2 connections directly anywhere in our system, or is HTTP/2 terminated at a proxy or load balancer?
• Do we use the Node.js Permission Model, or client certificates for outbound connections?
• Who is responsible for runtime updates, and how soon after a Node.js security release are they normally deployed?
• Are our container images and serverless functions rebuilt on a schedule, so they pick up runtime fixes without a code change?

Conclusion

The July 29, 2026 Node.js security releases fix eleven vulnerabilities across the 22.x, 24.x and 26.x lines, with the most serious affecting HTTP/2 handling and the optional Permission Model. Supported applications need a routine runtime update to at least 22.23.2, 24.18.1 or 26.5.1. Applications on end-of-life versions such as Node.js 20 or 18 received no fix and need an upgrade plan instead.

If you are not sure which Node.js version your application runs on, or you have an older Node.js system that needs moving to a supported release, Entrant Technologies builds and maintains web applications and custom software and can help you scope the work. You can request a quote to start that conversation.