Node.js October Security Release: What to Patch and How

Choose the fixed release for your current line

Treat this as a runtime maintenance task you should schedule promptly. The Node.js project rates the highest severity fixed as High across 26.x, 24.x and 22.x. For an application already on a supported line, we would apply its security release before considering a separate major upgrade.

These targets come from the Node.js project's October security announcement. They identify this release's fixes, rather than a permanent recommendation to pin an application indefinitely. If you are reading later, check the official advisory and release pages before selecting your deployment target.

The Node.js release schedule on GitHub gives 22.x support until 2027-04-30 and 24.x support until 2028-04-30. It records end-of-life for 20.x on 2026-04-30 and 25.x on 2026-06-01. The Node.js security announcement states that End-of-Life versions are always affected when a security release occurs.

Find the executable your application actually runs

On Ubuntu 24.04 LTS, start by distinguishing your interactive shell from your application service. A shell can use a version manager while systemd starts a package-managed executable elsewhere. A container can carry another runtime entirely, so a reassuring shell result does not close the investigation.

if command -v node >/dev/null 2>&1; then
  command -v node
  readlink -f "$(command -v node)"
  node --version
  node -p 'process.execPath'
else
  printf '%s\n' 'No Node.js executable on this shell PATH'
fi
if dpkg-query -W -f='${Status}\n' nodejs 2>/dev/null; then
  apt-cache policy nodejs
fi

For a systemd deployment, inspect the actual unit next. The commands below use app.service as an example: replace it with your application's unit before running them. Read the launch command and working directory, then inspect the service's process tree if the main process is a wrapper.

sudo systemctl cat app.service
sudo systemctl show app.service -p ExecStart -p WorkingDirectory -p User -p MainPID
sudo systemctl status app.service --no-pager

Compare the discovered runtime with the fixed target for its line. An upstream runtime below that target needs attention; an Ubuntu package may instead carry a backported fix, which requires confirmation from Ubuntu's package security information. If your launch arrangement is unclear, use the VPS deployment procedure to make the executable and service relationship explicit.

Assess exposure and prepare a recoverable deployment

The Node.js project describes CVE-2026-111497 as a High-severity Brotli decoder out-of-bounds write permitting remote code execution, affecting 26.x, 24.x and 22.x. It credits OpenAI Codex Security with reporting it. Prioritize applications that feed untrusted compressed data into the decoder, while treating a missing exposure assessment as unfinished work.

The advisory also identifies CVE-2026-106069, a High-severity TLS certificate hostname bypass when the host loosely resolves to an IP address, affecting those same lines. Outbound connections therefore belong in your review alongside incoming requests. A reverse proxy does not replace a runtime patch.

Before changing the service, preserve its current unit configuration and record the deployed application artifact. Keep the existing dependency lockfile available so you can rebuild the same application against the replacement runtime. Check that you have a usable application backup before making a major-version migration.

On a single VPS, arrange a maintenance window if restarting interrupts requests. We would give Claude Code read-only discovery first, then approve a bounded change naming the runtime target and affected service. The production agent guardrails help keep that authorization narrow enough to review.

Install the replacement through the correct path

Keep the installation method consistent where it can deliver the fix. For an apt-managed runtime, refresh package metadata and confirm the candidate's security status with its publisher before upgrading; package installation alone does not prove remediation. For a version manager, install the exact target as the service owner and inspect the service's absolute executable path afterward.

For an explicit systemd deployment, the following alternative installs an official Node.js binary under a separate versioned directory. It defaults to v24.22.1; change node_release to v22.23.4 or v26.12.1 to stay on either of those lines. Run this only after choosing the line your application supports.

(
set -eu
node_release=v24.22.1
sudo apt-get update
sudo apt-get install -y ca-certificates curl xz-utils
case "$(dpkg --print-architecture)" in
  amd64) node_arch=x64 ;;
  arm64) node_arch=arm64 ;;
  *) printf '%s\n' 'Use the official release instructions for this architecture'; exit 1 ;;
esac
case "$node_release" in
  v22.23.4|v24.22.1|v26.12.1) ;;
  *) printf '%s\n' 'Select an October fixed release'; exit 1 ;;
esac
node_work=$(mktemp -d)
node_archive="node-${node_release}-linux-${node_arch}.tar.xz"
node_target="/opt/node-${node_release}"
cd "$node_work"
curl --fail --show-error --silent --location --proto '=https' --tlsv1.2 --output "$node_archive" "https://nodejs.org/dist/${node_release}/${node_archive}"
curl --fail --show-error --silent --location --proto '=https' --tlsv1.2 --output SHASUMS256.txt "https://nodejs.org/dist/${node_release}/SHASUMS256.txt"
awk -v archive="$node_archive" '$2 == archive { print }' SHASUMS256.txt > selected-checksum.txt
test -s selected-checksum.txt
sha256sum --check selected-checksum.txt
tar --extract --xz --file "$node_archive" --no-same-owner
test ! -e "$node_target"
sudo install -d /opt
sudo cp -a "node-${node_release}-linux-${node_arch}" "$node_target"
sudo chown -R root:root "$node_target"
test "$("$node_target/bin/node" --version)" = "$node_release"
"$node_target/bin/node" -p 'process.execPath'
)

The checksum detects a mismatched download against the manifest fetched over HTTPS; it is not independent signature verification. This installation leaves the application's launch configuration untouched, so the next step is mandatory. The Node.js v24.22.1 release page is the official reference for that release's artifacts and changes.

For Docker, update the runtime in the image definition and rebuild the final runtime image before recreating the service. Updating the host executable cannot patch an image's runtime. Follow the Docker Compose production checklist when checking that the recreated container uses the intended image.

Point the service at the fixed runtime and restart it

Preserve the application's existing arguments and working directory when changing its executable. The example below assumes a direct Node launch of /srv/app/server.js through app.service; adapt both to the unit you inspected. Do not replace a wrapper command until you understand what that wrapper configures.

[Service]
ExecStart=
ExecStart=/opt/node-v24.22.1/bin/node /srv/app/server.js

Save the adapted override as /etc/systemd/system/app.service.d/node-runtime.conf, creating the drop-in directory if necessary. If child processes invoke node or npm through PATH, configure their runtime selection explicitly too, preserving any application-specific search paths. Keep the existing service identity and security restrictions.

sudo systemctl daemon-reload
sudo systemctl restart app.service
sudo systemctl is-active app.service
sudo systemctl status app.service --no-pager

If the application has native dependencies, rebuild the deployment artifact using the selected runtime and its normal locked dependency installation procedure. Avoid an unrelated dependency upgrade during this change. When CI owns deployment, update the runtime there as well, following the GitHub Actions deployment procedure so the next release preserves the fix.

Verify the running process and application behavior

A process that was already running does not become patched when you place a new executable on disk. For a service whose main process is Node directly, inspect the executable through its live process identifier. The example deliberately checks the process reference instead of your shell's PATH.

(
set -eu
node_pid=$(sudo systemctl show app.service -p MainPID --value)
test "$node_pid" -gt 0
sudo readlink "/proc/$node_pid/exe"
sudo "/proc/$node_pid/exe" --version
sudo journalctl -u app.service --since today --no-pager
)

Exercise a real application request through the public entry point, then check a representative operation that makes an outbound TLS connection. Review startup and request logs for certificate failures or dependency loading errors. A successful homepage response can miss a broken background worker.

Check separately managed workers and scheduled jobs using their own launch definitions. If application health fails, prefer correcting the configuration while retaining the patched runtime. Restoring a vulnerable runtime is an incident tradeoff requiring an explicit exposure decision, rather than a routine successful rollback.

Update the deployment source before closing the change

Record the selected runtime in the repository configuration that controls your next deployment. Update container build definitions or service provisioning files where appropriate, and preserve the application checks that established compatibility. A manual production repair remains fragile until a normal deployment reproduces it.

If you use managed hosting, confirm who owns runtime updates and how you inspect the deployed version before considering the task complete. When evaluating an alternative, use the Next.js hosting comparison to assess the operational responsibility you would retain. Hosting choice should make runtime ownership clearer.

Your concrete next action is to run the normal deployment process with the patched runtime selection committed, then repeat the live-process check. Attach the executable path and application health result to the change record. Assign an owner to review the next Node.js security announcement so patching does not depend on someone noticing a headline.