Node.js security releases on 11 November: what to do before they land

By Martin Mokoš, AYAsec · Published Nov 5, 2026

Key takeaways

• On 3 November 2026 the Node.js project announced security releases for its 26.x, 24.x and 22.x lines, due on or shortly after Wednesday 11 November. The highest severity among the fixed issues is HIGH. The notice does not name any issue yet.
• Do not wait for 11 November to fix the previous batch. The 21 October releases (22.23.4, 24.22.1 and 26.12.1) fixed ten issues, four of them rated HIGH. One of them, a flaw in the Brotli decoder (CVE-2026-111497), has been on CISA's list of exploited vulnerabilities since 27 October.
• Node.js 25.x, 20.x and older are past end of life. The project says end-of-life versions are always affected by a security release, and it prepares fixes only for supported releases.
• This week: find every place you run Node.js, check the version, and book the update for 11 and 12 November. After the release: update, rebuild container images, restart, verify.
• An external scan cannot tell you which Node.js version a server runs. That check happens on your own machines and images.

What happened

On 3 November the Node.js project published a pre-announcement: new versions of the 26.x, 24.x and 22.x release lines will ship "on or shortly after" Wednesday 11 November 2026. For each of the three lines the highest severity issue fixed is HIGH. The notice names no vulnerabilities. The project's security process puts the pre-announcement one week before the release, and the issue list, CVE numbers and download links come with the release itself.

It is the second batch in three weeks. On 21 October the project released 22.23.4, 24.22.1 and 26.12.1, fixing ten issues: four rated HIGH, three medium and three low. The four HIGH issues were:

• a remote code execution flaw in the Brotli decoder (CVE-2026-111497);
• two bypasses of the TLS certificate hostname check (CVE-2026-105483 and CVE-2026-106069);
• a flaw that makes dns.resolve cut off names that contain a NUL character (CVE-2026-105482).

The Brotli flaw is not specific to Node.js. NVD describes a buffer overflow in Google Brotli 1.0.3 through 1.2.0 that a remote, unauthenticated attacker can trigger with a crafted compressed stream, and lists scores of 9.8 (CVSS 3.1) and 9.2 (CVSS 4.0), both critical; the Node.js project rated its own instance HIGH. CISA added the flaw to its Known Exploited Vulnerabilities catalog on 27 October and gave US federal agencies until 10 November to fix it. The catalog entry does not say which products attackers went after, so it does not tell us whether Node.js servers were among them. Anything else that bundles Brotli 1.0.3 through 1.2.0 is affected too; NVD names 1.0.10, 1.1.1 and 1.2.1 as the fixed versions.

Which versions are affected?

End-of-life versions get no fix, but the notice says they are always affected when a security release happens. If you cannot move yet, the Node.js site points to commercial support for versions past the maintenance phase through partners of the OpenJS Ecosystem Sustainability Program.

Are you affected?

Node.js hides in more places than most inventories list. Check four:

1. Servers and virtual machines. Node.js may have come from a package, nvm, a tarball or a supplier's installer. node --version shows the version; run it on every host, not only the ones you remember.
2. Container images. Search Dockerfiles for FROM node: and for images that bundle Node.js. An image keeps the version it was built with, so updating the host changes nothing inside it. To read the version inside an image, run docker run --rm --entrypoint node IMAGE --version.
3. Build machines and developer laptops. CI runners (the node-version setting in a GitHub Actions workflow, for example), .nvmrc files and the engines field in package.json. They usually face less untrusted input than a web server, but they are on the list.
4. Products from suppliers and hosting platforms. Many commercial products and managed platforms run Node.js, and you cannot patch those yourself. Ask the supplier which Node.js version the product runs and when the fix ships. Desktop apps built on Electron bring their own Node.js and are fixed only when the app itself is updated.

October's HIGH issues sat in three places: decompression of data that comes from outside, TLS certificate checks when Node.js calls other servers, and DNS lookups of names that came from outside. Services that do those things come first.

What to do before 11 November

1. Make an inventory. List every place Node.js runs: hosts, images, build machines, supplier products. Write down the version and who owns each.
2. Update to the October builds now. 26.12.1, 24.22.1 or 22.23.4, or newer. This closes the Brotli flaw that CISA lists as exploited and nine other issues that are already public.
3. Plan the move off end-of-life lines. 25.x, 20.x and older get no fixes. Pick 22.x, 24.x or 26.x and put a date on it.
4. Book 11 and 12 November. The release is "on or shortly after" the 11th, so keep the next day free. Decide who updates what, internet-facing services first.
5. Follow the source. Subscribe to the low-volume nodejs-sec mailing list and watch the Node.js blog post. On release day the project sends the advisory to the list and, according to its security policy, publishes it on the blog within six hours.

What to do on the day

1. Read the advisory and match each issue to what you run.
2. Update, internet-facing services first. Pin the exact version in your Dockerfiles and rebuild the images instead of patching inside them.
3. Restart. A running Node.js process keeps using the version it started with until it is restarted.
4. Verify with node --version (or the docker run command above) and keep a record of what was updated, to which version, and when.

Do you have to report anything?

A vulnerability on its own is not an incident. If you find signs that someone used one against you, the clocks start. Under NIS2 (Article 23), an essential or important entity that becomes aware of a significant incident sends an early warning within 24 hours, an incident notification within 72 hours and a final report within one month of that notification. Under the GDPR (Article 33), a personal data breach is reported to the supervisory authority within 72 hours of becoming aware of it, unless it is unlikely to result in a risk to people. Which authority you notify depends on your country.

How worried should you be?

Worried enough to apply October's fixes this week and to keep 11 November free; not enough to panic.

Confirmed: the Node.js project says the worst issue in each of the three supported lines is HIGH, and the release is due on or shortly after 11 November. October's batch is public, includes four HIGH issues, and one of them is on CISA's exploited list. Not confirmed: what the 11 November issues are, whether they can be triggered remotely, and whether anyone is exploiting them. The notice does not mention exploitation. HIGH is the Node.js project's own rating of the worst issue, not a score we calculated.

A note on who is telling you this: we sell an external scanner. It cannot patch Node.js, and it cannot see which version a server runs.

What an external scan can tell you

From the internet, Node.js does not show its version. On 5 November 2026 we ran a minimal HTTP server in a current Node.js 22 container: the response headers carried a date and connection details, but no Server header and no version.

Express, a widely used framework on top of Node.js, sends an X-Powered-By: Express header by default, according to its documentation. That names the framework, not the Node.js version. The free HTTP checker lists the technologies a site reveals in its headers and cookies, and switching such headers off is cheap, but it does not tell you whether a server is on the October builds. The TLS and DNS flaws from October are about what your Node.js clients accept when they connect out, which an outside scan cannot see either.

So the check is internal: version commands, an image inventory, your supplier's answer.

See which technologies your site reveals with the free HTTP checker

Sources

• Node.js: Wednesday, November 11, 2026 Security Releases (3 November 2026) and Wednesday, October 21, 2026 Security Releases (21 October 2026)
• Node.js: release schedule, security policy and security release process
• CISA: Known Exploited Vulnerabilities Catalog (CVE-2026-111497, added 27 October 2026)
• NVD: CVE-2026-111497
• Express: Production best practices: security
• EUR-Lex: NIS2 directive, Article 23 and GDPR, Article 33