Node.js runs the back end of a huge share of today’s applications: the part that processes payments, stores data and connects services. At HitOcean we use it on many of the products we build for our clients, so we follow every security advisory closely. And 2026 kept us busy.
The threats came from two directions. Node.js itself patched 50 vulnerabilities in five security releases. Meanwhile, npm, the registry projects download their building blocks from, was hit by several supply chain attacks, the largest one spreading to more than 440 packages. Here’s what happened, which versions are no longer supported and what we check on every project.
The Node.js vulnerabilities patched in 2026
According to the official Node.js vulnerability blog, these were the security releases this year:
| Date | Vulnerabilities fixed | High severity |
|---|---|---|
| January 13 | 8 | 3 |
| March 24 | 9 | 2 |
| June 18 | 12 | 2 |
| July 29 | 11 | 3 |
| October 21 | 10 | 4 |
A sixth release is already announced for November 11, with at least one high-severity fix for the 22.x, 24.x and 26.x lines.
You don’t need to read every CVE (the ID each published vulnerability gets, so everyone refers to the same one) to see the pattern. Many of them let an attacker crash a server with a crafted request. In March, simply sending a header named __proto__ was enough to take a process down (CVE-2026-21710). Others weakened TLS certificate checks, the part that confirms you’re talking to who you think you’re talking to: in October, an IPv4 address written with a leading zero, like 0127.0.0.1, could get a certificate validated against the wrong IP (CVE-2026-106069). And the most serious one in October, in the bundled Brotli decoder, could allow remote code execution (CVE-2026-111497).
The npm supply chain attacks of 2026
No project is written from scratch. A typical Node.js app pulls in hundreds of open source packages, and each of them pulls in more. That web of third-party code is the software supply chain, and attackers have learned that compromising one link is often easier than attacking you directly.
- May, node-ipc. Three malicious versions of this library, which has over 10 million weekly downloads, were published from a maintainer account with no prior history on the package.
- May, fake internal packages. Microsoft found 45 packages named after the internal packages of nine real organizations. It’s called dependency confusion: a project installs the fake package thinking it’s its own.
- August, keyv. A self-spreading worm got in through the GitHub account of the keyv maintainer and moved on to other packages. It reached more than 440 packages and 1,381 versions, with over 2 billion monthly installs combined.
You can read the details in the reports from StepSecurity on node-ipc, Microsoft on dependency confusion and Aikido on keyv.
All three had the same goal: the keys, not the app’s data. The malicious code went after npm and GitHub tokens, cloud credentials, database passwords and .env files. With those, an attacker can publish more infected versions or walk straight into a company’s infrastructure.
One detail of the keyv case stands out to us. The infected versions were published through the project’s own automated release pipeline, so they carried valid provenance, the signature that says a package was built from its official repository. The signature was real. The attacker simply controlled the account. A package coming from the right place doesn’t mean it’s safe.
It’s the same logic behind the Binance hack and social engineering attacks: attackers don’t break the door down, they get someone inside to open it without noticing.
Node.js versions that are end of life
This is the issue we find most often in codebases that come to us for maintenance. Each Node.js release line gets security patches for a set period and then it’s on its own. Based on the official release schedule:
| Version | Status in November 2026 |
|---|---|
| Node.js 18 | End of life since April 30, 2025 |
| Node.js 20 | End of life since April 30, 2026 |
| Node.js 25 | End of life since June 1, 2026 |
| Node.js 22 | Patched until April 30, 2027 |
| Node.js 24 | Patched until April 30, 2028 |
| Node.js 26 | Patched until April 30, 2029 |
Node.js says it in every advisory: when a security release ships, end-of-life versions are always affected and don’t get the fix. If your app still runs on Node.js 20, the June, July and October vulnerabilities are still open on your servers.
What we check on every Node.js project at HitOcean
This is what we do on the products we build and maintain, and what we recommend you review on yours:
- The Node.js version. The app runs on a supported line, and there’s a date on the calendar for the next upgrade. If you’re on 22 today, the move to 24 should already be planned.
- Pinned dependencies. The lockfile (
package-lock.json) is committed and respected, so nobody installs a version that came out yesterday by surprise. - No same-day upgrades. Most malicious versions are caught within hours or a few days. Waiting before adopting a new release cuts the risk significantly.
- Install scripts under control. The keyv worm and the dependency confusion packages ran the moment they were installed. Disabling lifecycle scripts where they aren’t needed closes that path.
- Least-privilege tokens. npm, GitHub and CI tokens can only do what they need to, and they expire as soon as possible.
- A plan for when it happens. If a compromised package reaches a laptop or a CI runner, assume every secret in that environment is exposed and rotate it. Having that list ready beforehand saves hours when every minute counts.
- Outside testing. Penetration testing shows what an attacker can actually do with what they find, and a cybersecurity audit reviews versions, dependencies and access in a structured way.
The bottom line
2026 made it clear that the security of a Node.js application doesn’t depend only on the code your team writes. It depends on hundreds of third-party packages, on the Node.js version it runs on and on who holds the keys to publish and deploy.
None of these measures is hard on its own. The hard part is keeping them up, project after project. If you want to know where yours stands, our security services for companies can help you find out.