Node.js security releases are available: check your production runtimes

The Node.js security releases scheduled for 11 November 2026 are now available. The supported 22.x, 24.x and 26.x lines received security builds 22.23.5, 24.22.3 and 26.13.1. Businesses no longer need to wait for the announcement to become a downloadable patch. The next question is whether the corrected runtime is actually running wherever an application depends on it.

The official release information identifies several *High*-severity vulnerabilities involving HTTP/2, HTTPS and TLS. For a smaller company operating an online store, customer portal or internal API, the practical problem is often not understanding every protocol detail. It is knowing which Node.js installations exist, who maintains them and whether the latest security releases have reached production.

The security builds and what they contain

The Node.js project issued advance notice in early November and published the security releases on 11 November. The final advisories now provide individual CVEs, technical descriptions and patch versions. That supersedes the earlier situation in which the exact fixes were not yet public.

Applications using Node.js 22 can update within that release line to 22.23.5; applications on 24 can use 24.22.3, and those on 26 can use 26.13.1. Always check for any subsequent supported security build before deploying. Moving an application to a different major version is not necessary merely to receive this round of fixes, and may introduce compatibility changes best handled as a separate migration.

The releases also update dependencies bundled with Node.js. The project's advisory lists llhttp for all three lines, Undici for 24.x and 26.x, and SQLite for 22.x and 24.x. Not every affected component is visible as a dependency in an application repository, which is one reason routine npm package checks cannot replace runtime patching.

Why the technical details matter

Several findings involve HTTP/2, but they do not all have identical prerequisites or affect the same release lines. CVE-2026-123863 describes a process abort during HTTP/2 session cleanup; the official release notes list the fix for all three supported release lines: 22.x, 24.x and 26.x. CVE-2026-123875 concerns a separate HTTP/2 crash triggered when certain file downloads are cancelled, with the advisory listing all three active lines.

Other vulnerabilities affect TLS and HTTPS behaviour. CVE-2026-123864 concerns the interaction between TLS and HTTP parser execution. CVE-2026-123872 involves TLS session behaviour and rules around hostnames or client certificates. The release notes for 24.x and 26.x also list CVE-2026-126051, a remotely reachable TLS server crash under particular conditions.

These descriptions do not mean that every Node.js website exposes every vulnerability. An application that uses Node.js only to compile static pages has a different exposure from a publicly accessible server that processes HTTP/2 traffic. The exact risk depends on the runtime branch, enabled features, deployment architecture and whether an attacker can exercise the vulnerable code path.

A published CVE or *High* severity designation is not itself evidence of real-world exploitation. That is a separate question from the technical severity of a defect. In particular, the November issues should not be confused with the October Brotli vulnerability that was separately recorded as known exploited in CISA's catalogue.

Why patching a laptop may leave production exposed

Imagine a software agency supporting three customer websites. A developer upgrades the local Node.js installation, runs the test suite successfully and merges an updated Dockerfile. That sounds complete, but the live containers may still use an older image if they were not rebuilt and redeployed.

The same distinction applies when a cloud platform, website agency and internal IT team each control different parts of an application stack. One provider may manage the operating system while another is responsible for the application's runtime. Unless the ownership is explicit, a security notice can fall between those responsibilities.

The inventory must therefore cover running environments, not just source code. Identify Node.js versions used by production services, staging environments, scheduled jobs, workers and build pipelines. Execute node --version in the environment that actually runs the application, not merely on a developer's workstation. For managed services, request the equivalent version and deployment confirmation from the provider.

A deployment process that can be verified

Start by prioritising public-facing services and applications handling sensitive information. Record each service's Node.js major line, actual installed version, owner and update route. Select the corrected security build for its supported line.

Test the application against the patched runtime in a representative environment. Pay particular attention to HTTP/2, TLS, reverse proxies, authentication and integrations that might depend on runtime behaviour. Rebuild and redeploy immutable container images; changing a base-image reference alone does not alter a running process.

After deployment, confirm the active runtime version, test critical business journeys and review logs for unexpected process exits or connection failures. Keep a rollback plan available for compatibility problems while recognising that reverting to an affected version reintroduces the security risk.

Older end-of-life Node.js lines need their own migration plan. They do not receive the same ongoing security maintenance as supported lines. Nor should a business move a production application to an experimental Node.js 27 alpha merely because it has a newer number.

Turn security updates into routine maintenance

This release illustrates how much infrastructure sits underneath a JavaScript application. Business owners do not need to become protocol specialists, but they should have an accountable process for finding runtimes, applying vendor security fixes and confirming the result.

The useful question for a development or IT provider is not simply, “Has Node.js been updated?” Ask instead: “Which version is running in each production service, when was it deployed, and how was that checked?” That answer turns a security assurance into something an organisation can verify.

Sources: Node.js · Release 22 · Release 24 · Release 26