End-of-Life Language Runtimes: Java, Node.js and Python Dates and Upgrade Plans

When a language runtime reaches end of life, newly disclosed vulnerabilities in it are never fixed, and every application, function and container image built on it inherits that exposure. Node.js 18 and 20, Python 3.9 and 3.10 have all passed upstream end of life since April 2025, and Java 17 leaves Oracle Premier Support in September 2026, yet these versions remain common in build images, serverless functions and long-lived services. This guide is for application security teams, platform engineers and engineering leads. It sets out each project's official lifecycle and current dates, how cloud and container platforms layer their own deprecations on top, how to find every runtime and the identities attached to it, the upgrade options, testing and rollback, and what staying put costs. Runtimes are listed alphabetically; order is not a ranking. The PHP-specific companion is Unsupported PHP versions.

Key takeaways

• Each project publishes its own clock. Java LTS releases follow Oracle's support roadmap, Node.js even-numbered releases get about 30 months of LTS, and each Python branch is supported for five years, the last three as security-only.
• Platforms add a second clock. AWS Lambda deprecates a runtime when a major component reaches end of community support, then blocks creates and updates on published dates; container base images age the same way.
• Inventory runtimes, not just dependencies. Software composition analysis often reports libraries but not the interpreter or JVM underneath; check images, functions, CI runners and hosts directly.
• Upgrade one major step at a time, behind tests. Most breakage comes from removed APIs and dependencies that do not support the new version, so upgrade dependencies first and pin the runtime explicitly.
• Commercial extended support is a bridge. The Node.js project itself describes paid support for EOL lines as a temporary solution; the same applies to any runtime.

What is changing and why

Language runtimes are retired on fixed, published schedules so that maintainers can focus fixes on a small number of branches. The models differ, which matters for planning:

For Java, the vendor matters: Oracle's dates apply to Oracle JDK, while other OpenJDK distributions publish their own support periods. Licence terms also change during a release's life; Oracle's roadmap notes, for example, that Java 17 public updates after September 2024 moved from the No-Fee Terms and Conditions to the Java SE OTN licence. Record which distribution each application uses.

Official timeline and current status

Dates below are from each project's own pages, checked on 8 November 2026. "EOL" means the project no longer issues fixes for that line. Scheduled dates can move.

Platform deprecations: the AWS Lambda example

Managed platforms run their own schedules. AWS documents that Lambda deprecates a runtime when a major component reaches end of community long-term support, gives at least 180 days' notice, may stop applying security patches on the deprecation date, then blocks function creation at least 30 days later and updates at least 60 days later. Functions on deprecated runtimes keep running indefinitely, which is exactly why they are forgotten.

Lambda details, including the Amazon Linux 2 end of life on 30 June 2026, are in the AWS Lambda Runtime Deprecation guide. Other function platforms and managed services publish comparable lists; check each one you use.

Who and what is affected

• Container images: application images built on a language base image tag for an EOL version, and multi-stage builds where the build stage uses a newer runtime than the final stage, or the reverse.
• Serverless functions: functions on deprecated runtimes that still run and still hold execution roles.
• CI runners and build tools: build images, linters and deployment scripts that pin an old interpreter. These often hold the most powerful credentials in the organisation.
• Hosts and operating system packages: runtimes installed from distribution packages follow the distribution's support, not upstream's, which can extend or shorten coverage. See Ubuntu LTS End of Standard Support.
• Embedded and vendor software: products that bundle a JVM, Node.js or Python and update it only when the vendor ships a release.
• Libraries and frameworks: as the Node.js project notes, popular packages drop support for EOL lines, so an old runtime also freezes dependencies at vulnerable versions.

Finding affected systems and identities

1. Read the manifests. Collect declared versions from source: the engines field in package.json and .nvmrc for Node.js; requires-python in pyproject.toml, python_requires and .python-version for Python; the compiler release or toolchain setting in Maven and Gradle builds for Java. Declared versions show intent, not reality, so continue.
2. Inspect images. Parse the FROM lines in Dockerfiles and the image configuration in registries, and use image scanners or SBOMs to report the runtime package and version inside each image. See the SBOM Guide.
3. Query function platforms. List every function with its runtime identifier across all accounts and regions, and compare against the platform's deprecated list. Platform notifications go to account contacts that may be unmonitored.
4. Query running hosts. Use endpoint or configuration management inventory to record installed runtime packages and running processes with their versions. Include developer workstations and build agents.
5. Join to owners and credentials. For every EOL runtime found, record the owning team and the identities the workload uses: the function's execution role, the service account, API keys and database credentials in its configuration. An EOL runtime with a broad role is a priority regardless of exposure. See the NHI Discovery Across Cloud, SaaS, CI/CD and On-Premises Environments guide.
6. Rank by exposure. Internet-facing services, code that parses untrusted input and CI systems first; internal batch jobs with narrow permissions later.

Migration options

Decision guidance: set a policy that production uses only versions in active or security support with at least six months remaining, and that new projects start on the newest LTS. Small teams should upgrade straight to the newest LTS to reduce the number of migrations. Large organisations should upgrade shared base images and build templates first, because one change there moves many services, then let teams follow with deadlines tied to the official dates above. Automate routine version bumps; see the Dependency Update Automation Guide.

Testing and rollback

1. Upgrade dependencies first. Move libraries to versions that support both the old and new runtime, deploy, and only then change the runtime. This splits one risky change into two smaller ones.
2. Run the test suite on both versions. Add the target version to the CI matrix and fix failures before switching the default. Watch for removed standard library modules, changed defaults (cryptography, TLS, locale) and deprecation warnings that become errors.
3. Canary in production. Deploy the new runtime to a small share of traffic or one function alias, compare error rates and latency, then expand.
4. Pin explicitly. Use exact base image tags or digests and explicit function runtime identifiers so the change is reviewable and reproducible.
5. Keep the rollback path open. Keep the previous image or function version deployable until the new one is stable. On Lambda, AWS warns that rolling back to a deprecated runtime may be blocked after the update block date, so finish migrations before that date.
6. Verify after. Rescan images and functions, close the inventory item, and rotate any credential that was exposed in old configuration during the move.

Risks of doing nothing

• Known, permanent vulnerabilities: the Node.js project states that when fixes ship for supported lines, EOL lines affected by the same vulnerability get no release, so users are immediately exposed once details are public. That enables MITRE ATT&CK T1190 Exploit Public-Facing Application.
• Dependency freeze: libraries drop old runtimes, so security fixes in dependencies become unreachable, raising supply chain exposure (T1195.001 Compromise Software Dependencies and Development Tools).
• Platform cut-offs: functions that cannot be updated after a block date cannot receive even a configuration fix during an incident.
• Audit findings: the Node.js project notes that many industry audits forbid unmaintained runtimes, and NIST SP 800-53 SA-22 requires replacement or documented alternative support.
• Tool-chain breakage: old runtimes may stop linking against newer system libraries, blocking operating system updates on the same host.

Framework mapping and metrics

Metrics to track: number of workloads per runtime version, split into supported, security-only and EOL; percentage of production workloads with at least six months of support remaining; functions on deprecated platform runtimes (target zero before block dates); median days from a version's EOL to its last production use; percentage of base images rebuilt in the last 30 days; open exceptions past their end date.

Practitioner checklist

• Publish a runtime policy: supported versions only in production, newest LTS for new projects.
• Record official EOL dates for every Java, Node.js and Python version in use, with the date checked.
• Inventory runtimes in manifests, images, functions, CI runners and hosts, joined to owners.
• Record the identities each EOL workload uses and narrow them while migration is pending.
• Upgrade shared base images and build templates before individual services.
• Upgrade dependencies first, test on both versions in CI, then canary the runtime change.
• Finish platform migrations before create and update block dates.
• Treat paid extended support as a dated bridge with an exit plan.
• Track runtime versions as a standing vulnerability management metric.

Standards and references

• Oracle: Java SE Support Roadmap
• Node.js: Node.js Releases
• Node.js: End-of-Life
• Node.js Release Working Group: Release schedule
• Python Software Foundation: Status of Python versions
• AWS: Lambda runtimes
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Unsupported PHP versions · AWS Lambda Runtime Deprecation · Java and Spring Security Guide · Node.js Security Guide · Python Security Guide