On 21 October 2026 the Node.js project shipped security releases for its three supported lines: 22.23.4, 24.22.1 and 26.12.1. Node.js's own release page lists ten CVEs: four rated high, three medium, three low. The same release also updates bundled c-ares, OpenSSL, SQLite and Undici, and ships a certificate-store update the page labels "ca-cert (eMudhra Intermediate CA Compromise)", the incident we covered in eMudhra certificate compromise: what to check in your container image.
You may have seen a different count. Hostinger's write-up is headlined "7 new Node.js vulnerabilities". Node.js's page enumerates ten, and that is the list below. We have not tried to reconcile the two.
The ten, as Node.js lists them
High:
- CVE-2026-111497, "Node.js Brotli decoder out-of-bounds write permits remote code execution". Credited to "OpenAI Codex Security - Khai Tran and Sylvie Mayer".
- CVE-2026-105482, "dns.resolve truncates names containing NUL char".
- CVE-2026-105483, "TLS certificate hostname bypass when the IP is written fullwidth digits".
- CVE-2026-106069, "TLS certificate hostname bypass when the host loosely resolves to an IP address".
Medium: CVE-2026-105481 (a keep-alive socket processes a response written before the request was sent), CVE-2026-106072 (improper certificate validation for non-canonical IPv4 hostnames), and CVE-2026-106074 (entropy caches for crypto.randomUUID() and randomInt() are saved into user-land startup snapshots and single executable applications, "so every process repeats the same values"). That last one is narrow: it applies to processes started from a snapshot or SEA, not to ordinary Node processes.
Low: CVE-2026-106070 (ZipFile, 26.x only), CVE-2026-106071 and CVE-2026-106073 (Permission Model).
The Brotli bug is the one to check your scope against. In Hostinger's words: "It only matters when an application decompresses Brotli data an attacker controls, such as a request body or a response fetched from another server." If your app accepts compressed uploads, or fetches from servers you do not control with Brotli enabled, you are in scope. Most apps that only serve responses are not touched by that one, but the TLS hostname bypasses apply to any outbound HTTPS call.
Why npm update does nothing here
Hostinger states the structural point plainly: "Because these flaws are in Node.js itself, updating your framework or npm packages won't fix them; you need a patched Node.js." Every one of the ten is in the runtime: the DNS resolver, the TLS stack, the Brotli decoder, the crypto module. Your package.json has no say in which Node binary runs it.
On a server you manage yourself, the fix is to upgrade the Node package and restart the process. In a container that path does not exist, and Hostinger's own advice for it is one sentence: "If you use containers, rebuild on a patched base image and redeploy." The Node binary lives in your image. Until the image is rebuilt from a patched base and the new image is running, nothing has changed, however many times the app restarts.
Check, then rebuild
- Find out what your image actually runs. Not what the Dockerfile says, what the built image contains:
A tag likedocker run --rm your-image:tag node -vnode:22-alpineis a moving target; the version baked into your last build is whatever that tag pointed at on the day you built. - Compare with the fixed version for your major line. 22.x needs 22.23.4 or later, 24.x needs 24.22.1 or later, 26.x needs 26.12.1 or later. If your image pins an older major that no longer gets security releases, this release does not cover it at all, and the only fix is moving to a supported line.
- Rebuild from a refreshed base. Pull the base image again so the build picks up the patched version, then rebuild:
docker pull node:22-alpine docker build --pull -t your-image:tag . docker run --rm your-image:tag node -v # expect 22.23.4 or later - Redeploy, then verify inside the running container. A rebuilt image that is not running protects nothing. After the deploy, check the version from inside the live container, not from your laptop.
- If you pin an exact tag, such as
node:22.22.2-alpine, step 3 changes nothing until you bump the tag. Pinning exact versions is good practice; it also means security releases are a change you have to make on purpose.
No exploit details here, by design. The release page has the affected ranges per CVE; the versions above are the whole of the fix.
Sources: Node.js, "Wednesday, October 21, 2026 Security Releases", read 22 October 2026 at 23:13 UTC; Hostinger, "Securing Node.js", published 22 October 2026, for the two quoted sentences on scope and containers.