Node.js: the October 2026 security updates and what to do with your applications

Node.js fixed ten vulnerabilities, one allowing remote code execution. Which version to install, what to check in production and what to do with Node 16, 18 or 20.

On 21 October 2026, the Node.js project published security updates for every supported release line: v22.23.4, v24.22.1 and v26.12.1. They fix ten vulnerabilities, four of them high severity. The most serious, CVE-2026-111497, is an out-of-bounds write in the Brotli decoder, which the official announcement describes as permitting remote code execution. It was reported by the OpenAI Codex Security team.

If your company runs a web application, an API, an admin panel or an internal service written in JavaScript or TypeScript on the server, it almost certainly runs on Node.js. This article is for the manager of that application and the team that maintains it: what was fixed, what to check, which traps appear during the update, and what to do if the application is on an old version.

The official list has ten CVEs. In short, the ones that matter for most applications:

• CVE-2026-111497 (high severity): a flaw in the Brotli decoder, the compression format used on the web, which can allow remote code execution. It affects the 22, 24 and 26 lines.
• CVE-2026-105483 and CVE-2026-106069 (high severity): two ways to bypass the hostname check in a TLS certificate, tied to how IP addresses are written or interpreted. The certificate check is what guarantees your application is talking to the right server rather than an impostor.
• CVE-2026-105482 (high severity): DNS resolution truncates names that contain a null character.
• Medium and low issues: a problem with keep-alive connections, certificate validation for unusually written IPv4 addresses, the random identifier generator repeating values in startup snapshots and in applications packaged as a single executable (SEA), plus a few issues in the permission model and in reading ZIP archives.

The components bundled with Node.js were also updated: c-ares, OpenSSL, SQLite, Undici (the HTTP client behind fetch) and the list of certificate authorities. The last one was updated after the compromise of the eMudhra certificate authority in the same week.

One important point: the official announcement does not detail which functions or configurations expose the Brotli flaw. Until you know for certain that your application is not affected, treat any application on the 22, 24 or 26 lines as affected and update it.

• line 22: v22.23.4 or newer;
• line 24: v24.22.1 or newer;
• line 26: v26.12.1 or newer.

Node.js recommends, in this order:

1. updating to the fixed version of the line you use;
2. prioritising the Brotli flaw and the TLS bypasses;
3. rebuilding startup snapshots and SEA applications after the update, otherwise they keep the repeated values from CVE-2026-106074;
4. moving applications off versions that are out of support.

• The version actually running in production. Not the one in package.json, and not the one on a developer's laptop. Running node -v inside the production container or server is the only reliable answer.
• The base image, if you use Docker. The Node.js version comes from the image your application is built on. If that image is not rebuilt, the application stays on the old version.
• Managed platforms. On a serverless or PaaS service the provider updates the runtime, but sometimes you have to choose the version yourself or redeploy. Check in their console which version your function or application uses and what they have announced since 21 October.
• Dependencies. If your application installs Undici separately as a package, update it too. The version bundled with Node.js does not replace the one in node_modules.
• After the update: rebuild, deploy, run smoke tests on the important flows (login, payments, forms, integrations) and check the error logs.

Many projects build their image from a moving tag such as node 22 alpine. It looks as if it always brings the latest release of line 22, but that is not guaranteed: the build machine or server may hold an older copy of that image in its cache, and the build uses it without downloading it again. The result is an image built today, after the patch, that still runs the vulnerable version.

The fix is simple. Pin the version explicitly in the build file, for example node 22.23.4 alpine instead of node 22 alpine. Then check with node -v inside the running container, not just the build container. When the next security update arrives, the change to the pinned version is visible and easy to track.

Line 18 went out of support on 30 April 2025 and line 20 on 30 April 2026. They do not receive the October fixes. The Node.js project states that versions out of support should be considered affected by every security release.

Your options, in short:

• Porting to line 22 or 24. Line 22 is supported until 30 April 2027 and line 24 until 30 April 2028. Line 26 becomes LTS on 28 October 2026 and is supported until 30 April 2029. For new applications or a large port, 24 or 26 give more time before the next move.
• What porting means in practice: updated dependencies (some may be abandoned and need replacing), functions removed or changed between versions, native modules rebuilt and, above all, tests. Without automated tests, the port has to be done more slowly and carefully, on a copy of the application.
• A temporary bridge. For versions out of support, the Node.js project points to commercial partners in the OpenJS programme. Meanwhile, the application can be isolated: reachable only from the internal network or over a VPN, behind a filter. It is not a final solution, only time bought for the migration.

1. Find out which Node.js version actually runs in production.
2. Update to v22.23.4, v24.22.1 or v26.12.1.
3. Pin the version in the base image and rebuild every image.
4. Rebuild startup snapshots and SEA applications, if you use them.
5. Update dependencies, including a separately installed Undici, then test the important flows.
6. For applications on 16, 18 or 20, plan the port and isolate them until then.

At ME Digital we run applications on Node.js ourselves and updated them in the same week. We do the same for clients: we check the real version in production, update and rebuild the images, and port applications still on old versions, as part of our security and updates services. If you would like us to look at your application, get in touch.

• Node.js, security releases of 21 October 2026
• Node.js, release support schedule (schedule.json)
• Node.js, previous releases and commercial support for end-of-life versions
• Mozilla, compromise of the eMudhra intermediate certificates