Node.js Vulnerability: What to Do About 4 High-Severity Flaws
On October 21, 2026, Node.js fixed 10 vulnerabilities; 4 are high severity and one allows remote code execution. Here is which version you need to move to.
Contents 10
The Node.js vulnerability news broke with the security update published on October 21, 2026. The Node.js team released versions 22.23.4, 24.22.1 and 26.12.1 and fixed a total of 10 vulnerabilities. Four of them are high severity; the most serious is a remote code execution flaw in the Brotli decoder. The fix is short: check your version, update, and restart your processes.
In short:
- On October 21, 2026, Node.js 22.23.4, 24.22.1 and 26.12.1 were released; 10 vulnerabilities were fixed.
- The most critical flaw is CVE-2026-111497: an out-of-bounds write in the Brotli decoder that allows remote code execution.
- Two flaws bypass TLS hostname verification, and one affects dns.resolve.
- End-of-life versions such as Node.js 20 and 18 do not receive patches.
What is in the Node.js security update?
The official announcement is dated October 21, 2026. According to the Node.js security announcement, new versions were released for the three active release lines. The update does not only fix Node.js's own code. It also includes updates for dependencies such as c-ares, OpenSSL, SQLite and Undici. An update related to the eMudhra certificate compromise is bundled in the release as well.
You may see different numbers such as "7 vulnerabilities" or "8 vulnerabilities" in news coverage. This inconsistency is natural, because secondary outlets count the vulnerabilities differently. The official announcement mentions 10 vulnerabilities, and this post goes by that figure.
What are the four high-severity vulnerabilities?
The table below summarizes the four vulnerabilities:
| CVE | Subject | Affected line |
|---|---|---|
| CVE-2026-111497 | Out-of-bounds write in the Brotli decoder, remote code execution | Versions covered by the patch |
| CVE-2026-105482 | dns.resolve truncates names containing NUL characters | 22, 24 and 26 |
| CVE-2026-105483 | TLS hostname verification bypassed for IPs written with full-width digits | 26 and 24 |
| CVE-2026-106069 | TLS hostname verification bypassed with a loosely parsed Host | 26, 24 and 22 |
The Brotli flaw is the most serious. The other three are mostly about weaknesses in verification logic. Still, flaws that weaken TLS verification are dangerous for any application that relies on the assumption of a secure connection.
How does the Brotli flaw affect your application?
CVE-2026-111497 is an out-of-bounds write bug in the Brotli decoder. This bug can lead to remote code execution. It is also reported to be triggerable through fetch(). According to posts by security researchers, it is enough for a malicious server to return a Content-Encoding: br response.
This means the risk is not only on the server side. If your application sends requests to an external address with fetch(), and that address is compromised or malicious, you are at risk. Services that connect to third-party APIs, web scraping jobs and webhook verifications should be especially careful.
Why do the TLS hostname flaws matter?
TLS hostname verification guarantees that the server you are connecting to is really the server you expect. CVE-2026-105483 and CVE-2026-106069 bypass this check under certain conditions. The first stems from an IP address being written with full-width digits, the second from the Host value being loosely resolved to an IP address.
If the check is bypassed, an attacker sitting in the middle can read or modify traffic using a forged certificate. Internal communication between microservices, payment provider integrations and connections made over IP addresses are sensitive in this respect. Check the table above to see which flaw applies to which version; the 22 line is affected only by CVE-2026-106069 and CVE-2026-105482.
Which version am I on, and am I affected?
Run the following in a terminal:
node -v
If the output starts with v22, v24 or v26, you are within the scope of the patch. The target versions are 22.23.4, 24.22.1 and 26.12.1. If your version number is lower than these, you need to update. If you use Docker, also check the Node version inside the image separately; the version on the server and the one in the container may not be the same.
What should you do if you use Node.js 20 or 18?
End-of-life versions do not receive these patches. According to the release schedule, as of October 2026 Node.js 22 is in maintenance mode and is supported until April 30, 2027. Node.js 26 becomes LTS on October 28, 2026.
A practical recommendation:
- If you run Node.js 20 or 18, plan a migration to a supported line.
- If you cannot migrate immediately, restrict services that connect outward with
fetch(). - For new projects, prefer the 24 line or the 26 line, which is about to enter LTS.
Staying on an old version gives you the comfort of "it works, let's not touch it", but it accumulates vulnerabilities with every new security announcement. We covered a similar situation in our post on the critical GitLab vulnerability.
Do you need to restart after updating?
Yes. Even if you install the new version, running processes continue with the old code. You need to restart your application after the update. If you use PM2, systemd or containers, restart the relevant service or redeploy the image. Without a restart, the patch has no effect.
The recommended order is:
- Note the current version with
node -v. - Update to the target version (22.23.4, 24.22.1 or 26.12.1).
- Rebuild your dependencies and images.
- Restart the services.
- Confirm with
node -vthat the new version is running.
Frequently asked questions
Is only the server side exposed to the Brotli flaw?
No. Because the flaw can be triggered through fetch(), client-side usage is also risky. If your Node.js application connects to a malicious server and receives a Content-Encoding: br response, the flaw can be triggered.
How many vulnerabilities were fixed in this update?
According to the official announcement, a total of 10 vulnerabilities were fixed, 4 of them high severity. Some secondary sources may give different numbers; going by the official announcement is the safest.
Will there be a patch for Node.js 20?
End-of-life versions do not receive these patches. You need to move to a supported version.
I updated but am I still at risk?
Yes, if you have not restarted your processes. The old process keeps running with the old code; a restart is mandatory.
Conclusion
This update should be treated as urgent. Find out your version with node -v, move to 22.23.4, 24.22.1 or 26.12.1, and restart your services. If you are on end-of-life versions, it is time to plan a migration. If you would like help with updating an existing Node.js application, a version migration or a security audit, the EngerekTech team can assist. To keep up with similar security updates, you can also check out our post on the PHP vulnerability.
Sources
