DEV Community: endoflife-ai

Cisco IOS XE End of Life Dates: Full Version EOL & EoS Guide (17.x)

endoflife-ai — Thu, 28 May 2026 04:50:28 +0000

Knowing when your Cisco IOS XE version reaches end of software maintenance is essential for network compliance and vulnerability management. This guide covers the IOS XE lifecycle model, all 17.x release train dates, and how to determine whether your version is still receiving security fixes.

Quick answer: IOS XE 17.15.x (Long-Lived) is the current recommended release. IOS XE 17.12.x (Long-Lived) is in active maintenance. IOS XE 17.9 and earlier have reached or are approaching End of Software Maintenance.

⚠️ Always verify dates against official Cisco EoL product bulletins — this guide uses Cisco's standard release cadence for approximate dates where official bulletins are not yet published.

Understanding the Cisco IOS XE Release Model

Cisco IOS XE uses a two-track release model:

Standard Maintenance (SM) Releases

Ship approximately every 6 months. Receive roughly 12 months of software maintenance. Good for environments that want latest features. Examples: 17.3, 17.6, 17.9.

Long-Lived (LL) Releases

Designated for stable production deployments. Receive approximately 36 months of software maintenance — 3× the Standard window. Recommended for enterprise production networks. Examples: 17.3 LL, 17.6 LL, 17.9 LL, 17.12 LL, 17.15 LL.

⚠️ Cisco issues separate EoL bulletins for Standard vs. Long-Lived releases within the same version train. A 17.9 Standard release has an earlier end of maintenance date than 17.9 LL.

Cisco IOS XE 17.x Release Train — EOL Overview

IOS XE Release	Type	First Released	End of SW Maintenance	End of Support	Status
17.15.x	Long-Lived	~Q3 2025	~Q3 2028	~Q3 2030	✅ Current LL
17.14.x	Standard	~Q1 2025	~Q1 2026	~Q1 2028	✅ Active
17.13.x	Standard	~Q3 2024	~Q3 2025	~Q3 2027	🟡 Maintenance
17.12.x	Long-Lived	Mar 2024	~Mar 2027	~Mar 2029	✅ LL – Active
17.11.x	Standard	~Q3 2023	~Q3 2024	~Q3 2026	❌ EOL
17.10.x	Standard	~Q1 2023	~Q1 2024	~Q1 2026	❌ EOL
17.9.x	Long-Lived	Aug 2022	Aug 2025	Aug 2027	❌ EOL
17.8.x	Standard	~Q1 2022	~Q1 2023	~Q1 2025	❌ EOL
17.7.x	Standard	~Q3 2021	~Q3 2022	~Q3 2024	❌ EOL
17.6.x	Long-Lived	Jul 2021	Jul 2024	Jul 2026	❌ EOL
17.5.x	Standard	~Q1 2021	~Q1 2022	~Q1 2024	❌ EOL
17.4.x	Standard	~Q3 2020	~Q3 2021	~Q3 2023	❌ EOL
17.3.x	Long-Lived	Oct 2020	Oct 2023	Oct 2025	❌ EOL
17.2.x	Standard	~Q1 2020	~Q1 2021	~Q1 2023	❌ EOL
17.1.x	Standard	~Q3 2019	~Q3 2020	~Q3 2022	❌ EOL

Dates marked ~ are approximate based on Cisco's standard cadence. Verify against official Cisco EoL bulletins.

Cisco IOS XE 16.x — Legacy Releases

All 16.x releases are end of life.

IOS XE 16.x Release	Type	End of SW Maintenance	Status
16.12.x (Fuji)	Long-Lived	Jan 2023	❌ EOL
16.11.x	Standard	~Apr 2021	❌ EOL
16.9.x (Fuji)	Long-Lived	Oct 2021	❌ EOL
16.6.x (Everest)	Long-Lived	Jan 2020	❌ EOL

Key Release Notes

IOS XE 17.15 — Current Long-Lived

The current recommended Long-Lived release. Expected maintenance until approximately Q3 2028. Target version for networks being upgraded in the 2025–2026 window. Full support for Catalyst 9000, ISR 4000, and ASR 1000.

IOS XE 17.12 — Stable Long-Lived

Widely deployed in enterprise production. First released Q1 2024. End of software maintenance expected approximately March 2027. Solid choice for environments that cannot yet upgrade to 17.15.

IOS XE 17.9 — End of Life (August 2025)

One of the most widely deployed enterprise versions. End of Software Maintenance: August 2025. Networks still on 17.9 should upgrade to 17.12 or 17.15.

IOS XE 17.6 — End of Life (July 2024)

End of Software Maintenance: July 2024. No longer receiving security patches.

IOS XE 17.3 — End of Life (October 2023)

End of Software Maintenance: October 2023. Fully unsupported.

Quick Reference: Common Version Queries

Version String	Train	Type	Status
17.15.x	17.15	Long-Lived	✅ In Maintenance (~2028)
17.12.x	17.12	Long-Lived	✅ In Maintenance (~2027)
17.9.x	17.9	Long-Lived	❌ EOL – Aug 2025
17.6.x	17.6	Long-Lived	❌ EOL – Jul 2024
17.3.x	17.3	Long-Lived	❌ EOL – Oct 2023
16.12.x	16.12	Long-Lived	❌ EOL – Jan 2023

Platforms Running Cisco IOS XE

Catalyst 9000 Series — 9200, 9300, 9400, 9500, 9600, 9800 (wireless)
ISR 4000 Series — 4221, 4321, 4331, 4351, 4431, 4451, 4461
ASR 1000 Series — 1001-X, 1001-HX, 1002-X, 1002-HX, 1004, 1006-X
CSR 1000V / Catalyst 8000V — virtual router platforms
Catalyst 8000 Edge — 8200, 8300, 8500

How to Check Your IOS XE Version

Router# show version
Cisco IOS XE Software, Version 17.12.04

Router# show version | include IOS XE

How to Upgrade (Catalyst 9000 Install Method)

# Download image to flash
copy tftp://server/cat9k_iosxe.17.12.04.SPA.bin flash:

# Install
install add file flash:cat9k_iosxe.17.12.04.SPA.bin
install activate
install commit

FAQ

What is IOS XE 17.12 end of life?
Long-Lived release. End of Software Maintenance approximately March 2027. Verify at cisco.com.

Is IOS XE 17.9 still supported?
No. End of Software Maintenance was August 2025. Upgrade to 17.12 or 17.15.

What is the difference between EoS and EoL for Cisco?

End of Sale (EoS): Product can no longer be purchased
End of Software Maintenance: No new software releases or patches
End of Vulnerability Support: No more CVE patches
End of Support (EoL): All support ends, including TAC

For software releases, End of Software Maintenance is the critical milestone.

What happened to Cisco IOS 15.x (Classic)?
All 15.x releases have reached end of life. Classic IOS 15.1 EOL was January 2023. Plan hardware refreshes to IOS XE-based platforms.

Live version data: endoflife.ai/cisco-ios-xe

Debian End of Life Dates: Debian 10, 11, 12, and 13 Support Timelines

endoflife-ai — Thu, 28 May 2026 04:49:31 +0000

Debian uses a layered support model — regular security support, Long Term Support (LTS), and Extended Long Term Support (ELTS) — giving each release up to 7+ years of coverage. This guide covers every Debian release codename, release date, end of regular support, LTS end date, and ELTS end date.

Quick answer: Debian 13 (Trixie, released August 9, 2025) is the current stable release. Debian 12 (Bookworm) is oldstable with regular security support until ~August 2026 and LTS to ~June 2028. Debian 11 (Bullseye) is in LTS until August 2026. Debian 10 (Buster) is fully end of life.

Debian Release EOL Dates — Full Table

Version	Codename	Release Date	End of Regular Support	LTS End	ELTS End	Status
Debian 13	Trixie	Aug 9, 2025	~Aug 2028	Jun 30, 2030	~Jun 2032	✅ Stable
Debian 12	Bookworm	Jun 10, 2023	~Aug 2026	~Jun 2028	~Jun 2030	✅ Oldstable — Supported
Debian 11	Bullseye	Aug 14, 2021	Aug 31, 2024	Aug 31, 2026	Jun 30, 2028	🟡 LTS
Debian 10	Buster	Jul 6, 2019	Aug 10, 2022	Jun 30, 2024	Jun 30, 2026	❌ EOL
Debian 9	Stretch	Jun 17, 2017	Jun 6, 2020	Jun 30, 2022	Jun 30, 2025	❌ EOL
Debian 8	Jessie	Apr 25, 2015	Jun 17, 2018	Jun 30, 2020	Jun 30, 2025	❌ EOL

Understanding Debian's Three Support Tiers

Tier 1: Regular Security Support (~3 years)

Provided by the Debian Security Team. Covers the full main archive with timely security patches. Runs from release until approximately 1 year after the next stable release ships. Most users and production systems rely on this tier.

Tier 2: Long Term Support / LTS (~2 additional years)

After the Security Team ends support, the Debian LTS team (volunteers + corporate sponsors like Freexian) maintains security patches for ~2 more years. Covers most packages in main, but not every package. Free to use — no subscription required.

Tier 3: Extended LTS / ELTS (~2 additional years)

A commercial offering from Freexian extending support ~2 years beyond LTS. Covers only the most critical/popular packages. Requires a paid subscription.

⚠️ Coverage narrows with each tier: Regular covers the full archive → LTS covers most packages → ELTS covers only the most popular subset. Check your specific packages before relying on LTS/ELTS.

Debian 13 (Trixie) — Current Stable

Released approximately June 2025. Notable upgrades: GCC and LLVM toolchain updates, Python and Rust updates, Linux 6.x kernel, improved ARM64 and RISC-V support, updated installer.

Regular support: ~June 2028
LTS: ~June 2030
ELTS: ~June 2032

Debian 12 (Bookworm) — Oldstable, Active

Released June 10, 2023. Transitioned to "oldstable" when Trixie shipped, but remains actively supported by the Debian Security Team until approximately June 2026.

Ships with: Linux kernel 6.1, GNOME 43, KDE Plasma 5.27, Python 3.11, PHP 8.2, PostgreSQL 15, MariaDB 10.11.

How long is Debian 12 (Bookworm) supported?

Support Tier	Window
Regular security support	Jun 2023 → ~Jun 2026 (~3 years)
LTS	~Jun 2026 → ~Jun 2028 (+2 years)
ELTS (commercial)	~Jun 2028 → ~Jun 2030 (+2 more years)
Total coverage	Up to ~7 years

Debian 11 (Bullseye) — In LTS

Released August 14, 2021. Regular support ended August 31, 2024. Currently in LTS — LTS ends August 31, 2026. ELTS (commercial) continues until June 30, 2028.

Ships with: Linux 5.10 LTS, Python 3.9, PHP 7.4, MariaDB 10.5, PostgreSQL 13.

If you're running Debian 11 (Bullseye) in 2026, you're in the LTS window — still receiving security patches from the LTS team. LTS ends August 31, 2026. Plan your upgrade to Debian 12 or 13.

Debian 10 (Buster) — Fully End of Life

Released July 6, 2019. Regular support ended August 2022. LTS ended June 30, 2024. ELTS ended June 30, 2026. Debian 10 is now fully end of life through all support tiers. Migrate immediately to Debian 12 or 13.

Debian Codename Reference

All Debian codenames are characters from the Toy Story films, assigned alphabetically:

Number	Codename	Character	Status
14	Forky	Forky (TS4)	Testing
13	Trixie	Trixie the triceratops	Stable
12	Bookworm	Bookworm the caterpillar	Oldstable
11	Bullseye	Bullseye the horse	LTS
10	Buster	Buster the dog	EOL
9	Stretch	Stretch the octopus	EOL

How to Check Your Debian Version

cat /etc/debian_version
# 12.x

lsb_release -a
# Distributor ID: Debian
# Codename:       bookworm

Upgrading Debian 11 (Bullseye) → Debian 12 (Bookworm)

# Update all current packages
sudo apt update && sudo apt upgrade -y && sudo apt full-upgrade -y

# Switch sources to Bookworm
sudo sed -i 's/bullseye/bookworm/g' /etc/apt/sources.list
sudo sed -i 's/bullseye/bookworm/g' /etc/apt/sources.list.d/*.list

# Run upgrade
sudo apt update
sudo apt full-upgrade -y

sudo reboot

For Bookworm → Trixie, repeat with bookworm/trixie. Always read the official Debian release notes for the specific version pair before upgrading.

FAQ

When is Debian 12 (Bookworm) end of life?
Regular support ends ~August 2026. LTS extends to ~June 2028. ELTS (commercial) to ~June 2030.

When is Debian 11 (Bullseye) end of life?
Regular support ended August 31, 2024. LTS runs until August 31, 2026. ELTS until June 30, 2028.

When is Debian 13 (Trixie) end of life?
Released August 9, 2025. Regular support runs until approximately August 2028. LTS to June 30, 2030.

What is the difference between Debian LTS and ELTS?
LTS is a free community effort — 2 extra years of security support after regular EOL. ELTS is a commercial Freexian service — 2 more years on top of LTS, but covering only the most popular packages.

Is Debian 10 (Buster) still supported?
No. ELTS ended June 30, 2026. Buster is fully end of life through all tiers.

How often does Debian release new stable versions?
Approximately every 2 years, released "when ready." Recent cadence: Buster (2019), Bullseye (2021), Bookworm (2023), Trixie (~2025).

What codename does Debian 12 use?
Debian 12 uses the codename Bookworm. Debian 13 is Trixie. Debian 14 (in testing) is Forky.

Live version data: endoflife.ai/debian

Spring Boot End of Life Dates: Complete Version EOL Guide (2.x, 3.x and 4.x)

endoflife-ai — Thu, 28 May 2026 04:48:37 +0000

Spring Boot releases a new minor version approximately every 6 months, and each version has a defined open source (OSS) support window. If you're running an unsupported version, you're missing security patches and likely out of compliance with enterprise security policies. This guide covers every Spring Boot 2.x and 3.x version with exact OSS and commercial support end dates.

Quick answer: Spring Boot 4.0 (released Nov 30, 2025) and Spring Boot 3.5 are the current supported releases. Spring Boot 3.4 OSS support ended December 31, 2025. Spring Boot 3.3 OSS support ended June 30, 2025. All Spring Boot 2.x OSS support has ended — Spring Boot 2.7 commercial support runs to June 30, 2029.

Spring Boot Version EOL Dates — Complete Table

Spring Boot	Release Date	OSS Support Ends	Commercial Support Ends	Spring Framework	Min Java	Status
Spring Boot 4.0	Nov 30, 2025	~Jun 2027	~Dec 2028	Spring 7.0	Java 17	✅ Active — Recommended
Spring Boot 3.5	May 31, 2025	Jun 30, 2026	~Dec 2027	Spring 6.2	Java 17	✅ Active
Spring Boot 3.4	Nov 30, 2024	Dec 31, 2025	~Jun 2027	Spring 6.2	Java 17	🟡 OSS EOL — Commercial Only
Spring Boot 3.3	May 31, 2024	Jun 30, 2025	~Dec 2026	Spring 6.1	Java 17	❌ OSS EOL
Spring Boot 3.2	Nov 30, 2023	Dec 31, 2024	~Jun 2026	Spring 6.1	Java 17	❌ EOL
Spring Boot 3.1	May 31, 2023	Jun 30, 2024	~Dec 2025	Spring 6.0	Java 17	❌ EOL
Spring Boot 3.0	Nov 24, 2022	Dec 31, 2023	~Jun 2025	Spring 6.0	Java 17	❌ EOL
Spring Boot 2.7	May 31, 2022	Jun 30, 2023	Jun 30, 2029	Spring 5.3	Java 8	❌ OSS EOL
Spring Boot 2.6	Nov 17, 2021	Feb 24, 2023	—	Spring 5.3	Java 8	❌ EOL
Spring Boot 2.5	May 20, 2021	Aug 18, 2022	—	Spring 5.3	Java 8	❌ EOL
Spring Boot 2.4	Nov 12, 2020	Feb 22, 2022	—	Spring 5.3	Java 8	❌ EOL

Note on commercial support: VMware/Broadcom Tanzu Spring Runtime subscribers get an extended patch window after OSS EOL. This is a bridge for long enterprise release cycles, not a reason to avoid upgrading.

Understanding the Spring Boot Release Cycle

OSS Support Window (~12–15 months)

From release until ~3 months after the next minor version ships. The Spring team publishes patch releases (e.g., 3.4.1, 3.4.2) with bug fixes and security patches. Free for everyone.

Commercial Support Window (VMware Tanzu / Broadcom)

An additional 6–12 months beyond OSS EOL for Tanzu Spring Runtime subscribers. Critical security fixes are backported into the commercial stream. Intended for enterprises with longer upgrade cycles.

End of Life

After both windows close, no patches are available through any channel.

Spring Boot 4.0 — Current Recommended

Released November 30, 2025, built on Spring Framework 7.0. Requires Java 17 minimum. Spring Boot 4.0 is the current recommended version for new projects in 2026.

OSS support ends: ~June 2027

Commercial support ends: ~December 2028

Spring Boot 3.5 — Active

Released May 31, 2025, built on Spring Framework 6.2. Requires Java 17 minimum (Java 21 strongly recommended). Key improvements:

Enhanced virtual threads support (Project Loom)
Improved observability with Micrometer
Spring gRPC integration
Further AOT/GraalVM native image improvements

OSS support ends: June 30, 2026

Commercial support ends: ~December 2027

Spring Boot 3.4 — OSS EOL December 31, 2025

Released November 30, 2024. OSS support ended December 31, 2025. Commercial support extends to approximately June 2027. Upgrade to Spring Boot 3.5 or 4.0.

Spring Boot 3.3 — OSS EOL June 30, 2025

OSS support ended June 30, 2025. Commercial support (Tanzu) through approximately December 2026. For open source users, 3.3 is no longer receiving patches. Upgrade to Spring Boot 3.5 or 4.0.

Spring Boot 3.2 — OSS EOL December 31, 2024

OSS support ended December 31, 2024. Notable features: initial virtual threads support for Tomcat/Jetty, RestClient (replacing RestTemplate for new code), and GraalVM native image improvements. Commercial support runs until approximately June 2026. Upgrade to 3.5 or 4.0.

Spring Boot 2.7 — OSS EOL, Long Commercial Support

The last Spring Boot 2.x release — the final version to support Java 8. OSS support ended June 30, 2023. Commercial support (VMware/Broadcom Tanzu) extends to June 30, 2029. Note: the underlying Spring Framework 5.3 reached OSS EOL December 31, 2024.

🚨 Still on Spring Boot 2.7? The biggest migration challenge is the Java EE → Jakarta EE namespace change (javax.* → jakarta.*). Use OpenRewrite to automate most of the upgrade.

Spring Boot vs. Spring Framework EOL

Spring Boot Version	Spring Framework	Spring Framework OSS EOL
Spring Boot 3.5	Spring Framework 6.2	Dec 2027
Spring Boot 3.3 / 3.4	Spring Framework 6.1	Aug 2025
Spring Boot 3.0 / 3.1 / 3.2	Spring Framework 6.0	Feb 2025
Spring Boot 2.6 / 2.7	Spring Framework 5.3	Dec 2024

Spring Framework 5.3 reached end of life December 31, 2024. Even with a commercial Spring Boot 2.7 subscription, the underlying Spring Framework is unpatched.

Migrating from Spring Boot 2.7 to 3.x

Upgrade to Java 17 — required minimum for Spring Boot 3.x
Run OpenRewrite UpgradeSpringBoot_3_0 recipe to automate namespace migration
Replace javax.* imports with jakarta.* throughout your codebase
Update Spring Security — WebSecurityConfigurerAdapter is removed; use the lambda DSL
Update renamed properties — many Spring Boot config keys changed in 3.x
Test thoroughly — several deprecated APIs from 2.7 are removed in 3.x

FAQ

When is Spring Boot 3.2 end of life?
OSS support ended December 31, 2024. Commercial (Tanzu) support ends approximately June 2026. No open source patches are being published.

When is Spring Boot 3.4 end of life?
OSS support ended December 31, 2025. Commercial support approximately June 2027. Upgrade to 3.5 or 4.0.

Is Spring Boot 2.7 still supported?
OSS support ended June 30, 2023. Commercial support (Tanzu) extends to June 30, 2029. Note: Spring Framework 5.3 (the underlying framework) reached OSS EOL December 31, 2024.

What Java version does Spring Boot 3.x require?
Java 17 minimum. Java 21 (LTS) is strongly recommended — required for full Project Loom virtual thread support in Spring Boot 3.2+.

When is Spring Boot 3.5 end of life?
OSS support ends June 30, 2026. Commercial support approximately December 2027.

When is Spring Boot 4.0 end of life?
Released November 30, 2025. OSS support ends approximately June 2027. Commercial support approximately December 2028.

Live version data: endoflife.ai/spring-framework

PHP End of Life Dates: Every PHP Version EOL Date (7.0–8.5)

endoflife-ai — Thu, 28 May 2026 04:47:42 +0000

Running an unsupported PHP version means your application is exposed to unpatched security vulnerabilities — many hosting providers and security scanners flag this as a critical risk. This guide lists the exact EOL date for every PHP version from 7.0 through 8.5, explains the PHP release cycle, and tells you which version you should be running right now.

Quick answer: PHP 8.4 is the current recommended version (EOL December 31, 2028). PHP 8.3 is in security-only mode. PHP 8.2 reaches EOL December 31, 2026. PHP 7.x is entirely end of life.

All PHP Versions — EOL Dates at a Glance

PHP Version	Release Date	Active Support Ends	Security Support Ends (EOL)	Status
PHP 8.5	Nov 20, 2025	Dec 31, 2027	Dec 31, 2029	✅ Active
PHP 8.4	Nov 21, 2024	Dec 31, 2026	Dec 31, 2028	✅ Active — Recommended
PHP 8.3	Nov 23, 2023	Nov 23, 2025	Dec 31, 2027	🟡 Security Only
PHP 8.2	Dec 8, 2022	Dec 8, 2024	Dec 31, 2026	🟡 Security Only
PHP 8.1	Nov 25, 2021	Nov 25, 2023	Dec 31, 2025	❌ EOL
PHP 8.0	Nov 26, 2020	Nov 26, 2022	Nov 26, 2023	❌ EOL
PHP 7.4	Nov 28, 2019	Nov 28, 2021	Nov 28, 2022	❌ EOL
PHP 7.3	Dec 6, 2018	Dec 6, 2020	Dec 6, 2021	❌ EOL
PHP 7.2	Nov 30, 2017	Nov 30, 2019	Nov 30, 2020	❌ EOL
PHP 7.1	Dec 1, 2016	Dec 1, 2018	Dec 1, 2019	❌ EOL
PHP 7.0	Dec 3, 2015	Dec 3, 2017	Dec 3, 2018	❌ EOL
PHP 5.6	Aug 28, 2014	Aug 28, 2016	Dec 31, 2018	❌ EOL

🚨 If you're running PHP 8.1 or below, your site is vulnerable. PHP 8.1 reached EOL December 31, 2025. PHP 7.x has been EOL since 2022 or earlier.

Understanding the PHP Support Lifecycle

Every PHP release (from PHP 8.1 onwards) follows a 4-year lifecycle:

Active Support (2 years): Regular bug fixes, performance improvements, and security patches
Security Support Only (2 years): Critical CVEs only — no bug fixes, no performance improvements
End of Life: Zero patches of any kind. Newly discovered vulnerabilities will never be fixed.

PHP 8.4 — Current Recommended Version

Released November 21, 2024. Key improvements:

Property hooks — getter/setter logic directly in class property declarations
Asymmetric visibility — public private(set) access modifiers
New array functions: array_find(), array_find_key(), array_any(), array_all()
HTML5 parser for the DOM extension (Dom\HTMLDocument)
Performance improvements over PHP 8.3

Active support ends: December 31, 2026

Security support ends (EOL): December 31, 2028

PHP 8.3 — Security Only

Released November 23, 2023. Entered security-only support November 23, 2025. EOL: December 31, 2027.

Introduced typed class constants, json_validate(), Randomizer::getBytesFromString(), and significant performance improvements. If you're on 8.3, plan your upgrade to 8.4 — it's a smooth, backward-compatible migration.

PHP 8.2 — Security Only, EOL December 2026

Released December 8, 2022. Entered security-only support December 8, 2024. EOL: December 31, 2026.

Is PHP 8.2 still supported? Yes — security patches only, until December 31, 2026. No bug fixes. Upgrade to PHP 8.4 before end of year 2026.

PHP 8.1 — End of Life (December 31, 2025)

PHP 8.1 introduced enums, fibers (coroutines), intersection types, readonly properties, and the never return type. Despite being a landmark release, it is now completely unsupported. Upgrade immediately.

PHP 8.0 — End of Life (November 26, 2023)

A landmark release that introduced JIT compilation, union types, named arguments, match expressions, and nullsafe operators. EOL since November 26, 2023.

PHP 7.4 — End of Life (November 28, 2022)

The last PHP 7.x release. EOL November 28, 2022 — nearly 4 years ago. Hundreds of CVEs have been discovered since that will never be patched. Many hosting providers have dropped PHP 7.4 entirely.

🚨 PHP 7.4 is dangerously outdated. If your application still runs on PHP 7.4, it is exposed to years of unpatched vulnerabilities. Upgrading to PHP 8.x is urgent.

PHP 7.3 — End of Life (December 6, 2021)

EOL for over 4 years. No reason to remain on PHP 7.3 — all features are available in PHP 8.x.

PHP 7.2 — End of Life (November 30, 2020)

EOL for over 5 years. Running it on any internet-connected system is critically dangerous.

PHP 8.5 — Released November 2025

Released November 20, 2025, following the annual release cadence. Active support to December 31, 2027. Security support to December 31, 2029. Migration from 8.4 to 8.5 is smooth.

How to Check Your PHP Version

php -v
# PHP 8.4.7 (cli) (built: Apr 15 2026)

<?php
echo phpversion();
// or
echo PHP_VERSION;

How to Upgrade PHP

Ubuntu/Debian

sudo add-apt-repository ppa:ondrej/php
sudo apt update
sudo apt install php8.4
sudo update-alternatives --set php /usr/bin/php8.4

RHEL / CentOS / AlmaLinux

sudo dnf module reset php
sudo dnf module enable php:8.4
sudo dnf install php

Managed Hosting

Look for "PHP Version Manager" or "MultiPHP Manager" in cPanel, or "PHP Settings" in Plesk.

PHP 8.4 Upgrade Notes

Watch for this deprecation in PHP 8.4: implicit nullable parameter types (e.g., function foo(Type $x = null)) are now deprecated. Fix by using explicit ?Type. Check your codebase before upgrading.

FAQ

Is PHP 8.2 still supported?
Security patches only, until December 31, 2026. No bug fixes. Upgrade to PHP 8.4.

When did PHP 7.4 reach end of life?
November 28, 2022. No patches — including security patches — since that date.

When is PHP 8.3 end of life?
Active support ended November 23, 2025. Security support until December 31, 2027.

When is PHP 8.4 end of life?
Active support ends December 31, 2026. Security support until December 31, 2028.

Does PHP have LTS versions?
No. All PHP releases (from PHP 8.1 onwards) follow the same 4-year (2 active + 2 security) lifecycle. No version gets special long-term treatment.

Live version data and version checker: endoflife.ai/php

RHEL End of Life Dates: Complete Red Hat Enterprise Linux Lifecycle Guide (2025–2035)

endoflife-ai — Thu, 28 May 2026 04:45:59 +0000

Knowing exactly when your RHEL version reaches end of life — and which minor release you need to be on — is critical for maintaining security compliance and support eligibility. This guide covers every active and recently retired RHEL major and minor release, end of life dates, lifecycle phases, and what your team should do before support ends.

Quick answer: RHEL 8 full support ended May 31, 2024 — RHEL 8.10 is the final minor release and stays in Maintenance Support until May 31, 2029. RHEL 9 full support runs until May 31, 2027, with maintenance to May 31, 2032. RHEL 10 (released May 20, 2025) full support runs until approximately May 2030.

RHEL Major Version Lifecycle Summary

RHEL Version	GA Release	Full Support Ends	Maintenance Support Ends	ELS	Status
RHEL 10	May 20, 2025	~May 2030	~May 2035	~2036+	✅ Active
RHEL 9	May 2022	May 31, 2027	May 31, 2032	~2033	✅ Active
RHEL 8	May 2019	May 31, 2024	May 31, 2029	~2031	🟡 Maintenance
RHEL 7	Jun 2014	Aug 6, 2019	Jun 30, 2024	Jun 30, 2026	❌ EOL
RHEL 6	Nov 2010	May 10, 2016	Nov 30, 2020	Jun 30, 2024	❌ EOL
RHEL 5	Mar 2007	Jan 31, 2013	Mar 31, 2017	Nov 30, 2020	❌ EOL

Understanding the RHEL Lifecycle Phases

Red Hat defines three main support phases:

Phase 1 – Full Support (Years 1–5)

Active platform development: new hardware enablement, new functionality, and full bug and security fix coverage. Minor releases (e.g., RHEL 9.1, 9.2) ship roughly every 6 months.

Phase 2 – Maintenance Support (Years 5–10)

Only the final minor release (e.g., RHEL 8.10) receives updates — limited to critical security advisories and urgent bug fixes. No new hardware support or feature development.

Phase 3 – Extended Life Cycle Support (ELS, Optional)

A paid add-on that extends security patch coverage 1–3 years beyond the 10-year lifecycle. Intended as a migration bridge, not a permanent solution.

⚠️ Important: During Maintenance Support, only the latest minor release receives patches. If you're on RHEL 8.9, you must upgrade to RHEL 8.10 to remain supported.

RHEL 9 Minor Version EOL Dates

RHEL 9 Minor	Release Date	End of Support	Status
RHEL 9.0	May 18, 2022	May 31, 2023	❌ EOL
RHEL 9.1	Nov 2022	May 31, 2023	❌ EOL
RHEL 9.2	May 2023	Nov 2023	❌ EOL
RHEL 9.3	Nov 2023	May 2024	❌ EOL
RHEL 9.4	Apr 2024	Nov 2024	❌ EOL
RHEL 9.5	Nov 2024	May 2025	❌ EOL
RHEL 9.6	May 2025	Nov 2025	✅ Current
RHEL 9.7 (expected)	~Nov 2025	~May 2026	Upcoming

RHEL 8 Minor Version EOL Dates

RHEL 8.10 is the final minor release of RHEL 8. All earlier 8.x versions are end of life.

RHEL 8 Minor	Release Date	End of Support	Status
RHEL 8.0	May 2019	Nov 2019	❌ EOL
RHEL 8.1	Nov 2019	Nov 2021	❌ EOL
RHEL 8.2	Apr 2020	Apr 2022	❌ EOL
RHEL 8.3	Nov 2020	May 2021	❌ EOL
RHEL 8.4	May 2021	May 2023	❌ EOL
RHEL 8.5	Nov 2021	May 2022	❌ EOL
RHEL 8.6	May 2022	May 2024	❌ EOL
RHEL 8.7	Nov 2022	May 2023	❌ EOL
RHEL 8.8	May 2023	May 2024	❌ EOL
RHEL 8.9	Nov 2023	May 2024	❌ EOL
RHEL 8.10	May 2024	May 31, 2029	🟡 Maintenance

RHEL 10 — Current Recommended Release

RHEL 10 (released May 20, 2025) is Red Hat's latest major release and the recommended target for new deployments and for teams migrating from RHEL 8. It follows the standard 10-year lifecycle: full support until ~May 2030, maintenance until ~May 2035.

RHEL 7 — Fully End of Life

RHEL 7 reached the end of Extended Life Cycle Support on June 30, 2026. Any system running RHEL 7 is now completely unsupported. Migrate to RHEL 9 or RHEL 10 immediately.

How to Check Your RHEL Version

cat /etc/redhat-release
# Red Hat Enterprise Linux release 9.6 (Plow)

cat /etc/os-release

What to Do When Your RHEL Version Is Approaching EOL

Upgrade to the latest minor release within the same major version via dnf update
Migrate to the next major version using Red Hat's Leapp in-place upgrade tool
Purchase Extended Life Cycle Support (ELS) as a short-term migration bridge only

FAQ

When is RHEL 8 end of life?
RHEL 8 full support ended May 31, 2024. RHEL 8.10 (final minor) is in Maintenance Support until May 31, 2029.

When is RHEL 9 end of life?
RHEL 9 full support ends May 31, 2027. Maintenance Support extends to May 31, 2032.

Is RHEL 8.10 the last RHEL 8 release?
Yes. RHEL 8.10, released May 2024, is the final minor release of RHEL 8.

What is RHEL ELS?
ELS is a paid add-on extending security patch coverage beyond the standard 10-year lifecycle for 1–3 additional years. It's a bridge, not a long-term solution.

Live version data and version checker: endoflife.ai/rhel

Debian 12 Bookworm EOL is June 10, 2026 — Your 18-Day Action Checklist

endoflife-ai — Sat, 23 May 2026 17:06:05 +0000

Debian 12 "Bookworm" regular security support ends June 10, 2026 — 18 days away.

Most teams know the date. Fewer know what actually changes on that date, or have done anything about it yet. This is the practical breakdown.

What actually changes on June 10

The Debian Security Team stops issuing patches. This is the team behind security.debian.org — the one that responds to CVEs within days and covers the full package archive.

What takes over: the Debian LTS Team — a separate group of volunteers — maintains approximately 230 packages on a best-effort basis until June 2028. Slower cadence, narrower scope.

The security.debian.org repository keeps working. But the team behind it changes, and so does what gets patched.

The three support phases (most people only know one)

Phase	Dates	Maintained by
Regular support	Jun 2023 – Jun 10, 2026	Debian Security Team
LTS	Jun 10, 2026 – Jun 30, 2028	Debian LTS Team (volunteers)
ELTS	2028 – Jun 2033	Freexian (paid)

Current upgrade target: Debian 13 "Trixie" — stable since August 2025, supported through 2028+.

The compound June 2026 timing

Two deadlines in the same 20-day window:

June 10 — Debian 12 regular support ends
June 30 — Debian 11 (Bullseye) LTS ends

If you're running both versions across different systems, you're facing a double migration in June. Plan accordingly.

The part developers miss: Docker base images

debian:12 and debian:bookworm are among the most common Docker base images in production. After June 10, every container you build on them has an EOL OS layer that will never receive another Debian Security Team patch — regardless of how current your application code is.

The fix is one line:

# Before
FROM debian:12

# After  
FROM debian:13

Rebuild. Run your tests. For most standard application containers this is a drop-in change.

Also check: official application images like python:3.12, node:22, php:8.3 — if you're using non-alpine variants, verify which Debian version they currently build on. Some maintainers are slower to update base images than others.

If you can't upgrade by June 10

You don't have to panic. Debian LTS activates automatically after June 10 — no configuration change required. For standard server stacks (kernel, glibc, OpenSSL, nginx, Apache, PHP, Python) LTS coverage is likely adequate as a 3–6 month bridge while you plan the Debian 13 upgrade.

What you must do:

Verify your critical packages are in the Debian LTS scope
Document the transition in your risk register — compliance teams will ask
Set a hard target date for Debian 13 — don't treat LTS as permanent

The upgrade in 4 steps

# 1. Bring Debian 12 fully current first
apt update && apt upgrade && apt full-upgrade

# 2. Update sources.list — replace bookworm with trixie
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
# Also update any files in /etc/apt/sources.list.d/

# 3. Run the upgrade
apt update && apt full-upgrade

# 4. Reboot and verify
reboot
lsb_release -a

Use full-upgrade not upgrade — it handles package removals and replacements that occur during a major version transition.

Note: Debian 13 dropped i386 support. If you have 32-bit x86 systems or packages, check the Debian 13 release notes before upgrading.

Compliance implications

If your systems are in scope for a compliance framework, the June 10 transition needs to be documented before it happens — not discovered in an audit.

PCI DSS — requires vendor-supported software. Clarify with your QSA whether Debian LTS satisfies your requirements before June 10.
SOC 2 Type II — CC7.1 requires patch management. CVEs against packages outside LTS scope remain permanently open after June 10. Document your gap management.
ISO 27001 — Annex A.12.6.1 flags EOL systems. LTS must be documented as a managed compensating control.
FedRAMP — EOL OS in a FedRAMP boundary is a showstopper. Upgrade or obtain approved extended support before your assessment window.

Your checklist before June 10

[ ] Inventory every Debian 12 system — servers, VMs, containers, CI runners, build images
[ ] Audit Dockerfiles for debian:12 or debian:bookworm base images — update to debian:13
[ ] Update IaC templates (Terraform, Packer, Ansible) hard-coding Debian 12 image IDs
[ ] Verify LTS package coverage for systems you can't upgrade immediately
[ ] Document the support tier change in your risk register
[ ] Test the Debian 13 upgrade in a non-production environment first
[ ] Brief compliance and security teams — June 10 should be a calendar event
[ ] Set a 30-day post-June 10 review reminder to check for accumulating unpatched CVEs

EOL Risk Scores

Using the EOL Risk Score™ methodology — which weighs EOL recency, attack surface, CISA KEV exposure, and extended support availability:

Version	Score	Status
Debian 10 (Buster)	86 / Critical	Fully EOL since Jun 2024
Debian 11 (Bullseye)	64 / High	LTS ending Jun 30, 2026
Debian 12 (Bookworm)	55 / High	Regular EOL Jun 10, 2026
Debian 13 (Trixie)	12 / Low	Current stable

Debian 12's score rises after June 10 as the regular support phase closes. You can check live scores for every Debian version — and every product in your stack — at endoflife.ai.

EOL dates sourced from endoflife.date (MIT) and debian.org. Full Debian lifecycle guide with migration steps at endoflife.ai/article-debian-eol.html.

Why Your EOL Risk Score Is the Most Important Number in Your Security Stack

endoflife-ai — Sat, 23 May 2026 09:59:37 +0000

Your stack has a risk score. You just haven't been measuring it.

Every piece of software running in your production environment has an end-of-life date. The moment that date passes, the vendor stops issuing security patches. CVEs keep getting discovered. Exploits keep getting developed. Your software stops getting fixed.

That's not a hypothetical. That's a scheduled event — and it's on a calendar you can look up right now.

The EOL Risk Score™ puts a 0–100 number on that risk for every product and version tracked on endoflife.ai. This article explains what it measures, why each factor matters, how it maps directly to SOC 2, ISO 27001, and PCI DSS compliance requirements, and what the documented consequences look like for organizations that ignore it.

What the EOL Risk Score Actually Measures

The EOL Risk Score™ is a 0–100 composite score calculated for every product and version tracked on endoflife.ai. It is not a CVSS score. It answers a different question: not "how severe is this specific vulnerability" but "how much accumulated, unresolvable risk is this software carrying right now?"

Four factors combine into the final score:

Factor	Max Points	What It Measures
EOL Recency	40	How long since the version hit end of life
Attack Surface	30	How broadly deployed and exposed the software is
CISA KEV Exposure	20	Whether known exploited vulnerabilities exist
Extended Support	10	Whether paid extended support is available

Score bands:

76–100: 🔴 Critical
51–75: 🟠 High
26–50: 🟡 Medium
0–25: 🟢 Low

A score of 0 doesn't mean safe. It means low risk right now. Every supported version is accumulating risk on a known, published timeline. Node.js 22 scores 50 Medium today. On April 30, 2027 — with no change to your infrastructure — it becomes 90 Critical. The date is already on the calendar.

Why Each Factor Was Chosen

EOL Recency — 40 points

The heaviest factor, deliberately. The longer software has been past its end-of-life date, the more CVEs have been disclosed with no patch path. PHP 7.4 hit EOL in November 2022. By May 2026 that's 42 months of unpatched vulnerability accumulation. Every CVE discovered against PHP 7.4 since November 2022 will never receive an official fix. Not delayed — never.

The recency score scales with time past EOL. Attackers track EOL dates. Once a product hits end of life, the research community continues finding vulnerabilities but the vendor stops fixing them. The asymmetry grows with time.

Attack Surface — 30 points

Not all EOL software carries the same exposure. A niche internal tool on an air-gapped system carries different risk than a web-facing runtime handling public traffic.

Node.js, PHP, Python, Apache, nginx — these score 30/30 because they are the foundation of internet-facing infrastructure at scale. Same EOL date, wildly different real-world exposure.

CISA KEV Exposure — 20 points

The Cybersecurity and Infrastructure Security Agency maintains the Known Exploited Vulnerabilities catalog — CVEs that have been actively exploited in the wild. Not theoretically vulnerable. Actively exploited, right now, in documented incidents.

If a product has CISA KEV entries and no patch path, attackers have already demonstrated they know how to exploit it.

Extended Support Availability — 10 points

Running past EOL doesn't have to mean running without patches. Vendors like TuxCare provide extended lifecycle support for Linux distributions and other products. If migration isn't yet possible, a mitigation can exist.

This factor also helps compliance teams document a compensating control — "we are running past EOL but under a paid extended support contract" is a defensible position with auditors. "We are running past EOL with no patches and no plan" is not.

Real Score Examples

Product	EOL Date	Score	Band
PHP 7.4	Nov 2022	90	🔴 Critical
Python 3.8	Oct 2024	88	🔴 Critical
Node.js 18	Apr 2025	85	🔴 Critical
Ubuntu 20.04	Apr 2025	85	🔴 Critical
Spring Framework 5.3	Aug 2024	82	🔴 Critical
Node.js 22	Apr 2027	50	🟡 Medium
Go 1.24	Feb 2027	20	🟢 Low

The difference between PHP 7.4 at 90 and Go 1.24 at 20 isn't just the EOL date. It's the combination of how long it's been unsupported, how exposed it is, and whether active exploits exist in documented incidents.

The Stack Risk Problem Nobody Talks About

Your stack's risk level is set by your weakest component, not your strongest.

A team running Node.js 22 (Score: 50 Medium) on Ubuntu 20.04 (Score: 85 Critical) isn't a Medium-risk environment. They're a Critical-risk environment that happens to have a current application runtime. The OS is the foundation. If it's compromised, nothing above it matters.

The same applies throughout the stack:

A current framework running on an EOL language runtime
A patched application running on an EOL database
A modern containerized workload built on an EOL base image
A secure application deployed behind an EOL web server

The score that matters is the highest one — because that's the one your attacker will find first.

How EOL Risk Maps to Compliance Frameworks

EOL software isn't just a technical problem. It is a documented control failure in every major security framework.

SOC 2 — CC7.1 Vulnerability Management

SOC 2's mandatory Security criterion includes CC7.1, requiring organizations to detect and monitor for vulnerabilities. Running EOL software with no patch path is a vulnerability that cannot be remediated without migration or extended support.

Auditors will review your patch management program. "We are running PHP 7.4" is not a response that satisfies CC7.1 without a documented exception and remediation plan. Enough findings and your SOC 2 report comes back qualified.

Practical consequence: Enterprise procurement treats a qualified SOC 2 opinion like a failed credit check. You lose the deal.

ISO 27001 — Annex A.12.6.1 Technical Vulnerability Management

ISO 27001 Annex A control A.12.6.1 explicitly requires organizations to identify technical vulnerabilities, evaluate exposure, and take appropriate action. Running software past its vendor-published end-of-life date with no compensating control is a textbook nonconformity.

A nonconformity found during a surveillance audit can result in suspension of your certificate.

Practical consequence: Many enterprise contracts require maintaining ISO 27001 certification. A lapsed certificate can trigger breach of contract clauses.

PCI DSS — Requirement 6.3.3 Security Patch Management

PCI DSS is mandated by the card brands for any organization handling cardholder data. Requirement 6.3.3 requires all system components to be protected against known vulnerabilities by installing applicable security patches.

EOL software that is no longer receiving patches has no applicable security patches to install. It is a permanent, unresolvable violation until the software is replaced or covered by a paid extended support agreement.

Practical consequence: Fines of $5,000–$100,000 per month until compliant. Loss of ability to process card payments. Mandatory forensic investigation costs ($50,000–$200,000+) if a breach occurs while non-compliant.

Real-World Consequences — What Actually Happened

Equifax, 2017 — 147 Million Records Exposed

Root cause: Apache Struts CVE-2017-5638. The patch had been available for two months. It was never applied.

The breach ran undetected for 78 days. Total costs: $1.38 billion. FTC settlement: $575 million. The CEO, CIO, and CSO all resigned.

The vulnerability was known. The patch existed. The software was running unpatched in a public-facing system. EOL software takes this failure mode and makes it permanent — there is no patch to apply. Ever.

MOVEit Transfer, 2023 — 2,000+ Organizations Breached

A zero-day SQL injection in Progress Software's MOVEit Transfer, exploited by the Cl0p ransomware group in a coordinated global campaign. Over 2,000 organizations confirmed affected including Shell, British Airways, the BBC, and the US Department of Energy. Organizations running older unpatched versions had no remediation path.

Log4Shell, 2021 — CVSS 10.0, Exploited Within Hours

CVE-2021-44228 in Apache Log4j. CVSS score: 10.0. Actively exploited within hours of public disclosure. Organizations running EOL Java versions that could not apply the patch were fully exposed with no remediation path. Many didn't even know they were running Log4j — it was embedded in vendor products.

The pattern is the same every time. Known software. Known vulnerability. No patch applied. EOL software removes "apply the patch" from your options permanently.

Cyber Insurance — The Consequence Most Teams Miss

Underwriters now ask detailed questions about your technology stack:

"Are any components of your production environment running past vendor end-of-life?"
"What is your process for identifying end-of-life software?"
"Do you have documented exceptions for any end-of-life software in production?"

Some policies now include explicit exclusions for breaches originating from software that was past vendor end-of-life at the time of the incident.

IBM's Cost of a Data Breach Report puts the average breach at $4.45 million USD. A $4.45 million breach with voided coverage because you were running PHP 7.4 is a very different conversation than one with a $4 million policy.

The EOL Risk Score is the number your underwriter is going to ask about. Know it before they do.

The Planning Framework

Score	Band	Action
0–25	🟢 Low	Plan — document your migration path before you need it
26–50	🟡 Medium	Prepare — migration plan becomes a migration project, assign an owner
51–75	🟠 High	Act — investigate extended support, document formally with a hard remediation date
76–100	🔴 Critical	Escalate — board-level risk item, obtain extended support or migrate immediately

Check Your Stack Right Now

Every product and version on endoflife.ai has an EOL Risk Score. Free, no signup.

Full stack scanner: endoflife.ai/scanner.html
Individual scores: endoflife.ai/score/nodejs/18
Score methodology: endoflife.ai/risk-score.html
455+ products tracked: endoflife.ai/products.html

If you find a Critical score in your stack today, you have options. If you find it during an audit or after a breach, your options narrow considerably.

Attackers track EOL dates too. The moment a version hits end of life, it becomes a permanently open target. The CVEs will keep coming. The patches will not.

Know your number.

EOL Risk Score™ is a proprietary methodology developed by endoflife.ai. This article is for informational purposes and does not constitute legal or compliance advice.

Node.js 22 LTS — EOL Date, Support Timeline, and What Comes Next

endoflife-ai — Sat, 23 May 2026 04:21:31 +0000

Node.js 22 became Active LTS in October 2024. That sounds recent. It isn't.

Active LTS means the clock is already running. Node.js 22 reaches End of Life on April 30, 2027 — less than two years from now. And if the pattern from Node 16, 18, and 20 holds, a significant chunk of production environments will still be running it six months after that date.

This article covers the full Node.js 22 support timeline, how it fits into the broader release schedule, what the EOL Risk Score looks like today versus in 2027, and what your team should be planning now.

The Node.js 22 LTS Timeline

Phase	Start	End
Current (odd release)	April 2024	October 2024
Active LTS	October 2024	October 2026
Maintenance LTS	October 2026	April 30, 2027
End of Life	April 30, 2027	—

Node.js follows a predictable release cadence: even-numbered versions become LTS, odd-numbered versions don't. Node.js 22 is even, so it gets the full LTS treatment — Active LTS for two years, then Maintenance for six months, then EOL.

The Maintenance phase is the one most teams miss. After October 2026, Node.js 22 only receives critical bug fixes and security patches — no new features, no non-critical fixes. If you're still on Node 22 in early 2027, you're already in a degraded support window before you even hit EOL.

Where Node.js 22 Fits in the Full Release Schedule

Here's the full picture as of May 2026:

Version	Status	EOL Date	EOL Risk Score
Node.js 14	EOL	April 30, 2023	95 Critical
Node.js 16	EOL	September 11, 2023	90 Critical
Node.js 18	EOL	April 30, 2025	85 Critical
Node.js 20	EOL	April 30, 2026	76 Critical
Node.js 22	Active LTS	April 30, 2027	50 Medium
Node.js 24	Current	April 30, 2028	30 Low

Node.js 20 just hit EOL on April 30, 2026 — less than a month ago. If your team is running Node 20 in production today, you're already in the same position teams were in with Node 18 a year ago.

Node.js 22's current EOL Risk Score is 50 Medium — it's supported, but the attack surface score (30/30) is already baked in because Node.js is a high-exposure runtime regardless of support status. That score climbs to Critical the moment it hits EOL in April 2027.

What the Score Looks Like Today vs. April 2027

The EOL Risk Score™ on endoflife.ai breaks down like this for Node.js 22 today:

Factor	Score	Max	Notes
EOL Recency	0	40	Currently supported — zero penalty
Attack Surface	30	30	High-exposure runtime, always maxed
CISA KEV Exposure	20	20	Node ecosystem has known exploited vulns
Extended Support	0	10	No extended support available yet
Total	50	100	Medium

The day Node.js 22 hits EOL on April 30, 2027, the Recency score jumps from 0 to 40. Total score: 90 Critical. Nothing about your infrastructure changes — just the date.

That's the EOL cliff. Teams that plan migrations 6-12 months in advance avoid it. Teams that don't end up running Critical-rated software in production while scrambling to upgrade.

The Pattern: What History Tells Us

Node.js 18 hit EOL on April 30, 2025. Based on download and deployment data, a significant portion of Node.js production workloads were still on Node 18 six months later. The same pattern played out with Node 16 and Node 14 before it.

Why does this keep happening?

Upgrade friction is real. Dependency trees, native modules, and CI/CD pipeline compatibility all need testing.
EOL dates feel abstract. April 2027 sounds far away in May 2026.
Prioritization is hard. "It still works" wins most sprint planning arguments.

The teams that handle this well aren't faster — they just start earlier. If you're reading this in May 2026, you have 23 months before Node 22 EOL. That's comfortable. If you're reading this in January 2027, you have 3 months. That's a fire drill.

Node.js 22 Key Features Worth Knowing

Before you start planning the migration to Node 24, know what you're on:

V8 12.4 — improved performance, better WebAssembly support
Native test runner stabilized — node:test is production-ready
require() for ES modules — experimental but significant for ecosystem compatibility
WebSocket client — built-in, no ws dependency needed for basic use cases
Maglev compiler — faster startup times, better JIT performance

Node.js 22 is a genuinely good release. That's exactly why it'll still be running in production in 2028 at companies that didn't plan ahead.

What to Do Now

If you're on Node 18 or 20: You're already past EOL or just hit it. This is urgent. Check your EOL Risk Score at endoflife.ai/nodejs/18 or endoflife.ai/nodejs/20.

If you're on Node 22: You have runway. Use it. Schedule the Node 24 migration for Q1 2027 at the latest — that gives you a 3-month buffer before EOL and keeps you out of the Maintenance-only window.

If you're on Node 24: You're current. Node 24 EOL is April 2028. Check back in 18 months.

Scan your full stack: Node version is one data point. The underlying OS, runtime dependencies, and framework versions all have their own EOL dates. Use the Stack Scanner at endoflife.ai to get the full picture.

Check Your Node.js Version Score

Every Node.js version has a dedicated score card on endoflife.ai:

endoflife.ai/nodejs/22 — Active LTS, Score 50 Medium
endoflife.ai/nodejs/20 — EOL Apr 2026, Score 76 Critical
endoflife.ai/nodejs/18 — EOL Apr 2025, Score 85 Critical
endoflife.ai/nodejs — Full Node.js EOL schedule

EOL Risk Score™ is a proprietary methodology developed by endoflife.ai. Scores are calculated at build time from four factors: EOL Recency, Attack Surface, CISA KEV Exposure, and Extended Support Availability.

Part of The EOL Intelligence Report series on DEV.to.

Hardware End-of-Support-Life (EOSL) — The EOL Risk Nobody Tracks

endoflife-ai — Wed, 20 May 2026 20:20:56 +0000

Everyone talks about software EOL. Nobody talks about hardware EOSL.

End-of-Support-Life (EOSL) hardware creates exactly the same security exposure as EOL software — firmware vulnerabilities that will never be patched, CVEs that accumulate without remediation, and compliance findings that auditors increasingly flag. But unlike software EOL, hardware EOSL almost never shows up in a vulnerability scanner.

What EOSL Means for Hardware

When a hardware vendor declares a product End-of-Support-Life (sometimes called End-of-Service-Life or End-of-Sale), they stop:

Issuing firmware updates and security patches
Providing technical support
Selling replacement parts
Publishing security advisories

The firmware on your EOSL hardware is permanently frozen at whatever version it was at when support ended. Any CVEs discovered after that date — and there will be CVEs — have no patch path.

The Categories Most at Risk

Network Infrastructure

Routers, switches, firewalls, and load balancers are the highest-risk EOSL hardware category. They run continuously, face the internet directly, and contain embedded operating systems with their own CVE exposure.

Cisco IOS versions, Juniper firmware, Fortinet FortiOS — all have their own lifecycle dates. A switch running IOS 12.x is carrying vulnerabilities that Cisco stopped patching years ago, but it shows up in most network scans as "network device," not as "EOL software with unpatched CVEs."

Server Hardware

Physical servers from major vendors (Dell PowerEdge, HPE ProLiant, Lenovo ThinkSystem) have EOSL dates that affect:

iDRAC/iLO/IMM firmware (out-of-band management — high-value attack target)
BIOS/UEFI firmware
NIC, RAID controller, and storage adapter firmware
Vendor management software agents

EOSL server hardware in a datacenter or colo may still run perfectly well — but its management firmware is accumulating unpatched CVEs indefinitely.

Storage Systems

SAN arrays, NAS devices, and object storage appliances have complex firmware stacks. EOSL storage hardware often remains in production long after support ends because storage migrations are expensive and disruptive. The firmware running your storage fabric may be years past end of support.

Security Appliances

This is the highest-risk category. Hardware security appliances — next-gen firewalls, IDS/IPS systems, SSL inspection appliances — are explicitly security infrastructure. Running EOSL security hardware is a compounding risk: the device meant to protect your environment has its own unpatched vulnerabilities.

How EOSL Hardware Creates Compliance Findings

Most compliance frameworks have evolved to address hardware lifecycle, not just software:

PCI DSS 4.0 — Requirement 6.3 covers all system components, which includes hardware. A EOSL network device in the cardholder data environment requires the same Targeted Risk Analysis as EOL software.

NIST SP 800-53 — SA-22 (Unsupported System Components) explicitly covers hardware that has reached end-of-support. FedRAMP inherits this requirement.

SOC 2 — CC6.1 covers the use of security-enhanced configurations for all infrastructure components. EOSL hardware with unpatched firmware fails this control.

ISO 27001:2022 — Annex A 8.8 (Management of technical vulnerabilities) applies to hardware firmware as well as software.

Why Scanners Don't Catch It

Vulnerability scanners look for CVEs in running software. They fingerprint operating systems, detect software versions, and match against CVE databases. They don't typically:

Query hardware asset management systems for EOSL status
Check firmware versions against vendor lifecycle databases
Flag network devices as "end of support" even when they are

This is the same CVE blind spot that affects EOL software, amplified by the fact that hardware asset management is often maintained in a separate system (or a spreadsheet) that never gets cross-referenced against vendor lifecycle data.

What to Do

01 — Build a hardware inventory with firmware versions
Your network team knows your switch and router models. Your systems team knows your server hardware. Your storage team knows your SAN. Combine these into a single inventory with current firmware versions.

02 — Cross-reference against vendor EOSL announcements
Every major hardware vendor publishes EOSL dates. Cisco publishes EOL notices on their website. Dell, HPE, Lenovo, Palo Alto, Fortinet, Juniper all have lifecycle pages. Check each hardware model and firmware version against the vendor's current lifecycle table.

03 — Prioritize by attack surface
Not all EOSL hardware is equal risk. Rank by:

Internet-facing vs internal
Management plane exposure (iDRAC/iLO accessible from where?)
Vendor CVE history for that product family
Regulatory scope (is it in your CDE, healthcare network, or federal environment?)

04 — Document compensating controls for hardware you can't replace immediately
Hardware replacement cycles are 3–7 years. You can't always replace EOSL hardware immediately. Document: what the hardware is, its EOSL date, its current firmware version, what compensating controls are in place (network segmentation, monitoring, access controls), and a replacement timeline.

05 — Include hardware in your EOL monitoring program
The same discipline you apply to software EOL tracking should apply to hardware. Set calendar reminders for hardware EOSL dates. Include hardware in your quarterly security reviews.

The Bottom Line

EOSL hardware is the EOL risk nobody tracks until an auditor finds it or a breach investigator traces a compromise back to an unpatched firmware CVE.

The pattern is identical to software EOL: known vulnerabilities, no patch path, accumulating exposure. The only difference is that software EOL has gotten attention, and hardware EOSL largely hasn't.

Check your software stack for EOL exposure at endoflife.ai — and use what you learn there as a template for building the same discipline around your hardware inventory.

The Complete EOL Calendar for 2026 — Every Major Software End-of-Life Date

endoflife-ai — Wed, 20 May 2026 20:20:09 +0000

2026 is one of the most significant years for software end-of-life in recent memory. Multiple major LTS releases, widely-deployed operating systems, and enterprise-grade frameworks are all reaching the end of their support windows this year.

This is your complete reference — every major EOL event in 2026, organized by month.

Why 2026 Is a Critical Year

The 2021–2022 wave of LTS releases — Ubuntu 20.04, MariaDB 10.6, Django 4.2 — are all hitting their 5-year windows in 2025–2026. Organizations that chose LTS versions for stability are now facing simultaneous migration pressure across their entire stack.

The EOL Risk Score™ for any component scoring 76+ (Critical) means immediate action is warranted. Check any version at endoflife.ai.

Q1 2026 — January to March

January 13, 2026

Kubernetes 1.31 — EOL. Upgrade to K8s 1.35 or 1.36.

February 28, 2026

Kubernetes 1.32 — EOL. Skip 1.33 (EOL June 2026) and go straight to 1.35+.

Q2 2026 — April to June

April 7, 2026

Django 4.2 LTS — EOL. The most widely deployed Django LTS version. Upgrade to Django 5.2 LTS. EOL Risk Score™: 76 Critical.

April 30, 2026

Node.js 20 — EOL. Upgrade to Node.js 22 LTS. EOL Risk Score™: 72 Critical.

June 10, 2026

Debian 12 (Bookworm) — Regular support ends. Transitions to LTS. Package coverage narrows.

June 28, 2026

Kubernetes 1.33 — EOL. Upgrade to K8s 1.35 or 1.36.

June 30, 2026

Debian 11 (Bullseye) — LTS ends. All community patches stop. Only ELTS (paid) remains.
MariaDB 10.6 LTS — EOL. Upgrade to MariaDB 10.11 or 11.4 LTS. EOL Risk Score™: 58 High → will climb rapidly.

Q3 2026 — July to September

July 2026 (estimated)

PHP 8.1 — Security support ends. Upgrade to PHP 8.3 or 8.4. EOL Risk Score™ will reach Critical.

September 2026

Python 3.10 — EOL. Upgrade to Python 3.12 or 3.13. EOL Risk Score™: High.

Q4 2026 — October to December

October 2026

Kubernetes 1.34 — EOL. Stay current with K8s 1.36+.

November 2026

Ruby 3.1 — EOL. Upgrade to Ruby 3.3 or 3.4.

December 2026

PHP 8.2 — Security support ends. Upgrade to PHP 8.3 or 8.4.

Already EOL — Action Required Now

These reached EOL before 2026 but are still widely running in production:

Product	EOL Date	EOL Risk Score™	Action
PHP 7.4	Nov 2022	90 Critical	Upgrade to PHP 8.3+ immediately
Python 3.8	Oct 2024	88 Critical	Upgrade to Python 3.12+
Node.js 18	Apr 2025	85 Critical	Upgrade to Node.js 22 LTS
Spring 5.3	Dec 2024	82 Critical	Upgrade to Spring 6.x
Ubuntu 20.04	Apr 2025	80 Critical	Upgrade to Ubuntu 24.04 LTS
RHEL 7	Jun 2024	88 Critical	Upgrade to RHEL 9 or 10
Debian 10	Jun 2024	86 Critical	Upgrade to Debian 13
Node.js 16	Sep 2023	91 Critical	Upgrade to Node.js 22 LTS

How to Stay Ahead of EOL Events

Use the endoflife.ai API to query upcoming EOL dates programmatically and build automated alerts into your CI/CD pipeline or ITSM system.

Set 90-day and 180-day lead time reminders for every EOL date in this calendar. 90 days is the minimum time to plan and execute most migrations. 180 days is realistic for complex environments.

Document everything. For compliance frameworks (SOC 2, PCI DSS, HIPAA), an EOL date in your inventory without a migration plan is a finding. An EOL date with a documented plan and compensating controls is a managed risk.

Track all of these at endoflife.ai — free EOL checker, stack scanner, and EOL Risk Score™ for 455+ products. No signup required.

Your EOL Dependencies Are a Compliance Problem — Not Just Tech Debt

endoflife-ai — Wed, 20 May 2026 20:19:04 +0000

Most developers know about EOL software the way they know about eating vegetables. Sure, you should stay current. But the real reason to act isn't hygiene — it's that EOL software creates compliance findings your company can't easily explain away.

If your company is pursuing SOC 2 Type II, renewing a PCI DSS certification, or handling healthcare data under HIPAA, an auditor is going to inventory your software stack. When they find components that are past vendor end-of-life — and they will, because most stacks have at least one — the question becomes: does this team know about it, and are they managing it?

The answer "we know, here's our plan" is manageable. The answer "we weren't aware" is a finding.

What Auditors Actually Look For

Security auditors doing SOC 2 or PCI reviews don't just run a vulnerability scanner and read the output. They ask for your software inventory. They cross-reference versions against published EOL dates. They check whether you have a process for tracking this over time.

Under SOC 2's Trust Services Criteria, the relevant control is CC7.1 — your ability to detect threats to system components. If you're running Node.js 16 (EOL September 2023) and you don't have a documented reason why and a plan to migrate, that's a gap in CC7.1.

Under PCI DSS 4.0, Requirement 6.3.3 mandates that all components have applicable security patches installed. For EOL software, there are no patches. That means you need a Targeted Risk Analysis — a formal document explaining the risk, your compensating controls, and your remediation timeline.

The thing that surprises most developers: Compliance auditors aren't primarily looking for exploited vulnerabilities. They're looking for evidence that you know your risks and are managing them deliberately. A known EOL component with a documented upgrade plan is manageable. An unknown EOL component is a red flag about your security program overall.

What's Likely EOL in Your Stack Right Now

Product	EOL Date	EOL Risk Score™
Node.js 16	Sep 11, 2023	91 Critical
PHP 7.4	Nov 28, 2022	90 Critical
Python 3.8	Oct 7, 2024	88 Critical
Node.js 18	Apr 30, 2025	85 Critical
Spring 5.3	Dec 31, 2024	82 Critical
Ubuntu 20.04	Apr 2025	80 Critical

Don't know what's running? The endoflife.ai Stack Scanner will give you a read in minutes.

Why Compliance Risk Is Different from CVE Risk

Most developers think about EOL software as a CVE problem. "We'll upgrade when there's a critical vulnerability." That logic doesn't hold for compliance.

A CVE has a specific ID, a CVSS score, and a patch. An auditor can see your scanner output, confirm the patch was applied, and move on. EOL software doesn't work that way. When a component goes EOL, future vulnerabilities will never have patches. The risk is structural, not specific.

A CVSS 9.8 vulnerability that was patched last Tuesday is better, from a compliance perspective, than a component that's been EOL for 18 months with no reported CVEs. Because the EOL component is a process failure. It says something about whether your team is tracking software lifecycle at all.

The CISA KEV connection: When a vulnerability in EOL software gets exploited in the wild, it enters the KEV catalog — and you have no vendor patch, only replacement. FedRAMP's SA-22 control and NIST SP 800-53 both now reference unsupported software explicitly.

How to Make the Case to Your Boss

If you need budget or sprint time to fix EOL dependencies, the compliance angle is your best leverage. "We should upgrade because it's best practice" loses to "we have a new feature to ship." "We need to upgrade before our SOC 2 renewal" doesn't.

Here's the script:

"We're running [Node 18 / Python 3.8 / PHP 7.4] in production. These hit end-of-life in the last 12 months — no more security patches from the vendor. When we go through our SOC 2 renewal / PCI audit / [upcoming audit], the auditor will flag these as findings unless we have a documented upgrade plan or compensating controls. The migration to [Node 22 / Python 3.12 / PHP 8.3] is a [X sprint] project. A compliance finding causes more delay and creates customer-facing risk. I'd like to schedule the migration before [audit date]."

Name the specific versions. Name the audit. Estimate the migration cost. Contrast it with the audit-finding cost.

Practical Steps

01 — Run an EOL audit of your stack
Run node --version, python --version, php --version on your production servers. Check those versions at endoflife.ai/checker.html.

02 — Check EOL dates 12 months out, not just today
Your audit isn't today. The endoflife.ai API lets you query upcoming EOL dates programmatically so you can build this into your CI pipeline.

03 — For components you can't upgrade immediately, document a compensating control
Under PCI DSS 4.0, this is the Targeted Risk Analysis. It should include: what the component is, why it's EOL, what the migration blockers are, what compensating controls you have in place, and a defined remediation timeline.

04 — Build EOL tracking into your SDLC
Treat an upcoming EOL event the same way you'd treat a deprecation warning in your build output — something that needs a ticket before it becomes urgent.

05 — Know your options when you can't upgrade
For Linux OS EOL (Ubuntu, CentOS, RHEL, Debian), commercial extended support vendors like TuxCare provide security patches past vendor EOL. This can satisfy auditor requirements for compensating controls while a migration is underway.

EOL dependencies aren't just tech debt. When your company is going through compliance audits, they become findings. The tooling to know is free. The plan doesn't have to be elaborate.

Check your stack at endoflife.ai — free, no signup required.

Hidden Compliance Risks from Unsupported Software — What Auditors Find First

endoflife-ai — Wed, 20 May 2026 20:18:17 +0000

Most compliance failures are not discovered in production. They're discovered in audit prep — when someone finally looks at what's actually running.

Software end-of-life is not a maintenance footnote. It is a compliance trigger. Across every major security framework — SOC 2, PCI DSS, HIPAA, ISO 27001, and FedRAMP — running unsupported software creates a direct path to audit findings, control failures, and in regulated industries, material legal exposure.

The Problem Auditors See First

When a qualified security auditor reviews your environment, one of their first requests is a software inventory with version data. Not to be thorough. To check one specific thing: whether you know what you're running, and whether what you're running is still receiving security patches.

If you can't produce that inventory cleanly, you've already failed a control — before they've found a single vulnerability.

What "end-of-life" means legally: When a vendor stops issuing security patches, they've publicly documented that known vulnerabilities will not be fixed. Running that software means you have acknowledged, documented risk with no remediation path from the vendor. Auditors treat this differently from unknown risk. You knew. You chose to run it anyway.

How Each Framework Treats EOL Software

PCI DSS 4.0

Requirement 6.3.3 mandates that all system components are protected from known vulnerabilities by installing applicable security patches. The most consequential change in PCI DSS 4.0 is Requirement 12.3.2: the Targeted Risk Analysis, which must now formally document any deviation — including running EOL software in the cardholder data environment.

Running PHP 7.4, Node.js 16, or OpenSSL 1.0 in a CDE requires a documented risk decision with compensating controls, reviewed annually. Most organizations haven't done this. Most QSAs will find it.

SOC 2

The relevant Trust Services Criteria: CC7.1 (detection of threats to system components) and CC6.1 (logical access controls). An auditor testing CC7.1 will ask: how do you identify vulnerabilities in your environment? If your answer doesn't include a process for tracking software end-of-life, that's a gap. If EOL software is found running, that gap becomes a finding.

HIPAA Security Rule

The HIPAA Security Rule (45 CFR §164.312) requires covered entities and business associates to implement technical security measures to guard against unauthorized access to ePHI. OCR's current enforcement posture ties penalty severity to whether the covered entity had documented awareness of a risk and failed to act. Running unsupported software you knew about is worse than running it unknowingly.

ISO 27001:2022

Annex A Control 8.8 (Management of technical vulnerabilities) explicitly requires organizations to obtain timely information about technical vulnerabilities, evaluate exposure, and take appropriate measures. EOL software — software for which no patches exist — represents a structural vulnerability management failure under this control.

Framework	Key control	EOL exposure	Severity
PCI DSS 4.0	Req. 6.3.3, 12.3.2	Requires documented TRA for each EOL component in CDE	Critical
SOC 2	CC7.1, CC6.1	Gap in threat detection and vulnerability management	High
HIPAA	§164.312(a)(2)(iv)	Known risk factor in OCR breach investigations	Critical
ISO 27001:2022	Annex A 8.8	Structural failure of technical vulnerability management	High
FedRAMP	SI-2, SA-22	SA-22 directly addresses unsupported software; POA&M required	Critical

What Real Exposure Looks Like

These are the technologies most commonly found in production today that are past end-of-life:

Product	EOL Date	EOL Risk Score™
PHP 7.4	Nov 28, 2022	90 Critical
Python 3.8	Oct 7, 2024	88 Critical
Node.js 18	Apr 30, 2025	85 Critical
Spring Framework 5.3	Dec 31, 2024	82 Critical
Ubuntu 20.04	Apr 2025	80 Critical

These aren't obscure legacy systems. They're the foundation of most mid-market production environments — deployed three years ago and untouched since. That's the window auditors find.

The CISA KEV Connection

CISA's Known Exploited Vulnerabilities catalog is now a compliance input, not just an advisory. EOL software creates a specific KEV problem: when a vulnerability is discovered in a product past end-of-life, the vendor will not patch it. The CVE will be assigned. If it's exploited in the wild, it enters the KEV catalog. Your only remediation path is replacing the software entirely.

A 30-Day Action Plan

Days 1–5: Build the inventory
You cannot manage what you cannot see. Use the endoflife.ai Stack Scanner to get an immediate read on your technology stack against current EOL dates.

Days 6–10: Score and prioritize
Use the EOL Risk Score™ to triage. Components scoring 76+ go to the top of the remediation queue.

Days 11–20: Document compensating controls
For every EOL component you cannot immediately upgrade, document: what the component is, why it's EOL, compensating controls in place (network segmentation, WAF, enhanced monitoring), and a defined remediation timeline. Under PCI DSS 4.0, this is the Targeted Risk Analysis.

Days 21–30: Establish ongoing monitoring
The endoflife.ai API provides programmatic access to EOL dates for 455+ products, enabling automated alerting when components in your inventory approach end-of-life. 90-day lead time is the minimum.

Compliance frameworks don't require perfect software. They require that you know your risks and manage them deliberately. The tooling to know is free. The cost of not knowing is not.

Check your stack at endoflife.ai — free, no signup required.