Node.js released security updates for its 22, 24 and 26 branches on October 21, 2026. If you run an API, a server-rendered website or a bot, check the runtime used by every service, not just the one in your terminal. The official patched releases are 22.23.4, 24.22.1 and 26.12.1.
The project's advisory lists 10 CVEs: four high, three medium and three low severity. It does not provide a global count of attacked systems. Running an affected version does not establish that your server has been compromised.
Which Node.js version should you install?
For an existing deployment, start with the patch for your current branch and validate compatibility. You do not need to move from 22 to 26 to receive these fixes. If your version is end-of-life, plan a migration to a maintained branch: absence from this table does not make it safe.
These numbers refer to official project binaries. If your distribution maintains a package with backported fixes, request its security notice and exact patched package version; checking only the version printed by Node may not be sufficient.
The 10 CVEs and their confirmed scope
This table summarizes the bulletin and the three release notes linked above. Branches identify where the project reports an issue, not whether every application uses the affected feature. Individual severity follows the bulletin, which distinguishes the two TLS CVEs grouped together in the release notes.
| CVE | Issue and severity | Branches |
|---|---|---|
| CVE-2026-105482 | DNS names truncated at a NUL character. High. | 22, 24, 26 |
| CVE-2026-105483 | TLS hostname validation with fullwidth digits. High. | 24, 26 |
| CVE-2026-106069 | TLS hostname validation when a host resolves loosely to an IP. High. | 22, 24, 26 |
| CVE-2026-111497 | Brotli out-of-bounds write; potential remote code execution. High. | 22, 24, 26 |
| CVE-2026-105481 | HTTP keep-alive accepts a response predating its request. Medium. | 22, 24, 26 |
| CVE-2026-106072 | TLS non-canonical IPv4 authenticated using certificate DNS names. Medium. | 22, 24, 26 |
| CVE-2026-106074 | Random caches repeated through startup snapshots or SEAs. Medium. | 22, 24, 26 |
| CVE-2026-106070 | ZipFile returns bytes after ZIP header validation fails. Low. | 26 |
| CVE-2026-106071 | Permission Model grants excessive filesystem access with wildcards. Low. | 26 |
| CVE-2026-106073 | Permission Model check bypass in fs.realpathSync. Low. | 22, 24, 26 |
What this means for a website, API or bot on a VPS
Our recommendation is to update all services on affected branches, prioritizing those processing external input. These questions help organize the work better than inferring risk from a framework's name:
- Do you decompress Brotli content from third parties? Identify where that data reaches Node's decoder. The memory flaw deserves priority, but the advisory does not show that any HTTP request can automatically exploit any application.
- Does your application make outgoing HTTPS connections? Include payments, webhooks and API integrations in post-deployment tests. A valid certificate at your reverse proxy's entrance does not verify how Node authenticates outbound destinations.
- Do you distribute startup snapshots or single executable applications (SEAs)? These are artifacts containing startup state or packaged executables. Review their rebuild process as well as the runtime. A Node startup snapshot is not a VPS disk snapshot.
- Do you use the Permission Model? Update those processes too. Node.js documentation explicitly says this feature is not a security boundary for running malicious code.
The consequences of a compromise depend on the process's permissions and accessible resources. As an additional defense, run applications without administrator privileges and limit their credentials. These controls reduce exposure; they do not replace the patch.
Check your version without running an exploit
The following commands are diagnostic. They do not exploit these vulnerabilities or establish that a server is clean:
node --version
node -p 'JSON.stringify({node:process.version,execPath:process.execPath,openssl:process.versions.openssl},null,2)'
The first reports the version; the second adds the executable path and that process's OpenSSL version. They describe only the Node process just started by your shell. A systemd service, another user or PM2 may start a different binary.
For Docker, replace CONTAINER_NAME with one of your application containers:
Run your API or bot on a VPS with clear maintenance
Compare TERAMONT VPS plans for your project. Define who manages the runtime, deploys patches and verifies each service.
docker exec CONTAINER_NAME node --version
This checks the executable available inside that container; it does not prove an older worker was restarted. Log the version internally when the application starts, using a snippet such as:
console.info('runtime-start', {
node: process.version,
execPath: process.execPath,
pid: process.pid
});
After deployment, find the new startup entry for every replica or worker. Do not expose these paths through a public diagnostics endpoint. The process reference documents these fields.
Update without leaving old processes running
- Inventory execution points. Include APIs, websites, workers, bots, scheduled tasks, containers and CI builds. Record an owner, version, installation source and restart procedure for each.
- Prepare the change. Preserve configuration and data needed to restore service. Run your normal tests against the patch; avoid combining a security update with unnecessary framework and dependency migrations.
- Install through the channel managing that runtime. Use official downloads or your provider's patched package. For containers, update the base, rebuild and deploy the new image. Updating the host's Node does not update a container.
- Activate the patched binary. Restart or replace processes through your service manager's deployment procedure. Check the interpreter path in PM2 or systemd. In replicated deployments, verify that no older instance remains in the traffic pool.
- Validate and retain evidence. Record the startup version, deployed image or package, timestamp and functional tests of important routes. Check TLS errors, outgoing connections and background jobs.
Hypothetical example: you update an API and its terminal reports 24.22.1, but a worker still uses an older image. The task is unfinished even if the homepage loads. Verification must cover both processes.
This release also addresses the eMudhra incident
The Node.js 22.23.4 release notes include NSS 3.131.1 root certificates and rejection of chains containing blocked public keys; the other two branches also incorporate trust changes. This is another reason to test HTTPS integrations after deployment. Custom CA stores need their own review; do not disable TLS verification to conceal errors.
Questions before closing the update
Will npm audit or npm update patch the runtime?
No. npm audit checks dependencies; a clean report does not certify the Node.js executable's security. Updating project packages and updating the runtime are separate tasks.
Will moving to another VPS or updating the kernel fix this?
Not by itself. The relevant question is which Node binary runs your application. Ask your provider which layer it manages and which maintenance tasks belong to you. Do not assume it updated your containers or per-user installations.
How can I tell whether someone already attacked me?
A version check identifies a pending update, not an intrusion. If you find unknown processes, unauthorized changes or unusual access, preserve logs and begin incident response. Updating alone does not remove persistence from an earlier compromise.
Infrastructure with clear maintenance responsibilities
If you need infrastructure for an API or bot, compare TERAMONT VPS Hosting plans. Decide who installs Node, deploys patches and verifies running processes from the outset. If you are getting started, read what a VPS is and how it works. Close this advisory when a patched version is running and verified, not merely downloaded.
