What is EOL software? —
every term, explained like you're new here.
The short version: every piece of software has a date after which its maker stops fixing it — including security holes. That date is its end of life (EOL). The software keeps running after EOL; it just stops being defended. Any security flaw found after that date stays open forever, on every system still running it. This guide explains every term, acronym, and concept you'll meet when dealing with that — assuming zero prior knowledge.
The life of a piece of software, start to finish
Software versions move through predictable phases. The names vary by vendor, but the shape is always the same:
| Phase | What it means | What you get |
|---|---|---|
| Release (GA) | The version is declared ready for real-world use ("generally available"). | Everything: new features, bug fixes, security patches. |
| Active support | The healthy middle of life. | Bug fixes and security patches; sometimes new features. |
| Maintenance / security-only | The wind-down. The maker stops improving it. | Security patches only. PHP and Python both have this phase. |
| End of life (EOL) | The maker walks away. | Nothing. No fixes of any kind, ever again. |
| Extended support | Optional overtime — from the vendor or a third party, usually paid. | Security patches past EOL, for a price. A bridge, not a destination. |
The crucial point: software doesn't stop working at EOL. A server running EOL software behaves identically the day after the date. That's exactly what makes it dangerous — nothing visibly breaks, so nothing prompts action, while security holes quietly accumulate.
The acronym decoder
Every term you'll meet on this site or in a vendor lifecycle document:
| Term | Stands for | Plain-English meaning |
|---|---|---|
| EOL | End of Life | The date the maker stops all fixes, including security patches. The big one. |
| EOS / EoS | End of Support / Sale | Usually a synonym for EOL. Occasionally means "end of sale" — when a product stops being sold but is still supported. Check which one a vendor means. |
| EOSL | End of Service Life | The hardware version of EOL — when servers, switches, and storage stop getting firmware fixes and vendor repairs. More here. |
| EOM | End of Maintenance | When routine bug-fixing stops, often before full EOL. After this, security patches may continue but bugs stay bugs. |
| GA | General Availability | The official release date — when a version is declared production-ready. The lifecycle clock starts here. |
| LTS | Long-Term Support | A version the maker promises to support for an extended window (often 3–5+ years). The versions you should run in production. Ubuntu, Node.js, Java, and Django all use LTS releases. |
| STS | Short-Term Support | The opposite: a version supported only briefly (often 6–18 months), meant for early adopters. Oracle calls these "Innovation Releases." |
| ELS / ESU / ELTS | Extended (Lifecycle) Support / Extended Security Updates | Vendor-specific names for paid support past EOL: Red Hat sells ELS, Microsoft sells ESU, Debian's community offers ELTS. Same idea, different logos. |
| CVE | Common Vulnerabilities and Exposures | The global ID system for security flaws. Each disclosed vulnerability gets a number like CVE-2026-12345. "Unpatched CVEs" = known, documented holes with no fix applied. |
| CVSS | Common Vulnerability Scoring System | A 0–10 severity score attached to each CVE. 9+ is critical. |
| NVD | National Vulnerability Database | The US government's public catalog of all CVEs. Attackers read it too — that's the point of patching fast. |
| KEV | Known Exploited Vulnerabilities | CISA's list of CVEs actively being used in real attacks — not theoretical risk, observed exploitation. We factor KEV presence into every EOL Risk Score™. |
| CISA | Cybersecurity & Infrastructure Security Agency | The US agency that maintains the KEV catalog and issues security directives. |
| SBOM | Software Bill of Materials | An ingredient list for your software — every component and version inside it. Increasingly required in procurement and compliance; it's what makes EOL auditing possible at scale. |
| SCA | Software Composition Analysis | Tools that scan your dependencies for known vulnerabilities. Useful — but most don't flag EOL status, which is the gap this site covers. |
What's actually in a "stack"?
When people say their "stack," they mean the layers of software their application sits on. Each layer has its own EOL clock. From the bottom up:
Operating system (OS)
The foundation layer that runs the machine — Windows, macOS, or a Linux distribution ("distro") like Ubuntu, Debian, or RHEL. A distribution is a packaged bundle of the Linux kernel plus thousands of tools, released and supported as one versioned product. When Debian 12 hits EOL, every package in that bundle stops receiving coordinated security fixes.
Runtime
The engine that executes your code. Code written in JavaScript needs Node.js to run on a server; Python code needs the Python interpreter; Java code needs the JDK/JVM. You don't write a runtime — you write code that runs on one. Runtimes are high-stakes EOL items because they process untrusted input (web requests, files) — an unpatched runtime is an exposed engine.
Framework
A pre-built skeleton for an application, providing the structure so you only write what's unique to you. Django (Python), Ruby on Rails, Spring Boot (Java), and Laravel (PHP) handle routing, database access, and security plumbing. The framework rides on a runtime: a Django app needs both Django and Python in support — two clocks, and either one expiring exposes you.
Library / dependency / package
Smaller reusable building blocks your code pulls in — a date formatter, an encryption module, an HTTP client. Modern apps use hundreds, fetched by a package manager (npm for Node.js, pip for Python, Composer for PHP). Each is a dependency — and each can be abandoned by its maintainer, which is EOL without a press release. (Where's the line between framework and library? Rough rule: your code calls a library; a framework calls your code. React technically sits in the middle — a library that's used like a framework.)
Database
Where the data lives: PostgreSQL, MySQL, MongoDB, Redis. Databases hold the crown jewels, so an EOL database is among the worst items on an audit. They also EOL on long cycles, which lulls teams into forgetting them.
Middleware & servers
The connective layer: web servers (nginx, Apache), application servers (Tomcat), message brokers (Kafka). Invisible when working, internet-facing by design — patching them matters.
Containers & base images
A container (usually Docker) packages an app with a slice of an operating system — the base image — so it runs identically anywhere. The catch: that base image embeds an OS with its own EOL. A Dockerfile starting with FROM debian:12 bakes Debian 12 into every container built from it — even brand-new deployments inherit the EOL layer.
Firmware & hardware
The software burned into physical devices — switches, servers, firewalls. It expires too (EOSL), and it's the layer organizations track least.
How version numbers work
Most software uses some form of semantic versioning: major.minor.patch — e.g., Python 3.11.9. The major number (3) signals big, potentially breaking change; the minor (11) adds features compatibly; the patch (9) is fixes only. EOL almost always applies to the major.minor line — "Python 3.11 is EOL" means every 3.11.x release, and no 3.11.10 will ever ship. Upgrading patch versions is routine hygiene; crossing minor or major lines is a migration. That's why teams pin versions — and why pinned versions quietly age into EOL.
Why EOL matters: the CVE blind spot
Compare two scary things. A zero-day is a flaw nobody knows about yet — frightening but rare, and once discovered it gets patched. EOL software inverts this: the flaw is public — documented on the NVD, scored by CVSS, often with working exploit code on GitHub — but no patch will ever exist. Attackers don't need to discover anything; they read the CVE feed and check who's still running the EOL version.
Worse, most security scanners give EOL software a clean bill of health: they check for known unpatched CVEs at scan time, not for the fact that the patch pipeline itself is dead. That gap is the CVE blind spot, and closing it is why this site exists. It's also a compliance problem: PCI DSS, SOC 2, ISO 27001, and HIPAA all expect supported, patchable software — running EOL components is an audit finding waiting to be written. More on that here.
Extended support: buying time when you can't upgrade
Sometimes you genuinely can't migrate before the date — a legacy dependency, a frozen budget, a vendor appliance. Extended support keeps security patches flowing past EOL, and it comes from two places:
From the maker: Red Hat sells Extended Life-cycle Support for RHEL, Canonical extends Ubuntu LTS coverage through Ubuntu Pro, and Microsoft sells Extended Security Updates for Windows. When a vendor program exists, it's the default option.
From third parties: providers such as TuxCare continue issuing security patches for end-of-life software the original maker has abandoned — for example CentOS, which is fully discontinued with no vendor program at all. Third-party extended support answers the question vendor programs can't: what do you do when the maker quits entirely?
Either way, treat extended support as a bridge — it buys a planned migration window, not a permanent excuse.
Where to start
- Look up anything — the EOL Checker covers 455+ products: type a name, get its dates and risk score.
- Check a whole project at once — paste a
package.json,requirements.txt, orGemfileinto the Stack Scanner. - Never get surprised again — every product page has an Add-to-Calendar button that reminds you 90, 30, and 7 days before an EOL date.
- Already found something EOL? The incident guide walks through your four options, step by step.