Node.js is a critical component of many production environments, powering REST APIs, background workers, web applications, and real-time services. Keeping the runtime updated is an important part of maintaining server security.

On April 30, 2026, Node.js 20 reached End of Life (EOL). This means it no longer receives official upstream security updates. The October 21, 2026 Node.js security releases addressed multiple vulnerabilities, including high-severity issues involving DNS resolution, TLS certificate validation, and the Brotli decoder.

For administrators running Node.js applications on Debian 12 Bookworm, migrating from Node.js 20.x to Node.js 24.x is a practical step toward a supported runtime.

This guide covers the migration using APT and the NodeSource repository, including pre-upgrade checks, installation, application validation, and post-upgrade security verification.

Why Upgrade Node.js 20?

End-of-life software introduces a security maintenance problem. When vulnerabilities are discovered after a release line reaches EOL, upstream maintainers no longer provide official fixes for that release line.

The October 21, 2026 security release illustrates why runtime maintenance matters.

According to the official Node.js security advisory, the release addressed several vulnerabilities affecting supported release lines. Examples include:

• CVE-2026-105482 — High: DNS resolution can truncate names containing a NUL character.
• CVE-2026-105483 — High: TLS certificate hostname validation can be bypassed when an IP address is represented using fullwidth digits.
• CVE-2026-106069 — High: TLS certificate hostname validation can be bypassed in certain cases involving hostnames that loosely resolve to IP addresses.
• CVE-2026-111497 — High: A Brotli decoder out-of-bounds write can permit remote code execution.

The advisory also identifies medium-severity issues involving HTTP keep-alive handling, certificate validation, and random-number generation.

The exact impact depends on the application, runtime version, and reachable code paths. An upgrade should therefore be accompanied by application testing rather than treated as a substitute for a security assessment.

References:

• Node.js security release: https://nodejs.org/en/blog/vulnerability/october-2026-security-releases
• Node.js release schedule: https://github.com/nodejs/Release
• Node.js End-of-Life information: https://nodejs.org/en/about/eol

1. Check the Existing Node.js Installation

Before changing anything, confirm the installed version and how APT manages the package.

node -v
npm -v
which node
which npm

apt-cache policy nodejs

dpkg-query -W -f='${Package} ${Version}\n' nodejsCode language: JavaScript (javascript)

If the installed runtime is Node.js 20.x and the package is managed by APT, continue with the following procedure.

Check whether other installations exist:

type -a node
type -a npm
readlink -f "$(command -v node)"Code language: JavaScript (javascript)

Multiple Node.js installations can cause confusion when a shell, PM2 process, or systemd service uses a different executable from the one upgraded by APT.

This guide assumes that the active runtime is managed by APT, normally through NodeSource.

2. Prepare for the Upgrade

Perform the upgrade during a maintenance window if the server hosts production applications.

Record the current versions and application status:

node -v
npm -v
pm2 -v
pm2 listCode language: PHP (php)

If you use PM2, save its current process configuration:

pm2 save
pm2 startup

The second command displays the startup configuration command if one needs to be configured. Follow its instructions only if necessary.

Back up application configuration and ensure that source code, environment files, and deployment manifests are recoverable. For applications managed through Git, confirm that the working tree and deployed commit are known.

Also check whether the application uses native Node.js modules. Packages that include compiled binaries may require rebuilding or reinstalling after a major runtime upgrade.

3. Configure the NodeSource Node.js 24.x Repository

Debian 12’s standard repositories do not necessarily provide the desired Node.js major version. NodeSource provides APT packages for Node.js 24.x on Debian 12.

Install the required tools:

sudo apt update

sudo apt install -y \
  ca-certificates \
  curl \
  gnupg

Download the NodeSource setup script:

curl -fsSL https://deb.nodesource.com/setup_24.x \
  -o /tmp/nodesource_setup_24.xCode language: JavaScript (javascript)

Run the script:

sudo -E bash /tmp/nodesource_setup_24.x

This configures the NodeSource repository for the Node.js 24.x release line.

Repository reference:

https://github.com/nodesource/distributions

4. Upgrade Node.js Using APT

Refresh the package index:

sudo apt update

Check the installed and candidate versions:

apt-cache policy nodejs

Confirm that the candidate comes from the intended NodeSource repository and belongs to the Node.js 24.x release line.

Then install the package:

sudo apt install -y nodejs

APT will upgrade the installed Node.js package when the repository offers a newer candidate version.

Security note: Do not assume that installing any version of Node.js 24 is sufficient. For the October 21, 2026 security release, the published Node.js 24.x release is 24.22.1. Verify the version installed on your server against the official advisory and install the latest patched release available from your configured repository.

5. Verify the Installed Runtime

After installation, check the Node.js version, npm version, executable location, and package metadata:

node -v
npm -v

which node
readlink -f "$(command -v node)"

apt-cache policy nodejsCode language: JavaScript (javascript)

The Node.js version should begin with v24..

For the October 2026 security release, the expected patched Node.js 24.x version is v24.22.1, or a later security-fixed version if one has subsequently been published.

Do not rely on the major version alone. A server running an older 24.x release may still be vulnerable to issues fixed in a later patch release.

6. Validate Application Dependencies

Moving from Node.js 20 to Node.js 24 is a major-version upgrade. Applications may encounter changes in runtime behavior, dependencies, or native modules.

Navigate to each application directory and inspect its dependency manifest and lockfile.

For an npm-managed application:

cd /path/to/your/application

npm ls --depth=0

If you need to reinstall dependencies, use the existing lockfile:

npm ci

Run npm ci only when it is appropriate for your deployment workflow; it removes the existing node_modules directory and reinstalls the locked dependencies.

Run the application’s automated tests and any project-specific validation commands. Check packages that depend on native compilation, Node.js APIs, OpenSSL behavior, or runtime-specific binaries.

Do not automatically delete lockfiles or upgrade every dependency as part of the runtime migration. Keeping the runtime upgrade separate from unrelated dependency changes makes problems easier to diagnose.

7. Restart Applications Managed by PM2

If your applications run under PM2, verify the process list:

pm2 list
pm2 reportCode language: PHP (php)

Restart applications in a controlled sequence:

pm2 restart <app-name>Code language: HTML, XML (xml)

Replace <app-name> with the actual PM2 application name.

Inspect the logs:

pm2 logs <app-name> --lines 100Code language: HTML, XML (xml)

Confirm that each application starts successfully, serves requests, connects to its databases and message queues, and processes background jobs as expected.

For applications that use PM2 cluster mode, verify that all workers are healthy after the restart.

If PM2 was installed globally through npm and behaves unexpectedly after the Node.js upgrade, verify its executable location and installation before changing its configuration.

8. Validate systemd Services and Other Processes

Not every Node.js application runs under PM2. Some deployments use systemd, cron jobs, containers, or custom service managers.

For systemd-managed services, inspect the service configuration:

systemctl cat your-service.service
systemctl status your-service.serviceCode language: CSS (css)

Check whether the service uses an explicit Node.js executable path or a custom environment. A service may continue to use a different runtime if its executable is bundled with the application or comes from another installation.

After the appropriate controlled restart, inspect logs:

journalctl -u your-service.service -n 100 --no-pagerCode language: CSS (css)

For Docker deployments, upgrading the host’s APT package does not upgrade Node.js inside existing containers. Update the container image and rebuild or redeploy the affected application separately.

9. Final Security Checklist

Before considering the migration complete, verify the following:

• Node.js 20 is no longer the active runtime for the application.
• Node.js 24.x is installed through the intended APT repository.
• The installed version includes the required security fixes.
• Application dependencies are compatible with Node.js 24.
• Native modules have been validated or rebuilt where necessary.
• PM2 and systemd-managed applications have been tested.
• API endpoints, database connections, and background workers are functioning.
• Application logs contain no new startup errors or unexpected exceptions.
• The deployment configuration and rollback procedure are documented.

Keep monitoring official Node.js security advisories after the upgrade. Security maintenance is an ongoing process, not a one-time installation.

Conclusion

Upgrading Node.js from 20.x to 24.x on Debian 12 using APT provides a straightforward migration path to a maintained runtime. The October 2026 security releases reinforce the importance of keeping Node.js patched, especially for services exposed to untrusted network traffic.

The migration should include more than installing a new package. Administrators must verify the exact patched version, validate application dependencies, restart services safely, and confirm that the new runtime is actually being used in production.

For production systems, a repeatable upgrade procedure combined with regular security monitoring helps reduce exposure to known vulnerabilities while keeping application downtime under control.

Official references

• Node.js October 2026 security releases: https://nodejs.org/en/blog/vulnerability/october-2026-security-releases
• Node.js release schedule: https://github.com/nodejs/Release
• Node.js End-of-Life information: https://nodejs.org/en/about/eol
• NodeSource Debian installation instructions: https://github.com/nodesource/distributions