Node.js 18 End of Life: What Enterprise Teams Need to Do

Node.js Release Schedule and LTS Lifecycle

Node.js follows an alternating LTS (Long Term Support) model where every even-numbered major version receives LTS status:

• Node.js 14 (LTS "Fermium"): EOL April 2023
• Node.js 16 (LTS "Gallium"): EOL September 2023
• Node.js 18 (LTS "Hydrogen"): EOL April 2025
• Node.js 20 (LTS "Iron"): Active LTS through April 2026, Maintenance through April 2027
• Node.js 22 (LTS "Jod"): Active LTS through April 2027

After the EOL date, the Node.js project stops releasing security patches for that version. The release page lists Node.js 18 with an EOL badge, and the release team does not backport CVEs to 18.x.

What CVEs Affect EOL Node.js 18?

Node.js itself isn't frequently the source of application-layer CVEs, but it underpins several critical security surfaces:

• V8 engine vulnerabilities: Node.js bundles the V8 JavaScript engine. V8 CVEs affecting Node.js 18 are not patched after EOL.
• OpenSSL/libuv: Node.js bundles OpenSSL for TLS and libuv for I/O. OpenSSL receives CVEs regularly; EOL Node.js builds will not receive OpenSSL updates.
• http_parser: Vulnerabilities in the HTTP request parser can affect all Node.js applications serving HTTP traffic.
• npm/package ecosystem: While npm vulnerabilities are separate from the runtime, EOL runtime CVEs can interact with npm package vulnerabilities to create broader exploit chains.

Why Are Many Enterprises Still on Node.js 18?

The Node.js 18 to 20 or 22 migration is not as disruptive as, say, a Spring Boot 2 to 3 migration — but it's not trivial for large Node.js deployments either:

• npm package compatibility: Some packages with native bindings (node-gyp compiled modules) must be rebuilt or replaced for the new Node version.
• V8 API changes: Applications using native addons via the V8 C++ API may require updates.
• CI/CD pipeline updates: Docker base images, GitHub Actions runner versions, and build scripts all reference specific Node versions and must be updated consistently.
• Container base image audits: Many enterprise Node.js deployments use custom base images that pin Node.js at a specific version. Updating 50 microservices' base images, testing each, and rolling out the change is a non-trivial coordination effort.

The Container Image Dimension

A significant source of Node.js 18 EOL exposure in enterprise environments is not the runtime being run directly, but Node.js 18 being baked into Docker base images. A team using node:18-alpine as their base image is running EOL Node.js regardless of whether they explicitly chose that version — it was simply the LTS when the Dockerfile was written, and nobody updated it.

Container scanning tools (Trivy, Grype, Snyk) will flag EOL Node.js in base images as an informational finding, but after the EOL date, CVEs specific to Node.js 18 may not be included in scanner rules if there's no official patch to remediate to. This is the gap extended lifecycle support addresses.

Node.js 18 to 20 Migration Considerations

For most Node.js applications, the 18 to 20 migration is relatively low-risk:

• Node.js 20 maintains the same V8 API surface for most use cases
• CommonJS and ESM module behavior is largely consistent
• The Web Crypto API, built-in fetch, and other web standard additions from Node 18 are available in 20
• The primary changes are V8 version bumps (with performance improvements), updated OpenSSL version, and new diagnostic tooling

OSSeva recommends Node.js 22 as the target for most enterprise migrations, as it provides the longest current support window (LTS through April 2027).

OSSeva's Node.js 18 Extended Lifecycle Support

For enterprises that cannot immediately complete the Node.js 18 migration — perhaps because hundreds of services are containerized on Node 18 base images and the retesting effort is being scheduled for Q3 — OSSeva provides CVE-patched Node.js 18 builds. These include backported fixes for V8, OpenSSL, and http_parser vulnerabilities, delivered as signed container base images (node:18-osseva) and as direct tarballs for bare-metal or VM deployments. Each release includes CVE attestation documentation for audit evidence.