Node.js Vulnerabilities in 2026: Every CVE, the npm Worms and What to Patch

Node.js has shipped five security releases in 2026: in January, March, June, July and October. Between them they fix around 50 vulnerabilities in Node.js core. The latest, on 21 October, fixes a decoder bug that the project's own advisory says can lead to remote code execution.

That was not the hardest part of the year for Node.js teams, though. Over the same months, the npm registry saw three large supply-chain attacks: a hijacked axios release in March, a worm that went through TanStack's own release pipeline in May, and ChainDrop in August, which Microsoft says reached more than 400 packages.

This article covers both: what changed in Node.js core, what the npm attacks had in common, and the exact versions and settings to use today. It is written for teams running Node.js in production, and every version number links back to its source. If you also run Bun, PHP or Ruby, we have written the same roundup for Bun, PHP and Ruby and Rails.

What is the most serious Node.js vulnerability right now?

CVE-2026-111497, a flaw in the Brotli decoder that ships inside Node.js, nicknamed "Node2Shell". It affects Node 22, 24 and 26, and the fix is in 22.23.4, 24.22.1 and 26.12.1, released on 21 October 2026.

The official advisory explains the mechanism. An invalid block switch in the compressed stream was reported as "need more input" instead of as a format error. The streaming decoder therefore kept appending bytes to an eight-byte internal buffer, past its end. Anyone who can make your application decompress Brotli data with node:zlib can corrupt process memory, "which can lead to a crash, disclosure of process memory, or remote code execution."

The bug is in Google's Brotli library itself, versions 1.0.3 to 1.2.0, so it is not specific to Node.js. It also hit Bun and the Python brotli package. Node.js rates it High. Google, which assigned the CVE, rates it Critical, CVSS v4.0 9.2 (NVD record), and Singapore's Cyber Security Agency scores it 9.8 in its alert.

You are exposed if any code path inflates Brotli data that came from outside, for example:

• Request bodies sent with Content-Encoding: br that your server or middleware decompresses.
• Uploaded or downloaded .br files processed with zlib.brotliDecompress or createBrotliDecompress.
• Outgoing HTTP calls. Node's built-in fetch() (undici) decompresses br responses with zlib.createBrotliDecompress, so an HTTP request to a server you do not control reaches the decoder.

The last point makes this broader than it looks. Webhooks, link previews, scrapers and any "fetch this URL for me" feature are all in scope. There is no configuration flag that removes the risk; the fix is the upgrade.

Everything in the October 2026 release

The same release updates c-ares, OpenSSL (22 and 24), SQLite (22), undici and the bundled CA certificates. That last update follows an intermediate CA compromise at eMudhra.

What did each Node.js security release in 2026 fix?

Every release this year followed the same pattern: a small number of High-severity bugs in network-facing code, a long tail of Medium and Low issues, and dependency updates. Here are the five side by side. The counts are taken from each official post.

Two things stand out. First, several October fixes are repairs of June fixes: CVE-2026-105482 is an incomplete fix of the June DNS bug, and CVE-2026-105483 is a regression after the June TLS fix. Patching once is not enough; you have to keep up.

Second, March was the last release for Node 20. Every Node 20 server running today has missed the June, July and October fixes.

Where do Node.js vulnerabilities come from?

Most core CVEs in 2026 sit in protocol handling and in the native libraries that Node.js bundles, not in JavaScript APIs that you call directly. That matters, because there is nothing you can configure around a bug in the HTTP/2 or Brotli layer. You can only upgrade.

Four patterns cover nearly everything in this year's releases.

1. TLS and DNS disagree about what a name is. NUL bytes, Unicode dots, fullwidth digits, octal IPv4 addresses, SNI case and session reuse: in each case the certificate checker and the resolver read the same hostname differently. An attacker who controls a name can then get a certificate accepted for a host it was not issued for. If you connect to internal services by IP, or pin certificates to hostnames, these bugs are aimed at you.

2. HTTP/2 and the HTTP parser keep producing crashes. Almost every release has an HTTP/2 denial of service, and July added a use-after-free (CVE-2026-56848) and a header-count bug (CVE-2026-58044). The latter lets a forwarding proxy disagree with the backend about where a request ends, which is the setup for request smuggling.

3. Memory-safety bugs in bundled C code. The Brotli decoder, nghttp2 and the WebCrypto AES path are all native code. These are the bugs that move from "crash" to "remote code execution".

4. The Permission Model is bypassed in every release. That is the subject of the next section.

Is the Node.js Permission Model a security sandbox?

No. The Node.js documentation calls it a "seat belt" that stops trusted code from accidentally touching files or resources. It states plainly that it "does not provide security guarantees in the presence of malicious code."

The 2026 releases bear that out. Counting all five posts, we found 14 Permission Model bypasses. They came through process.report, FileHandle.utimes(), chmod() and chown(), realpathSync, trace_events, symlinks, Unix domain sockets and wildcard paths. Several were incomplete fixes of earlier ones.

Use --permission to catch mistakes in code you trust. To run code you do not trust, use operating-system isolation: a container with a read-only filesystem, a separate user, seccomp or AppArmor profiles.

Which Node.js versions are still supported?

Node.js 22, 24 and 26. Node 20 reached end-of-life on 30 April 2026, and the odd-numbered Node 25 followed on 1 June. The project's own wording is that end-of-life versions "are always affected when a security release occurs."

Dates are from the Node.js release schedule. For new production work we would start on Node 24, or on 26 once it becomes LTS on 28 October. Node 22 is still patched, but it has six months left, which is less than most upgrade projects take to plan.

How did the 2026 npm supply-chain attacks work?

The same way each time: steal a publishing credential, ship a release with a script that runs on install, and use whatever that script steals to publish more. The three big incidents differed only in how they got the first credential.

axios, 31 March 2026. A maintainer account was compromised and two releases, axios@1.14.1 and axios@0.30.4, were published with a new dependency, plain-crypto-js@4.2.1. That package's postinstall script dropped a cross-platform remote access trojan that went after .ssh and .aws. The bad versions were live for about three hours, according to Orca Security's analysis. Projects that installed axios in that window, without a lockfile pinning an older version, pulled the trojan.

TanStack and "Mini Shai-Hulud", May 2026. This one did not need a stolen password. Orca reports that the attacker chained GitHub Actions weaknesses: a pull_request_target workflow poisoned the Actions cache, and the release workflow then leaked OIDC tokens. The malicious versions, 373 of them across 169 npm package names, were published through the legitimate pipeline. They therefore carried valid npm provenance. The payload stole GitHub, npm, cloud, Kubernetes and Vault credentials and spread from one package to the next, like the original Shai-Hulud worm of 2025.

ChainDrop, August 2026. Microsoft's write-up describes more than 400 compromised packages from unrelated publishers, including keyv, flat-cache and cache-manager.

• Install hook. A preinstall hook ran setup.mjs, which launched an obfuscated, Bun-based payload.
• Theft. It harvested npm, GitHub and cloud credentials, and used them to read AWS, Kubernetes and Vault secrets.
• Spread. For every package a stolen token could publish, it downloaded the latest tarball, inserted itself, bumped the patch version and republished.
• Persistence in repositories. It also wrote .claude/settings.json and .vscode/tasks.json files into repositories, to spread from developer to developer.

How do you protect a Node.js project from npm supply-chain attacks?

Make new releases wait, stop install scripts from running by default, and make your own publishing pipeline hard to borrow. In order of effort:

1. Commit the lockfile and install with npm ci in CI and in Docker builds. A lockfile means a new malicious patch release only reaches you when someone updates it on purpose.
2. Add a release-age cooldown. Microsoft's ChainDrop guidance is to upgrade to npm CLI v12 and use its min-release-age setting. pnpm has minimumReleaseAge, and so does Bun, in bunfig.toml (see our Bun article). The malicious axios versions were live for about three hours, so a cooldown of a few days would have kept them out entirely.
3. Turn off lifecycle scripts by default with ignore-scripts=true in .npmrc. Then run the few build steps you actually need, such as native modules, explicitly. The axios trojan ran from a postinstall script, and ChainDrop from a preinstall hook.
4. Treat provenance as a signal, not a guarantee. The TanStack versions had valid provenance because the attacker used the real pipeline.
5. Harden your own release workflow if you publish packages. Use trusted publishing (OIDC) instead of long-lived tokens. Never run untrusted pull-request code in a pull_request_target workflow, and do not share caches between untrusted jobs and release jobs.
6. Run npm audit in CI, but know its limits. It reports known advisories against your installed versions; it does not catch a malicious release in its first hours.

Which npm package vulnerabilities should you check in 2026?

Next.js is the urgent one. On 20 October 2026, two unauthenticated remote code execution flaws were published, both CVSS v4.0 9.5, per Singapore's CSA alert:

• GHSA-673q-mjm6-r5xr affects App Router applications using Cache Components, when a "use cache" function returns multiple typed arrays. No CVE ID had been issued at publication.
• CVE-2026-96889 comes from a memory bug in an upstream library used for Image Optimisation, on glibc-based Linux.

Both affect 16.x before 16.4.1 and 10.x to 15.x before 15.5.28. Upgrade to those versions or later.

Beyond Next.js, the most important "package vulnerability" of 2026 was not a bug but the compromised releases above. Check your lockfiles for axios@1.14.1, axios@0.30.4 and plain-crypto-js, and for any ChainDrop-era versions of keyv, flat-cache or cache-manager. Use the version lists in Microsoft's and your security vendor's advisories.

What should you patch first?

1. Upgrade Node.js to 22.23.4, 24.22.1 or 26.12.1, and rebuild container images, because a node:22 base image you pulled last month still has the old binary. Check with node -v in the running container, not on your laptop.
2. Move off Node 20 and 25. They will not get the Brotli fix.
3. Upgrade Next.js to 16.4.1 or 15.5.28 or later if you run it.
4. Search your lockfiles for the compromised axios and ChainDrop versions.
5. Add a cooldown and turn off install scripts for every project and CI pipeline.
6. Stop relying on --permission as isolation for untrusted code.

Nordbeam builds production systems on TypeScript and Node.js. If you have an end-of-life Node line or a dependency tree you are no longer sure about, our software development team can scope the upgrade with you.