Wednesday 21 October 2026 was quite a day for the internet’s plumbing. Hours after PHP rushed out emergency patches for the PHP2Shell flaws, the Node.js project published its own scheduled security releases — fixing ten vulnerabilities in the software that powers millions of websites, apps and online services. The most serious of them, hidden inside a compression library bundled with Node.js, can potentially let an attacker run their own code on a server.
If your business runs a modern website, a web app, an online shop with a separate app, or any service built in the last few years, there is a real chance Node.js is running somewhere in your stack — often without you ever having heard its name. Here is what happened, which versions are affected, and exactly what to do about it, in plain English.
First, what is Node.js — and why should you care?
Node.js is the technology that lets developers run JavaScript — the language of web browsers — on servers. Since its release it has become one of the most popular ways to build the “back end” of websites and apps: the part that handles logins, orders, payments, messages and data. Around 7.4% of all websites with an identified server technology run on it, and the names behind it are not small: Netflix, PayPal, Walmart, LinkedIn, Uber and NASA all use Node.js somewhere in their systems. Millions of smaller businesses do too — frequently through the agency or developer who built their site or app, which is why so many owners have Node.js running without ever having chosen it themselves.
The headline flaw: a bug in Brotli that can open the door to your server
The most serious issue, tracked as CVE-2026-111497, is an out-of-bounds write in the Brotli decoder bundled inside Node.js. Brotli is a compression library created by Google — it shrinks data so it travels faster, and Node.js uses it inside its compression (zlib) features.
In plain terms: if an application decompresses Brotli data that an attacker controls — for example a crafted request body, an uploaded file, or a response the app fetches from another server — the malformed data can corrupt the program’s memory. The Node.js project states plainly that this “permits remote code execution”: the most serious class of bug there is, where an outsider gets to run their own instructions on your server.
Two honest clarifications, because headlines rarely include them. First, Node.js rates this flaw High severity (Node.js does not publish CVSS scores itself; the underlying Brotli CVE record is scored 9.2 out of 10, and some security scanners flag it as high as 9.8). Second, the bug only bites when an app actually decompresses attacker-controlled Brotli data — Node.js does not decode Brotli on its own. That narrows the risk, but “narrower” is not “none”: plenty of real applications decompress uploaded or fetched data every day. The flaw was reported by security researchers at OpenAI’s Codex Security team.
The other nine flaws, briefly
Alongside the Brotli bug, the October releases fixed nine further issues — four rated High in total, three Medium and three Low:
| Flaw | Severity | What it means in plain English |
|---|---|---|
| DNS name truncation (CVE-2026-105482) | High | Names containing a hidden null character get cut short during DNS lookups, which can slip hostile names past safety checks. |
| TLS certificate bypass — fullwidth digits (CVE-2026-105483) | High | An IP address written in exotic fullwidth digits could fool the certificate hostname check, so a fake endpoint could pass as genuine. (24.x / 26.x only.) |
| TLS certificate bypass — loose IP match (CVE-2026-106069) | High | A second way of writing an IP address non-standardly could bypass the same certificate check. |
| Keep-alive response mix-up (CVE-2026-105481) | Medium | On a persistent connection, a response written before a request was sent could be processed as that request’s answer — a response-smuggling risk. |
| Certificate validation for odd IPv4 forms (CVE-2026-106072) | Medium | Certificates meant for domain names could wrongly authenticate IP endpoints written in non-standard forms. |
| “Random” values repeated (CVE-2026-106074) | Medium | The caches behind random ID generators could be baked into app snapshots, so every copy of an app produces the same “random” values — undermining anything that relies on them being unpredictable. |
| ZIP + Permission Model issues (CVE-2026-106070 / 106071 / 106073) | Low | Three smaller flaws: a ZIP reader returning attacker-controlled bytes, and two ways to escape Node’s file-permission model. Mostly affect the 26.x line. |
The same releases also quietly updated several built-in components and blocked eight compromised certificate-authority keys (from eMudhra) — the same keys the major browsers blocked earlier in October. It was, in other words, a thorough spring-clean of the platform’s security.
Is your version affected? The only table you need
| Your Node.js version | Status | What you must do |
|---|---|---|
| 26.x (before 26.12.1) | Vulnerable | Update to Node.js 26.12.1 |
| 24.x LTS (before 24.22.1) | Vulnerable | Update to Node.js 24.22.1 |
| 22.x LTS (before 22.23.4) | Vulnerable | Update to Node.js 22.23.4 |
| 20.x, 18.x or older | Vulnerable — no patch exists | Upgrade to a supported line (24.x LTS recommended) |
| 22.23.4 / 24.22.1 / 26.12.1 or higher | Patched | No action needed for these flaws |
Notice the fourth row — it is the same trap we flagged in the PHP2Shell story a day earlier. Versions 20.x and older are end-of-life: they are affected by these flaws, but no fix will ever be published for them. If your app still runs on Node 20 (and a great many do), patching is not an option — a proper upgrade is the only route to safety, and every future security release will pass you by until you take it.
Are attacks already happening?
Here the honest answer is reassuring — so far. As of 22 October, no exploitation in the wild has been reported for any of these ten flaws. A public proof-of-concept for the Brotli bug managed to crash a standard Node.js build and read a limited amount of memory, but achieved full code execution only against a deliberately weakened test build. That is a meaningful gap between “theoretically critical” and “attackers are using this today”.
Contrast that with PHP2Shell, where millions of exploit attempts were seen within a day. The practical difference: PHP was an emergency; Node.js is urgent maintenance. You do not need to panic, take anything offline, or wake anyone up at 3 a.m. — but you do need the update on your list this week, not this quarter. Attackers read the same advisories, and the gap between “proof-of-concept crashes it” and “working exploit” tends to close quietly.
How to check whether you even use Node.js
This is the question most business owners will be stuck on, because Node.js rarely announces itself. Places it commonly hides:
- Your website’s back end or API — especially sites built in the last five years, “headless” sites, and anything built with frameworks like Next.js or Nuxt.
- Your mobile app’s back end — the server your app talks to is very often Node.js.
- Desktop apps — many are built on Electron, which bundles Node.js; those need their own updates from their makers.
- Internal tools and dashboards — the little systems businesses forget they own.
If a developer or IT person manages your systems, one command answers the version question on any server: node --version. If nobody can tell you whether Node.js is in your stack at all, that uncertainty is itself the finding — and exactly the kind of thing an audit is for.
The five steps that protect you
Step 1 — Find every Node.js installation you rely on. Production servers, staging copies, containers, the app back end, the forgotten internal tool. If it runs Node, it counts.
Step 2 — Update to the fixed release for your line. 22.23.4, 24.22.1 or 26.12.1 (or higher). On 20.x or older, plan a line upgrade instead — there is no patch coming.
Step 3 — Rebuild and restart. Container images must be rebuilt with the new Node version, and services restarted, so the patched code is the code actually running. An update sitting on disk protects nobody.
Step 4 — Remember the bundled-copy rule. Node.js ships its own Brotli and other components. Updating your server’s system packages does not touch them — only the Node.js update counts.
Step 5 — Retest the sensitive paths. After updating, sanity-check the things these flaws touched: logins and certificates (TLS), any file-upload or decompression features, and your app’s permission boundaries. Then take a clean backup.
One strange week for the whole web
It is worth pausing on the coincidence: the two most-used server platforms on earth — PHP and Node.js — shipped serious security fixes on the same day, found by different researchers (Wiz for the PHP flaws; OpenAI’s Codex Security team for the Node.js headline bug), in code that shares nothing but history. There is no grand conspiracy in it — just a reminder that the software underneath your website is itself software, maintained by humans, carrying old bugs in old corners. The businesses that sail through weeks like this are not the ones with the fanciest websites. They are the ones where somebody is watching the foundations.
Frequently asked questions
My website is WordPress. Does this affect me?
WordPress itself runs on PHP, not Node.js — the PHP2Shell update is the one that matters for a standard WordPress site. But if your setup includes a separate app, a headless front end, or a custom API, Node.js may still be in your stack. Both checks are worth doing.
Should I take my app offline until we update?
No. With no reported exploitation and a fix already available, the sensible move is a prompt, planned update — not downtime.
We are on Node.js 20. Can we just apply a patch?
There isn’t one. Version 20 is end-of-life and receives no security fixes. Upgrading to a supported line (we recommend the 24.x LTS) is unavoidable maintenance — and it closes not just these ten holes, but every future one too.
Does updating our server’s system packages fix the Brotli bug?
No. Node.js bundles its own copy of Brotli. Only updating Node.js itself replaces the vulnerable code.
How do I know if we have already been attacked?
There is no public evidence of these flaws being exploited yet, which makes quiet compromise unlikely. The usual warning signs still apply — unexplained crashes in anything that decompresses data, unknown processes, changed files. If you see them, get the system inspected before anything else.
The bottom line
Ten flaws, one genuinely nasty one, zero attacks reported so far, and a fix that takes most teams less than a day to apply. That is the whole story — and it is a good-news story, provided the update actually happens. The pattern of October 2026 is now unmistakable: PHP, then Node.js, each with end-of-life versions abandoned to their fate. Whatever your website or app is built on, someone needs to own its updates.
Not sure whether Node.js runs anywhere in your business — or which version it is on? That is precisely the kind of thing we check for our clients every week. Get in touch with Altus Web Solutions for a free website audit — we will map what your site and apps actually run on, flag anything end-of-life or unpatched, and tell you plainly what needs doing. No jargon, no scare tactics.
