Node.js October 21 Security Release: What to Do About the Brotli RCE and TLS Validation Flaws
On 21 October 2026 the Node.js project released versions fixing 10 security flaws, four of them high severity. A remote code execution in the Brotli decoder and two TLS hostname-validation bypasses stand out. We explain which versions are safe and what you should ask.
In brief: On 21 October 2026 the Node.js project released security versions for the 26.x, 24.x and 22.x lines: v26.12.1, v24.22.1 (LTS) and v22.23.4. A total of 10 flaws were fixed: 4 high, 3 medium, 3 low severity. The most serious is CVE-2026-111497, a memory overflow in the Brotli decoder that can allow remote code execution. Two high-severity TLS hostname-validation bypasses were also fixed. If you have an application running Node.js on the server side (an API, a Next.js server, a back end), ask your software team in writing for the Node.js version and whether the patch has been applied. This article relies on Node.js's official announcement (23 October 2026).
Last updated: 23 October 2026
Which versions were fixed?
| Line | Fixed version | Highest severity |
|---|---|---|
| 26.x | v26.12.1 | High |
| 24.x | v24.22.1 (LTS) | High |
| 22.x | v22.23.4 | High |
The announcement covers only these three lines. In its official wording, end-of-life (EOL) versions are always affected by security releases and receive no fixes; if you are on those lines you need to move to a supported version. (Secondary sources say Node.js 20 reached end of life in April 2026; verify your own version's support status in the Node.js release schedule.)
The flaws that stand out
| CVE | Severity | Summary |
|---|---|---|
| CVE-2026-111497 | High | Out-of-bounds write in the Brotli decoder; can allow remote code execution. Affects the 26, 24 and 22 lines |
| CVE-2026-105482 | High | dns.resolve truncates names containing a NUL character |
| CVE-2026-105483 | High | TLS hostname validation can be bypassed when an IP address is written with fullwidth digits (26 and 24) |
| CVE-2026-106069 | High | TLS hostname validation can be bypassed when a hostname loosely resolves to an IP |
| CVE-2026-105481 | Medium | Keep-alive sockets can process a response written before the request was sent |
| CVE-2026-106072 | Medium | Non-canonical IPv4 names cause DNS SANs to authenticate IP endpoints (improper certificate validation) |
| CVE-2026-106074 | Medium | crypto.randomUUID() and randomInt() entropy caches saved into startup snapshots can make processes produce the same values |
| CVE-2026-106070/106071/106073 | Low | ZIP header validation, Permission Model filesystem permissions |
The update also refreshes bundled components such as c-ares, the CA certificate store (related to the eMudhra intermediate CA), OpenSSL, SQLite and Undici.
What do these flaws mean for your business?
The Brotli flaw
Brotli is a common compression format used by web servers and clients. A bug in the decoder can lead to code execution when maliciously crafted compressed data is processed. Because this flaw affects all three supported lines, it should be treated as the top-priority item. Your software team should assess whether your application processes externally supplied compressed data inside Node.js.
The TLS hostname-validation flaws
These flaws can let you be fooled by a fake certificate while you believe you are connecting securely to a server. Services that connect by IP address and rely on hostname checks are especially affected (for example internal service-to-service connections and some payment/ERP integrations). Keeping the Node.js version current matters for sensitive integrations such as payments, identity and ERP. For integration security, see our system integration guide.
Docker and compiled applications
Updating Node.js on the server alone may not be enough: Docker images and single-executable (SEA) applications carry their own Node.js version and must be rebuilt. The announcement also notes that the randomUUID() flaw affects startup snapshots and SEAs.
What to ask your software team
- Which Node.js version are our servers/containers on? Which line (22, 24, 26 or older)?
- Have we moved to v22.23.4 / v24.22.1 / v26.12.1? When?
- Have the Docker images been rebuilt and deployed?
- How do you track that Node.js stays on a supported line?
- Were critical flows (payments, login, integrations) tested after the upgrade?
- Is there a time commitment in the maintenance contract for urgent security patches? (Our maintenance and SLA guide)
The pattern of the week: three separate patches in the same days
This week, urgent patches came out at the same time across different technologies: PHP (21 October, PHP2Shell), Node.js (21 October) and Next.js (14 October, details). The takeaway: security updates are no longer a “once-a-year maintenance” job but a continuous process. That calls for:
- A current inventory of all the runtimes you use (PHP, Node.js, Python etc.),
- A policy of staying on supported versions,
- A defined time and owner for urgent patches,
- Automated tests after upgrades.
For general measures see our web application security guide.
Maintenance and security with Aktaş Digital
In Node.js and Next.js based projects, version tracking, security updates and post-upgrade testing are core parts of the maintenance plan. If you would like your current application's runtime and dependency status reviewed, or a scope and cost breakdown for a new project, you can use our quote form. Related services: web applications.
Frequently Asked Questions
We use Node.js 20; what should we do?
The official announcement covers only the 22.x, 24.x and 26.x lines; end-of-life versions get no fixes. Plan a move to a supported line (e.g. 24 LTS).
We updated Node.js on the server; are our Docker images current too?
No, not automatically. Docker images carry their own Node.js version; the image must be rebuilt and redeployed.
Does the Brotli flaw affect my site directly?
The impact depends on whether your application decodes Brotli-compressed data in Node.js and where that data comes from. Your software team should assess which components are affected; the safest route is to move to the fixed version.
Is there a workaround?
None was stated in the sources we used; the recommendation is to move to the fixed version.
Conclusion
Node.js's 21 October release closes four high-severity flaws, including a remote code execution and two TLS validation bypasses. The first thing you can do today: find out which Node.js version runs on your servers and in your Docker images, and request the move to a fixed version in writing.
