Node.js October 2026 Security Releases: What Changed and Who Needs to Upgrade

On 21 October 2026 the Node.js project shipped security releases for all three supported release lines: v22.23.4, v24.22.1, and v26.12.1. Together they fix ten vulnerabilities, four rated high, three medium, and three low. Most of them affect specific features, but one, a memory corruption bug in the Brotli decoder, can reach ordinary web applications that never call zlib directly. If you run anything on Node.js, including Next.js, NestJS, or Express, plan the upgrade for this week.

Which Version to Install

Each supported line has its own fixed release. Upgrading within your current line is enough; there is no need to jump to a new major version to get the fixes.

The Node.js project states that end-of-life versions are always affected when a security release goes out. Node.js 20 reached end of life in April 2026, so servers still running it will not receive these fixes and should move to 22 or, preferably, 24.

The Brotli Bug That Can Lead to Remote Code Execution

The most serious issue is CVE-2026-111497, found in the Brotli decompressor in node:zlib. When the decoder met a particular kind of invalid input, it treated the problem as a temporary need for more data instead of a format error. It kept appending input to an eight-byte internal buffer and wrote past the end of it. An application that decompresses Brotli data from an untrusted source can therefore have its process memory corrupted, which can end in a crash, a memory leak to the attacker, or remote code execution. All three supported lines are affected.

Few applications call the Brotli decoder by hand, but plenty use it indirectly. The built-in fetch automatically decompresses responses sent with Brotli encoding, so a feature that fetches a URL supplied by a user, such as a link preview, a webhook tester, or an import from an external address, decompresses data chosen by whoever controls that server. Upload handlers and proxies that unpack compressed request bodies fall into the same category. If your application does any of this, treat the upgrade as urgent.

Hostname and Certificate Checks

Three of the four high-severity issues concern how Node.js matches hostnames, and two of them are gaps left by earlier fixes. They matter most for code that validates a hostname before connecting to it, such as protection against server-side request forgery, and for services that talk to each other over TLS using IP addresses.

• CVE-2026-105482 (high): dns.resolve*() and dns.reverse() cut a hostname off at a NUL byte. Resolving attacker.example followed by a NUL byte and .trusted.example quietly returns the records of attacker.example. An allowlist that checks the full name and then resolves it can end up acting on a different host. An earlier fix covered only dns.lookup() and the net and tls host options.
• CVE-2026-105483 (high, 24.x and 26.x): tls.checkServerIdentity() did not recognise an IP address written with fullwidth digits, and matched it against certificate DNS names instead. A certificate issued for the DNS name 127.0.0.1 could be accepted for an IP endpoint it was never issued for.
• CVE-2026-106069 (high): for an IPv4 address with a leading zero such as 0127.0.0.1, the certificate check read the octet as octal while the operating system resolver on some platforms, including macOS, read it as decimal. The connection and the certificate check could disagree about which address was being verified.
• CVE-2026-106072 (medium): other non-canonical IPv4 spellings, such as 0x7f.0.0.1 or 2130706433, were also matched against DNS names rather than treated as IP addresses. Exploiting it requires a numeric DNS name in a certificate from a trusted CA and a resolver that accepts these spellings, such as glibc.

Beyond upgrading, the lesson for application code is to normalise a hostname once, reject anything that contains control characters, and pass the same normalised value to both the validation step and the connection. Checking one string and connecting to another is how most of these bypasses work.

Issues with a Narrower Reach

The remaining issues only apply when an application uses a particular feature. They are worth reading through, because if one of them does match your setup, its impact can be larger than the severity suggests.

The snapshot issue deserves a second look from teams that package Node.js tools as single executables. Two processes that hand out the same UUIDs can collide in a database, and anyone who can observe the output of one process can predict the next values of another.

Bundled Dependencies Were Updated Too

The releases also update several libraries that ship inside Node.js: c-ares and undici on all three lines, OpenSSL on 22.x and 24.x, and SQLite on 22.x. The bundled root certificate store was updated as well, in response to the compromise of an eMudhra intermediate certificate authority. Applications that rely on the default certificate store pick up that change only by upgrading the Node.js binary.

How to Upgrade

Node.js reaches production in several ways, and each one is upgraded differently.

• Servers with nvm or a similar version manager: install the fixed version, for example nvm install 24.22.1, switch the service to it, and restart. Make sure systemd units or PM2 point to the new binary rather than a path tied to the old version.
• Packages from NodeSource or a Linux distribution: run the usual package update and confirm the version with node -v. Distribution packages may keep an older version number while carrying the fix, so check the security notice for the CVE numbers.
• Docker: rebuild every image from the updated official base, for example node:24-alpine or node:24-bookworm-slim, and redeploy. Images pinned to an exact older tag will not change on their own.
• Managed runtimes such as AWS Lambda or Vercel: the provider usually updates the runtime for supported major versions, but check that the major version you selected is still supported, and redeploy if the platform requires it. Platforms that run your own container image, such as Cloud Run or ECS, follow the Docker route above.
• Developer machines and CI runners: update them too, since build steps and tests also run Node.js and may fetch or unpack external data.

1. 1List every service that runs Node.js, including API servers, Next.js front ends, background workers, and internal tools.
2. 2Upgrade each one to the fixed version of its release line, rebuild container images, and redeploy.
3. 3Restart long-running processes. A Node.js process keeps running the old binary until it is restarted.
4. 4Check the version that is actually running, for example by logging process.version at startup or exposing it on an internal health endpoint.
5. 5Plan the move to Node.js 22 or 24 for any service still on 20 or older.

Keeping Up Without Scrambling

Node.js publishes security releases several times a year, usually with a few days of notice. Teams that handle them calmly tend to have the same habits: one place that records which Node.js version each service runs, base images that are rebuilt on a schedule, and a deployment pipeline that can ship a runtime upgrade without waiting for a feature release. Subscribing to the nodejs-sec announcement list is the simplest way to hear about the next one early. If you would like help reviewing or upgrading your Node.js services, our managed service team can take it on.