Node.js Releases Urgent Security Fixes Across Three Active Branches

Table of Contents

• You might want to know
• Main Topic
• Key Insights Table
• Afterwards...

You might want to know

• Which Node.js branches and vulnerabilities are covered by the October 21 security release?
• Why should organizations using end-of-life Node.js versions act even if they cannot immediately install the latest patch?

Main Topic

Node.js published a security update on October 21, Taipei time, covering its active 26.x, 24.x, and 22.x release branches. The patched versions are 26.12.1, 24.22.1, and 22.23.4, respectively. According to the project’s security announcement, the releases address 10 vulnerabilities: 4 rated high, 3 medium, and 3 low. The highest severity in each branch is HIGH. The project also warns that end-of-life (EOL) versions may be affected by the same issues and encourages users to move to a supported release.

The update matters because Node.js is part of a broad developer and operations ecosystem. Front-end build pipelines, back-end APIs, and AI agent environments may rely on the same runtime, while npm packages and deployment images can make an older version persist long after a team has updated its application code. The immediate task is therefore practical: identify the deployed branch, install the corresponding patched version, and check whether related connection, compression, and certificate-validation components are also current.

The most prominent issue is CVE-2026-111497, a Brotli decoder out-of-bounds write. The official description says the flaw could lead to remote code execution. It affects all three active branches covered by the release: 26.x, 24.x, and 22.x. Brotli is used to decode compressed content, so systems that process data through this path should treat the patch as a priority. Exposure can depend on how an application handles incoming or intermediary content, but teams should not assume a deployment is safe without confirming its runtime and usage.

Three other vulnerabilities are rated high. CVE-2026-105482 concerns DNS resolution in cases where a hostname contains a null character and is truncated; it affects 26.x, 24.x, and 22.x. CVE-2026-105483 involves bypassing TLS certificate hostname verification when an IP address is written using full-width digits; the announcement lists 26.x and 24.x as affected. CVE-2026-106069 is another TLS hostname-verification bypass: it applies when a host resolves to an IP address after permissive parsing, and affects all three branches. These issues demonstrate why hostname parsing and certificate checks deserve attention alongside the headline compression vulnerability.

Not every high-severity issue applies to every current branch. For example, CVE-2026-105483 is listed for 26.x and 24.x, not 22.x. That variation makes it important to compare the official affected-version information with the actual version running in production, rather than treating the release as a single uniform patch. Organizations should also consider runtime copies embedded in containers, continuous integration images, developer workstations, and packaged tools. Updating only a primary server may leave other environments using a vulnerable release.

The medium-severity findings include CVE-2026-105481, involving keep-alive connections processing a response before a request has been sent; CVE-2026-106072, concerning improper TLS certificate validation for non-canonical IPv4 hostnames; and CVE-2026-106074, where cached values from crypto.randomUUID() or randomInt() can repeat across processes after being written into a user startup snapshot and a single executable application (SEA). All three affect 26.x, 24.x, and 22.x. The random-number issue is particularly relevant to teams that use snapshots or SEA packaging, because those deployment patterns can change how state is initialized and reused between processes.

The three low-severity issues are also branch-specific in some cases. CVE-2026-106070 affects only 26.x and concerns ZIP header validation that, after failure, can return attacker-controlled prefix bytes. CVE-2026-106071, also listed only for 26.x, involves filesystem wildcards in the permission model granting excessive access. CVE-2026-106073 concerns bypassing the permission model through fs.realpathSync and affects all three branches. Although these are rated low, the permission-model findings are relevant to applications that rely on runtime restrictions as one layer of defense. Such controls should be reviewed after upgrading, not treated as a substitute for patching.

The security releases also update third-party components used by Node.js. c-ares, the root certificate bundle—including action related to the eMudhra intermediate CA—and Undici updates apply to all three branches. OpenSSL updates are included for 24.x and 22.x, while SQLite updates are included for 22.x. The release notes list c-ares version 1.34.9, OpenSSL version 3.5.9, and the following Undici versions: 8.12.2 for 26.x, 7.30.1 for 24.x, and 6.29.1 for 22.x. These dependency changes are a reminder that runtime security can depend on bundled libraries as well as Node.js core code.

The recommended response is to map each deployment to its branch and upgrade to the matching patched version: 26.12.1, 24.22.1, or 22.23.4. Teams should verify the runtime inside production containers and CI images, check base images and local development tools, and confirm that lockfiles or build processes do not continue to pull in an older runtime. Where Node.js is managed centrally, update the relevant distribution or image and rebuild dependent applications. After deployment, teams can validate the effective version and review whether compression handling, DNS resolution, and TLS hostname checks follow the expected paths.

The same day, PHP also issued security updates. Its patched releases are 8.5.12, 8.4.27, 8.3.36, and 8.2.35, addressing two critical issues that could enable unauthenticated remote code execution: CVE-2026-109618 and CVE-2026-109619. For organizations operating both Node.js and PHP services, the timing puts pressure on multiple language runtimes at once. A practical response is to deploy official fixes first, then review reverse proxies, compression negotiation, and certificate-chain configuration as part of a broader assessment of the application stack.

Node.js remains a common foundation for cloud services, cryptocurrency trading interfaces, and AI agent toolchains. This release places the maximum severity at HIGH and explicitly identifies Brotli, TLS, and DNS handling as important areas of concern. For teams on supported branches, the shortest path to risk reduction is to install the matching security release and confirm that all runtime copies have been updated. For systems still running an EOL branch, the project’s guidance is to migrate to a supported version as soon as feasible, because those systems may remain exposed without receiving the same security fixes.

Key Insights Table

Afterwards...

The Node.js release underscores the need to treat runtime maintenance as an ongoing operational responsibility, not a one-time response to a prominent CVE. Teams can reduce the chance of overlooked exposure by tracking runtime versions across production, testing, CI, containers, and local tooling; maintaining a clear upgrade process; and reviewing the relevant official release notes whenever a security update is published.

The next step is to complete the upgrades, verify that each environment is actually running its patched release, and review the surrounding trust boundaries: compressed input, name resolution, certificate validation, and permission controls. Organizations that still depend on EOL Node.js should plan a migration to a supported branch. That work can take time, but leaving an unsupported runtime in place also leaves teams without the regular security coverage needed to respond to future vulnerabilities.