Node.js’ October Security Release Fixes DNS, TLS and Brotli Risks Across Three Lines

The October 21 Node.js security release is easy to mistake for a routine version bump. It spans three actively supported major lines and includes fixes to network-facing behavior, including DNS handling and a Brotli decoder issue. The useful response is operational: map where Node runs, update the runtime actually used there, and confirm that each long-lived process has restarted on the patched binary.

The supported lines and releases

The Node.js Project published security releases for v26, v24 and v22. The corresponding versions listed on the release pages are 26.12.1 (Current), 24.22.1 (LTS) and 22.23.4 (LTS). The project advises production applications to use Active or Maintenance LTS lines; v26 is currently in the Current phase, so teams should weigh their compatibility requirements and support policy before selecting it for production. ^{[1] [3]}

The advisory says the highest severity issue in each line is rated High. It also records dependency updates for c-ares, certificates, OpenSSL, SQLite and Undici across the affected lines. The exact dependency changes differ by branch, so operators should use the release notes for their selected version rather than assuming every line contains an identical set of changes. ^[1]

What the fixes mean for operators

One high-severity DNS issue involves hostnames containing a null byte. The advisory says Node’s dns.resolve*() functions and dns.reverse() could pass a truncated value to the c-ares resolver without returning an error. That means code validating one hostname and code resolving another could disagree about the value being processed. The project identifies the issue as CVE-2026-105482 and describes it as an incomplete fix for a related earlier case that affected other APIs. ^[1]

The release also addresses high-severity problems in TLS handling and the bundled Brotli decoder. The advisory describes CVE-2026-106069 and CVE-2026-106072 as a TLS issue involving non-canonical IP addresses, and CVE-2026-111497 as an out-of-bounds write in the Brotli decoder that permits remote code execution. These descriptions are drawn from the Node project’s advisory; do not infer exploitability for a particular service without checking its usage and the full release notes. ^[1]

There are also medium- and low-severity changes in the same release, including crypto snapshot cache handling and a permission-model check in realpathSync(). Security releases often combine issues with different preconditions. Prioritize the upstream update, then assess application-specific exposure using your own dependency and traffic inventory. ^[1]

A practical patch workflow

1. Find every runtime, not just every repository. Inventory containers, serverless functions, build agents, desktop services and managed hosting environments. Check the runtime embedded in the deployment image or platform, not only the project’s package.json declaration.
2. Map each workload to a supported line. Confirm whether it uses v22, v24, v26 or an end-of-life branch. The project’s release status page is the source for current lifecycle state; older lines may have different availability through a hosting vendor. ^[3]
3. Update the runtime and lock the intended base. Select the current patched release for that line, rebuild images and update version pins in CI or deployment configuration. If an organization relies on a vendor-provided backport, document the vendor’s advisory and affected package boundary.
4. Restart long-lived processes. A package upgrade on disk does not replace the Node binary already loaded into a running process. Roll deployments through the service manager or platform, then verify the process version from the running environment.
5. Exercise network and decompression paths. Run representative DNS, TLS and compressed-response workflows through staging and health checks. Look for regressions from runtime changes and confirm that the expected binary is active after restart.
6. Check EOL workloads separately. The Node.js security notice states that end-of-life versions are affected when a security release occurs. If a workload cannot move immediately, isolate it, assess whether a maintained vendor backport exists, and set a dated migration owner. ^[1]

The version command in a developer shell is not sufficient evidence for a server deployment. A container might still be running an image built weeks earlier; a process manager may have kept an old worker alive; a platform’s runtime selection can differ from the local toolchain. Tie verification to the workload that receives traffic.

Do not read a release date as an exposure test

The Node advisory establishes which branches were updated and what classes of defects changed. It does not reveal whether a particular application calls the affected APIs, accepts attacker-controlled hostnames or processes untrusted compressed data. Conversely, a team should not wait for an exploit demonstration before applying a vendor security release. The project’s stated severity and the breadth of the lines make inventory and patch verification the sensible first steps.

The Node.js security policy explains the project’s process for reporting and handling security issues. The release status page should be checked again during rollout because the exact patch version can be superseded. After updating, verify both the artifact and the running process, then record any line that remains unsupported.