# Node.js October 2026 security update: affected versions, Docker and Next.js

Published: 2026-10-25 | Updated: 2026-10-25 | URL: https://blog.genko.me/en/nodejs-security-release-2026-10

> Check the October 2026 Node.js security fixes, upgrade to 22.23.4, 24.22.1 or 26.12.1, and verify Docker, CI and deployed framework runtimes.

Node.js released fixes for ten vulnerabilities on October 21, 2026, including Brotli decompression and TLS certificate validation issues. Update Node.js 22 to 22.23.4, Node.js 24 to 24.22.1, or Node.js 26 to 26.12.1. Next.js, Astro, Nuxt and SvelteKit projects belong in your inventory wherever their builds or servers run on Node.js. [Official announcement](https://nodejs.org/en/blog/vulnerability/october-2026-security-releases)

## Which Node.js versions contain the October 2026 fixes?

These are the releases containing this security update:

| Release line | Fixed release | Release notes |
| --- | --- | --- |
| 22.x | 22.23.4 | [Node.js 22.23.4](https://nodejs.org/en/blog/release/v22.23.4/) |
| 24.x | 24.22.1 | [Node.js 24.22.1](https://nodejs.org/en/blog/release/v24.22.1/) |
| 26.x | 26.12.1 | [Node.js 26.12.1](https://nodejs.org/en/blog/release/v26.12.1/) |

Start with the patched release in your current supported line. A major-version migration is a separate compatibility decision. If a later patch is available, read that line's subsequent release notes as well.

An end-of-life line missing from this table is not a safe alternative. Move it to a supported release line rather than treating the absence of an October release as evidence that it is unaffected.

## Which vulnerabilities were fixed?

Severity below follows the Node.js announcement. Affected lines mean the applicable releases before these fixes; they do not mean every application on that line exposes every attack path. The individual CVE records are linked under Sources.

| CVE | Severity | Affected lines | Plain explanation | Relevant application behavior |
| --- | --- | --- | --- | --- |
| CVE-2026-105482 | High | 22, 24, 26 | A NUL byte truncates a DNS name | Validating hostnames before using `dns.resolve*()` or related resolution |
| CVE-2026-105483 | High | 24, 26 | Non-ASCII IP spellings bypass certificate matching | TLS clients connecting to IPs written with characters such as fullwidth digits |
| CVE-2026-106069 | High | 22, 24, 26 | Certificate checks and connections can use different IP interpretations | TLS clients using leading-zero IPv4 literals on affected resolver platforms |
| CVE-2026-111497 | High | 22, 24, 26 | Brotli decoding writes outside a buffer | Decompressing attacker-supplied Brotli data through `node:zlib` |
| CVE-2026-105481 | Medium | 22, 24, 26 | A client accepts a response sent before its request | Reusing keep-alive connections through HTTP Agent |
| CVE-2026-106072 | Medium | 22, 24, 26 | Numeric DNS certificate names authenticate IP endpoints | TLS clients using non-canonical IPv4 spellings on accepting resolvers |
| CVE-2026-106074 | Medium | 22, 24, 26 | Snapshots preserve random caches across processes | Building startup snapshots or snapshot-enabled single executable applications after generating random values |
| CVE-2026-106070 | Low | 26 | Invalid ZIP headers lead to the wrong bytes being returned | Inspecting and reading affected archives with `zlib.ZipFile` |
| CVE-2026-106071 | Low | 26 | Wildcard filesystem permissions grant too much access | Particular wildcard grant configurations in the Permission Model |
| CVE-2026-106073 | Low | 22, 24, 26 | `fs.realpathSync()` misses permission checks | Restricting filesystem reads through the Permission Model |

### When does the Brotli issue expose a web application?

CVE-2026-111497 concerns decoding attacker-controlled Brotli data. Memory corruption can cause a crash, disclose process memory or potentially permit remote code execution. Inspect compressed inbound requests, uploaded data and external HTTP responses wherever they reach a Brotli decoder, directly or through a library.

Producing compressed responses and decoding untrusted compressed input are different paths. A framework name alone does not establish exploitability. Review middleware and HTTP client behavior to identify where decompression actually happens. [Brotli CVE record](https://www.cve.org/CVERecord?id=CVE-2026-111497)

### Why do outbound HTTPS and special runtime settings matter?

The three TLS issues concern how a client interprets an IP address and matches its certificate. Review outbound API calls and user-supplied destination URLs, rather than looking only at the application's public HTTPS listener. CVE-2026-106072 additionally requires a certificate with a numeric DNS SAN issued by a trusted CA and a resolver that accepts the unusual IP spelling.

The HTTP Agent issue also concerns the client side: reuse of an existing connection. It should not be described as a generic inbound HTTP server flaw. The snapshot issue needs a user-created startup snapshot, or a single executable built with `useSnapshot`, that contains populated random caches. Saving an ordinary application build or Docker image is not the same operation.

## How to check whether your application is affected

1. **Inventory actual runtimes.** Check development, servers, CI immediately after Node setup, and build containers. A local version does not tell you which binary production executes.
2. **Review version declarations.** Inspect `.nvmrc`, `.node-version`, `package.json` engines and Volta settings, CI runtime configuration, and every Dockerfile `FROM` instruction.
3. **Check managed platforms.** Inspect both build-time and server runtime settings in serverless or PaaS projects, then read the provider's patch information.
4. **Trace the relevant behavior.** Look for Brotli decoding, outbound HTTPS, HTTP Agent reuse, DNS resolution, startup snapshots and Permission Model settings.

These commands report the Node binary selected by the current shell, together with its dependency versions:

```bash
node -v
node -p 'JSON.stringify({node: process.version, executable: process.execPath, dependencies: process.versions}, null, 2)'
```

For a container, replace the placeholder with its actual name:

```bash
docker exec YOUR_CONTAINER node -v
```

A lockfile such as `package-lock.json` does not pin the Node.js executable. The `engines` field also does not replace an installed runtime automatically. A long-running service can still be using a different binary from a newly opened shell, so also record `process.version` from the deployed process at startup. [Node.js process documentation](https://nodejs.org/api/process.html#processversions)

## How to update Node.js with nvm, Volta or fnm

Use the tool already managing your environment. These examples stay on Node.js 24; substitute the fixed version for 22 or 26 when appropriate.

With nvm:

```bash
nvm install 24.22.1
nvm use 24.22.1
node -v
```

With Volta, update the project's pin as well:

```bash
volta install node@24.22.1
volta pin node@24.22.1
node -v
```

With fnm:

```bash
fnm install 24.22.1
fnm use 24.22.1
node -v
```

Update `.nvmrc` or `.node-version` according to your team's convention. Switching a developer shell is only one part of the change: align CI setup and service launch configuration too. The official [nvm](https://github.com/nvm-sh/nvm#usage), [Volta](https://docs.volta.sh/reference/pin) and [fnm](https://github.com/Schniz/fnm#usage) documentation describes those tools' version-selection behavior.

## Do Docker node images need a rebuild?

The official image lists `node:22.23.4`, `node:24.22.1` and `node:26.12.1`. For example, a Node.js 24 Debian slim base can use:

```dockerfile
FROM node:24.22.1-bookworm-slim
```

If your Dockerfile pins an older patch tag or digest, change that reference. If it uses a floating major tag such as `node:24`, an existing application image and running container still retain their old contents. Fetch the base again, rebuild the application image, and redeploy it. [Official image tags](https://hub.docker.com/_/node)

```bash
docker build --pull -t your-app:node24-security .
```

For multistage builds, inspect both build and runtime stages. A fixed build stage cannot compensate for an old runtime stage, and the build environment also needs the security fixes. After deploying the new image, check the version across every replica. Docker documents `--pull` as always attempting to pull all referenced images. [Docker build reference](https://docs.docker.com/reference/cli/docker/buildx/build/#pull)

## How to update distro packages and PaaS runtimes

For an operating system package, read the distributor's security notice and package changelog. A distributor may backport a fix without adopting the upstream patch version, so a numeric comparison alone may be misleading. Confirm the binary path as well: the service may be using a version-manager installation instead of the system package.

For PaaS and serverless deployments, check runtime selection and the provider's patch status, then perform any required redeployment. Build and runtime environments can be managed separately. Verify which Node version the deployed process starts after the change.

Run the project's normal build and tests, then check public pages, API routes, outbound HTTPS calls and features that handle compressed input. Keep the resulting runtime version with the deployment record so the next check starts from evidence rather than a configuration assumption.

The release also updates c-ares, Undici and CA certificates across 22, 24 and 26; OpenSSL on 22 and 24; and SQLite on 22. Review the [individual release notes](https://nodejs.org/en/blog/release/v24.22.1/) alongside the application checks.

## Does static output remove the need to patch Node.js?

Serving HTML, CSS and JavaScript as static files without Node.js in that delivery path reduces the paths by which public requests can reach Node processing. It does not update the CI runner, build machine, preview server, API or SSR service. Each remaining runtime needs its own owner and patch process.

A site that fetches content from a CMS such as [genko.me](https://genko.me/) during its build still depends on an updated build runtime. See the [Astro integration guide](https://docs.genko.me/en/frameworks/astro/getting-started) and [Astro CMS blog guide](https://blog.genko.me/en/astro-blog-cms) for the build-time pattern. The related [PHP2Shell and static site architecture article](https://blog.genko.me/en/php2shell-static-site-architecture) discusses separating the public delivery layer from other application services.

## FAQ

### Which Node.js versions are affected by the October 2026 vulnerabilities?

The announcement covers Node.js 22.x, 24.x and 26.x, with fixes in 22.23.4, 24.22.1 and 26.12.1. Individual issues differ: the fullwidth-IP TLS issue covers 24 and 26, while the ZIP and wildcard-permission issues cover 26.

### Do I need to update a Docker node image using a floating tag?

A floating tag does not replace an already built application image or a running container. Fetch the base again, rebuild and redeploy, then inspect the running version.

### Are Next.js applications affected?

Their Node-based builds and servers need to be checked. Actual exposure to an individual CVE depends on behavior such as decoding Brotli input or making outbound connections.

### Can npm update fix the Node.js runtime vulnerabilities?

Updating application dependencies does not replace Node.js itself. Update the runtime, then verify the dependency installation and application behavior on that runtime.

## Sources

- [Node.js October 2026 security announcement](https://nodejs.org/en/blog/vulnerability/october-2026-security-releases)
- [22.23.4](https://nodejs.org/en/blog/release/v22.23.4/), [24.22.1](https://nodejs.org/en/blog/release/v24.22.1/), [26.12.1](https://nodejs.org/en/blog/release/v26.12.1/)
- CVE records: [105482](https://www.cve.org/CVERecord?id=CVE-2026-105482), [105483](https://www.cve.org/CVERecord?id=CVE-2026-105483), [106069](https://www.cve.org/CVERecord?id=CVE-2026-106069), [111497](https://www.cve.org/CVERecord?id=CVE-2026-111497), [105481](https://www.cve.org/CVERecord?id=CVE-2026-105481), [106072](https://www.cve.org/CVERecord?id=CVE-2026-106072), [106074](https://www.cve.org/CVERecord?id=CVE-2026-106074), [106070](https://www.cve.org/CVERecord?id=CVE-2026-106070), [106071](https://www.cve.org/CVERecord?id=CVE-2026-106071), [106073](https://www.cve.org/CVERecord?id=CVE-2026-106073)
- [Docker official Node image](https://hub.docker.com/_/node), [nodejs/docker-node](https://github.com/nodejs/docker-node), [Docker build pull option](https://docs.docker.com/reference/cli/docker/buildx/build/#pull)
- [nvm](https://github.com/nvm-sh/nvm#usage), [Volta install](https://docs.volta.sh/reference/install), [Volta pin](https://docs.volta.sh/reference/pin), [fnm](https://github.com/Schniz/fnm#usage)
- [Node.js process](https://nodejs.org/api/process.html#processversions), [npm engines](https://docs.npmjs.com/cli/v11/configuring-npm/package-json#engines)