Node.js 26.13.1, 24.22.3 and 22.23.5: is the Node you actually run patched?

Check the Node on a container's PATH

Run these commands in a POSIX shell (Linux, macOS or WSL). Replace CONTAINER with the name of a running container:

docker exec CONTAINER sh -c 'echo "node $(node -p process.version 2>/dev/null || echo "not found") at $(command -v node || echo "no node on PATH")"; dpkg-query -W nodejs 2>/dev/null; apk list -I nodejs nodejs-current 2>/dev/null; true'

It prints the version and path of the node that PATH selects in a new shell in the container, and any installed nodejs package record from dpkg or apk. On 4 November it printed:

node v24.22.2 at /usr/local/bin/node

for the official node:24-slim image, and for a Debian 13 image with apt-get install nodejs:

node v20.19.2 at /usr/bin/node
nodejs	20.19.2+dfsg-1+deb13u3

Read it like this:

• The command prints the Node executable selected by PATH in this new shell and any installed nodejs package record. The path alone does not prove who built Node; an installed package record does not prove it owns that executable. An application may use another bundled executable. Use its documented runtime and package provenance before applying an upstream-version or distribution-tracker comparison.
• A distribution's nodejs package: its Node version can stay the same after a fix, because distributions patch their own builds. See distribution packages; the table above doesn't decide it.
• A nodejs package version ending in nodesource1: a NodeSource build, which follows nodejs.org's version numbers. Compare the version with the table above; the Debian and Ubuntu trackers do not cover it.
• no node on PATH: the application may carry its own Node in its own folder. An application that bundles Node gets the fix when its vendor ships a release with it.
• exec: "sh": executable file not found in $PATH: the image has no shell, as in Google's distroless Node images, so the check cannot run. docker inspect -f '{{.Config.Entrypoint}} {{.Config.Cmd}}' CONTAINER shows the program the container starts; if that is a Node executable, run it by its full path. For the distroless Node image, docker exec CONTAINER /nodejs/bin/node -p process.version printed v24.22.2 on 4 November. docker exec CONTAINER node -p process.version fails there, because node is not on PATH.

Run it in a container started from the image you actually run. A newer image on the registry changes nothing until the container is recreated from it, using the application's supported upgrade procedure; with plain Compose that is docker compose pull and then docker compose up -d. Without containers, run the part between the single quotes in a terminal on the server.

Check an image tag without running it. The official node images, and images built on them, declare the Node version in the NODE_VERSION variable of the image's environment. For a tag that holds several platforms, as the official images do:

docker buildx imagetools inspect --format '{{range (index .Image "linux/amd64").Config.Env}}{{println .}}{{end}}' node:24-slim | grep '^NODE_VERSION='

It fetches registry metadata without pulling filesystem layers or starting the image, and prints the NODE_VERSION declared in the environment of the linux/amd64 image; on an Arm server, put linux/arm64 in its place. On 4 November it printed NODE_VERSION=24.22.2. Put your own image in place of node:24-slim. If it stops with can't index item of type v1.Image, the tag holds a single platform; only then use this instead, with your image in place of IMAGE (on a tag with several platforms it prints nothing):

docker buildx imagetools inspect --format '{{range .Image.Config.Env}}{{println .}}{{end}}' IMAGE | grep '^NODE_VERSION='

The value is what the image's build declared, not a run of Node, and it is printed whole: n8nio/n8n:latest declared NODE_VERSION=26.12.1-r0, an Alpine package version rather than a nodejs.org one. If it prints nothing, no matching declaration was found; this does not establish how Node was installed. Use the docker exec check instead; for an image with no shell, see the last case under "Read it like this".

These commands need Docker Buildx; docker buildx version prints a version if you have it. Without it, Docker prints unknown flag: --format. Then download the image with docker pull IMAGE and read the same variable locally:

docker image inspect --format '{{range .Config.Env}}{{println .}}{{end}}' IMAGE | grep '^NODE_VERSION='

For node:24-slim it printed NODE_VERSION=24.22.2. Reads of Docker Hub images count toward Docker Hub's limit for users who are not logged in; if a read stops with 429 Too Many Requests, run docker login or wait.

When your Node gets the fix depends on where it comes from

Public timestamps and statuses from the previous Node security release, 21 October 2026 (fixed versions 22.23.4, 24.22.1 and 26.12.1; nodejs.org's SHASUMS256.txt files are dated 10:32–10:36 UTC). Each row names what was recorded; not every row measures when a runnable package became available.

What follows from it:

• Tags: A major-version tag such as node:24-slim can advance to a newer Node release when the publisher updates it. A patch-version tag such as node:24.22.2-slim does not select a newer Node patch version automatically, so update that reference yourself. Tags can be republished; a digest pins image bytes. Pull, rebuild where applicable, and recreate the intended service using the application's supported upgrade procedure. docker build --pull fetches the base image again instead of reusing a local copy.
• GitHub Actions: actions/setup-node with node-version: 24 first uses a Node already cached on the runner if one matches, and that copy can be older than the newest release. With check-latest: true it picks the newest matching version in GitHub's version manifest (setup-node documentation); that manifest can lag a new nodejs.org release. To be sure, request the fixed patch version from the security release, such as node-version: 24.22.3, and check node --version after the setup step. Update that pin when a later fixed patch is needed.
• Alpine: nodejs and nodejs-current are separate packages, and each Alpine branch moves separately. Check the package you install on the branch you build from.
• Debian and Ubuntu apt install nodejs: For CVE-2026-105482, Debian's tracker listed the named bookworm, trixie and forky packages as vulnerable on 4 November. Ubuntu listed the named releases as “Needs evaluation”; that does not establish whether they are affected or fixed. Check your vendor's status for each CVE relevant to your package.
• Applications and managed runtimes that bundle Node, such as Kibana, Electron apps or a cloud provider's Node runtime, get the fix only when their vendor ships it. Their own release notes or issue tracker is the place to look; in a self-hosted container of theirs, the check above shows the Node on PATH, which may not be the one the application uses.

Distribution packages

Debian and Ubuntu patch the Node version they ship rather than move to a new one, so node -p process.version keeps printing the same version after their fix. Compare the package version from the check above with the security tracker of your distribution for the CVE IDs in nodejs.org's list:

• Debian: https://security-tracker.debian.org/tracker/ followed by the CVE ID. Our Debian 13 test image had 20.19.2+dfsg-1+deb13u3, the version Debian's tracker listed as vulnerable for CVE-2026-105482 (from the October release) on 4 November.
• Ubuntu: https://ubuntu.com/security/ followed by the CVE ID.
• Alpine: Alpine packages for your branch and package (nodejs or nodejs-current). In October, Alpine's updated packages carried the new upstream versions (24.22.1 and 26.12.1), so there the package version follows the upstream one. An older version on your branch does not by itself show whether Alpine backported a fix to it.

If you are on Node 20

There is no Node 20 release to update to. Node 22 is supported until 30 April 2027, Node 24 until 30 April 2028 (Node release schedule). In Docker, that is FROM node:22 or FROM node:24 instead of node:20, plus your own .nvmrc or engines field if you pin one; build with docker build --pull. Debian 13's nodejs package is Node 20 maintained by Debian: whether it gets a fix is up to Debian, and its tracker says.

Why a clean scan is not enough

The report in nodejs/security-wg#1590 recorded nine October-release CVEs as RESERVED at 20:53 UTC on 22 October. Tools that rely on those published records may miss those CVEs until their data is available and ingested. A clean scan alone does not establish that your Node is patched; check the applicable upstream version or distribution tracker.

Status of common images and packages

Last read: 11 Nov 2026, 22:40 UTC.

Docker node:20: 20.20.2; end of life, no upstream November release. Read 22:40 UTC.

Distribution packages: the tracker status for CVE-2026-123863 only. It is not a verdict on the other CVEs in this release; check each one on your vendor's tracker.

Each row is a dated read of an image configuration, a package index or a vendor's tracker. Image rows read the NODE_VERSION declared in the linux/amd64 image's environment, not a running Node. "Yes" and "No" compare a declared or listed upstream version with the fixed version on the same release line only; they do not establish whether an application is exploitable. Alpine rows show "Listed" when the package version is below the fixed upstream version, because Alpine can backport a fix. Distribution rows quote the vendor's tracker status for one named CVE; that is not a verdict on the release's other CVEs. Unknown means a failed read, no single declaration, a value that is not a plain upstream version, or a version on another line. Every row stays: a failed refresh shows Unknown with the attempted read time, or keeps the old value with its old read time. We plan to refresh this table about 1, 6, 24 and 72 hours after the release.

What nodejs.org says about the vulnerabilities

nodejs.org lists:

It also lists dependency updates: llhttp on 22.x, 24.x, 26.x; undici on 24.x, 26.x; sqlite on 22.x, 24.x. This page covers versions only. For what each vulnerability does and which applications it reaches, read nodejs.org's release notes.

Receipts

Commands we ran on 4 November 2026, 10:58–11:07 and 11:10–11:52 UTC, linux/amd64, on our own machine:

We ran the check as sh -c in new containers without network access, and again through docker exec on long-running containers from bash and dash. For Compose we changed the local image tag instead of pulling from a registry: the running container kept its old Node until docker compose up -d recreated it. The 21 October times come from commit and release timestamps, the Last-Modified dates of the files and the package build dates named in that table, read on 4 November. We did not run docker compose pull against a registry, docker build --pull, setup-node, or these commands in Windows shells; those steps follow Docker's and GitHub's documentation.

Sources: nodejs.org release notes, advance notice of 3 November and October release notes; nodejs.org/dist/index.json; docker-library/official-images; actions/node-versions; Homebrew/homebrew-core; Alpine packages; Debian security tracker; Ubuntu CVE reports.

Prepared by CyberNative AI LLC, an AI-run company, using AI agents. If something here is wrong, write to hello@cybernative.ai; we correct this page and date each correction.