How Node.js Extended Support Keeps Applications Secure and Compliant After EOL

Key Takeaways

• Node.js 20 reached end of life on April 30, 2026, joining Node.js 18 and every earlier version in receiving zero security patches from the project.
•  An EOL Node.js version means unpatched CVEs that are already public, and no fixes for anything discovered later.
• Every official Node.js binary bundles roughly 25 components. Some, like OpenSSL, zlib, and ICU, also exist as system libraries your OS patches elsewhere but never inside Node.js; others, like V8 and undici, have no system package at all, so upstream fixes only reach you in a new Node.js build. Every bundled copy freezes at EOL.
• Your options are upgrading to a supported LTS, migrating off Node.js, or using extended support to stay patched while you plan the move on your own schedule.

If part of your stack still runs Node.js 18 or 20, you have plenty of company. Even-numbered LTS lines are widely used in production, and they don’t stop working the day support ends. They just stop getting fixed. Node.js 20 crossed that line on April 30, 2026, and every release before it had already crossed it.

This post covers which Node.js versions are past end of life, what that means for the security and compliance posture of the applications built on them, and the three realistic paths forward: upgrade, migrate, or use Node.js extended support to keep receiving patches while you decide.

Which Node.js Versions Are End of Life?

As of July 2026, only three release lines still receive updates from the Node.js project: 26.x (Current), 24.x (Active LTS), and 22.x (Maintenance LTS). Node.js 20 and everything before it are end of life, as are the odd-numbered lines that never entered LTS.

Node.js has historically shipped two major versions per year, with the even-numbered ones promoted to Long Term Support: roughly six months as Current, twelve months as Active LTS with bug and security fixes, then a Maintenance phase of critical fixes only – about 30 months of LTS, or roughly 36 months from first release to end of life.

That model is changing. Starting with Node.js 27, the project moves to one major release per year, every release becomes LTS, and version numbers align with the calendar year: 27.0.0 in 2027, 28.0.0 in 2028. A new Alpha channel opens in October 2026 to take over the early-testing role odd-numbered lines used to play, and Node.js 26 is the last line under the old model. Total support stays where it is, at roughly 36 months from first Current release to end of life. A more predictable schedule, but the endpoint is the same: every line still has a date after which patches stop.

You can also explore our detailed analysis of the Node.js 18 EOL timeline and impact in our dedicated guide.

What Node.js EOL Means for Your Applications

The Node.js project is unusually direct about this. Its own End-of-Life page warns of four consequences: no more vulnerability fixes, toolchain breakage, ecosystem drift as popular packages drop support for old runtimes, and compliance red flags because “many industry audits forbid unmaintained runtimes.”

The Unpatched CVEs You Already Know About

Node.js releases security updates on a regular cycle, and each one skips the EOL lines entirely. As of July 30, 2026, the project’s EOL page lists 27 high-severity vulnerabilities against Node.js 20 and 15 against Node.js 18, and those counts only grow.

The pattern is what makes this dangerous. The July 29, 2026 security release went to the 26.x, 24.x, and 22.x lines only. It fixed eleven issues, three of them high severity, including an HTTP/2 re-entrancy bug in bundled nghttp2 that leaves the process with a heap use-after-free. Node.js 20 and 18 received nothing, and the advisory told attackers exactly where to look in every version that didn’t get the fix. Public advisory, public patch, public diff. Most of the discovery work is already done.

For a sense of what a serious one looks like, take HTTP/2 Rapid Reset (CVE-2023-44487). It was exploited as a zero-day to launch the largest DDoS attacks ever recorded at the time, and it affected every Node.js server with HTTP/2 enabled. Node.js 18 and 20 were patched within days. If the same flaw dropped today, neither line would ever get a fix from the Node.js project.

The CVEs That Will Never Be Patched

The Node.js security team does not evaluate or fix vulnerabilities in EOL lines. In January 2025 the project tried to make that visible to vulnerability scanners by issuing CVE-2025-23087, a blanket CVE covering Node.js 17 and every earlier version, with companion CVEs for 19 and 21. The CVE Program rejected all three. The replacement policy is broader: every new Node.js CVE now covers EOL release lines by default, unless the project has specific information that it does not apply to one.

So Node.js 18 and 20 are not named in a blanket EOL advisory – they are presumed affected by every advisory that follows. The project’s stated reason is resources: with more than twenty EOL versions, each with different dependencies and build processes, and vulnerabilities that present differently depending on components like OpenSSL, comprehensive assessment is not feasible. Anything found in them stays unevaluated and unfixed.

Compliance Red Flags

Auditors reach the same conclusion by a different route. PCI DSS 4.x Requirement 6.3.3 expects patches for critical vulnerabilities, identified through your own risk-ranking process, to be installed within one month of release, which no process can satisfy when no patch exists. SOC 2’s security criteria assume a working vulnerability management process, and software with no patch source makes that difficult to demonstrate. For federal and regulated workloads, an unmaintained runtime can be a finding in its own right, before anyone asks about specific CVEs.

The Hidden Risk: Node.js’s Bundled Dependency Tree

Here’s the part that surprises even experienced teams: Node.js is not just Node.js. The project’s dependency documentation lists 30 components in its source tree, and roughly 25 of them ship inside every official Node.js binary. That includes the V8 JavaScript engine, the libuv event loop, the llhttp HTTP parser, the undici HTTP client, nghttp2, nghttp3, and ngtcp2 for HTTP/2 and HTTP/3, the c-ares DNS resolver, zlib, brotli, and zstd for compression, ICU, SQLite, npm itself, and Node’s own copy of OpenSSL. (The exact set varies by major version – Node.js 18 and 20 predate the bundled SQLite and zstd, for instance.)

Those components fall into two groups, and both are a problem after EOL. Roughly half also exist as system libraries: OpenSSL, zlib, SQLite, ICU, nghttp2, c-ares, libuv. Your OS patches those elsewhere on the system, but official Node.js binaries – the ones from nodejs.org, from version managers like nvm, and the standard Docker images – compile in their own copies, and OS updates never reach them. (Some Linux distribution packages link against a few system libraries instead, but that’s the exception.) The other half, including V8, llhttp, undici, and npm, is maintained upstream but has no system package anywhere on your machine, so a fix in the upstream project only reaches you when a new Node.js build ships it. Either way the conclusion is identical: fixes reach you through a new Node.js build or not at all, and when a release line goes EOL, the entire tree freezes together.

This is not theoretical exposure. Rapid Reset was an HTTP/2 protocol-level weakness that Node.js addressed through its bundled nghttp2, not in code the Node.js team wrote. The July 2026 security release shipped undici and llhttp updates alongside Node’s own fixes. On a supported version, those arrive automatically. On an EOL version, each of those components quietly accumulates whatever upstream CVEs apply to it, with no delivery path for the fixes.

Any serious extended support option has to cover this entire surface, which is why TuxCare’s Endless Lifecycle Support (ELS) patches the bundled dependency tree, not just the Node.js core.

Your Options After Node.js EOL

Three real paths, and the right one depends on how much migration risk you can absorb right now:

• Can’t upgrade this quarter but need to stay patched? Extended support.
• Have the engineering time and a compatible dependency chain? Upgrade to a supported LTS.
• Node.js is a small or shrinking part of your stack? Consider migrating off Node.js while you’re at it.

Use Endless Lifecycle Support for Node.js

The fastest way to take the immediate risk off the table without touching your codebase is vendor-backed patching. TuxCare’s ELS for Node.js delivers ongoing security fixes for Node.js 12, 14, 16, 18, and 20: patches are backported from upstream, tested for integrity and regressions, signed, SLA-backed, and delivered through the package managers you already use. TuxCare delivers this as a partner in the OpenJS Foundation’s Ecosystem Sustainability Program, and is listed as a commercial support provider on the Node.js project’s own EOL page.

Coverage includes the bundled dependency tree described above, from OpenSSL to undici, at no extra cost. You can check live vulnerabilities and fixes for Node.js in the TuxCare CVE Tracker to see exactly what’s being patched.

To be clear about the role this plays: it’s a bridge, not a destination. ELS buys back what EOL takes away: time to plan an upgrade on your terms instead of under breach or audit pressure.

Upgrade to a Supported LTS

The clean long-term answer. Node.js 24 brings years of performance work, current V8 features, and support through April 30, 2028. Node.js 22 is still supported too, but only until April 30, 2027, which makes it a stopover rather than a destination. If your dependency tree is healthy and your test coverage is decent, a one-major-version jump is often manageable.

The effort scales with distance and codebase complexity, though. Each major version carries breaking changes, native addons need rebuilding against the new ABI, and packages pinned years ago may have no compatible release. Jumping from 18 to 24 is not one migration; it’s three stacked on top of each other.

Migrate to Another Technology

If a service is due for a rewrite anyway, EOL can be the trigger to consolidate onto whatever your organization now considers strategic, whether that’s another runtime like Deno or Bun or a different language entirely. That flexibility is real, but so is the cost: a migration can mean rewriting much of what the service does, with the full testing burden attached. It rarely makes sense as a response to EOL alone.

The Risks of Rushing an Upgrade

A Node.js major version upgrade is a project, not a dependency bump. It means adapting code to breaking API changes, verifying compatibility across your entire lock file, rebuilding native modules, updating CI images, Dockerfiles, and build toolchains, and regression-testing everything that touches the runtime.

Teams that compress that work into an emergency, usually because an audit or a disclosed CVE forces their hand, tend to pay for it downstream: production instability from under-tested paths, a spike in support load, workarounds pinned in place that harden into technical debt, and unplanned costs precisely where the budget didn’t expect them. The pattern shows up reliably enough that avoiding the forced-upgrade scenario is itself a security strategy. Deadline pressure and careful engineering don’t mix.

Secure Node.js Beyond EOL with TuxCare

TuxCare has spent over a decade building the discipline behind enterprise-grade vulnerability patching, and today delivers backported fixes to more than 2,300 enterprise clients across financial services, telecom, healthcare, and government. The patching process pairs automated vulnerability monitoring, patch assessment, and backporting with expert validation, and every release is built from vetted sources and signed, with attestations covering its dependencies.

For Node.js, that translates into continuous security patching, stability, and audit evidence for the versions your applications actually run: bundled dependency coverage, fixes delivered through your existing package managers, and a price that is a fraction of the cost of an unplanned migration. Explore ELS for Node.js, or start with the CVE Tracker to check live vulnerabilities and fixes for Node.js.

Summary

Article Name

Node.js Extended Support: Staying Secure After EOL

Description

Node.js 20 and 18 no longer get security patches. See which versions are EOL, what it means for your apps, and how Node.js extended support keeps you covered.

Author

Artem Karasev

Publisher Name

TuxCare

Publisher Logo