DEV Community: end-of-life.org

73% of the Software Versions We Track Are Already End of Life

end-of-life.org — Thu, 13 Aug 2026 05:30:00 +0000

Of the 8,307 software and hardware versions in
end-of-life.org, 73% are past their end-of-life date.
Another 142 branches reach EOL within the next 90 days.

The honest reading of that first number is: it is not very interesting. Software
accumulates dead versions the way a filesystem accumulates old files. Python 2.7
being EOL is not news, and nobody's risk register needs a line item for it.

The number that matters is much smaller, and getting to it means throwing away most
of the 73%.

Key Takeaways

"73% end of life" is mostly historical sediment — versions nobody runs. The figure is a denominator problem, not a finding.

What matters is the intersection of dead and still deployed, which no public dataset knows for you. Only your inventory does.

Among branches that are both dead and plausibly in production, rank by critical CVE count and by accumulation rate, not by total CVEs.

The 90-day window is the more useful number to put on a roadmap: it is the only part of the dataset that is actionable before it becomes urgent.

Most of that 73% is sediment

Every product carries its whole history. MySQL has 18 tracked branches, Go has 27,
PHP has 23, PostgreSQL has 29. The overwhelming majority of those are ancient and
uninteresting, and they will stay in the denominator forever, pushing the percentage
up every year regardless of what anyone does.

So the number does not describe risk. It describes how long the industry has been
shipping software.

The full directory covers 462 products, and
browsing it makes the shape obvious: for any given product, a couple of branches are
maintained and a long tail behind them is not. That tail is normal.

The number that isn't sediment

The intersection you care about is dead and still running in your environment.

That second half is the part no external dataset can answer. A lifecycle database
knows when Oracle stopped patching MySQL 5.7. It has no idea whether you have four
of them in a VPC somewhere. Every EOL dashboard that shows you a big scary
percentage without reading your inventory is showing you the sediment.

Which means the useful workflow runs in the opposite direction from how these tools
are usually pitched:

Enumerate what you actually run — lockfiles, container images, AMIs, whatever is authoritative in your environment.
Look each one up against lifecycle data.
Rank only the matches.

Step 3 is where most of the value is, and where most teams get the ordering wrong.

Ranking: the trap is sorting by CVE count

The obvious sort is "how many vulnerabilities has this version missed since it went
EOL." It is the wrong primary key, and the current data shows why cleanly.

MySQL 5.7 sits at the top of that list with
127 missed CVEs. Zero of them are rated critical. Go 1.15 sits just below it
with 122 missed CVEs, and twelve of those are critical.

Sort descending by volume and you fund the wrong upgrade first. I went through the
full ranking and the arithmetic behind it in
Your EOL Risk List Is Probably Sorted Wrong;
the short version is below.

There is a second distortion in the same column: CVE count rewards age. Normalise by
time and the ranking inverts.

Version	Days EOL	CVEs missed	Critical	CVEs/year
MySQL 5.7	~1,060	127	0	~44
MySQL 8.1	1,020	103	0	~37
Go 1.17	1,469	106	10	~26
Go 1.16	1,609	111	10	~25
Go 1.15	1,820	122	12	~24

Go 1.15 had nearly twice as long as MySQL 5.7 to accumulate a slightly smaller
number. The Go branches cluster at 24-26 missed CVEs per year, the MySQL branches at
37-44 — the same measurement, from the same source, separating the two ecosystems by
roughly 50%. Counts published by the NVD; lifecycle dates
from vendor policy documents such as Oracle's
Lifetime Support Policy
and Go's release policy.

That rate is the number to bring to a planning conversation, because it answers the
question that actually gets asked: what does it cost us to defer this another
quarter? Total CVE count answers a question nobody asked, which is how long the
thing has been dead.

The 90-day window is the part you can act on

142 branches reach end of life within 90 days.

Unlike the 73%, this number is small, forward-looking, and maps directly onto a
planning cycle. Everything in it is by definition something a vendor is still
supporting today, which means the upgrade path exists, is documented, and has not
yet acquired the compatibility debt that accumulates after a branch goes cold.

Upgrades scheduled before the EOL date are maintenance. The same upgrades six months
later are incidents. The window is the cheapest part of the dataset to act on and
the easiest to ignore, because nothing is broken yet.

What I would put on the roadmap

When	What	Sort by	Why
Now	Dead and deployed	Critical CVE count	Severity is the only column that maps to blast radius
This quarter	Dead and deployed, high accrual rate	CVEs/year	Where the next critical shows up, before it does
Next two quarters	The 90-day list	EOL date	Cheapest window — it is maintenance now, remediation later
Never	The rest of the 73%	—	Sediment. Treating it as a backlog is how a risk register becomes something nobody reads

The only hard part is the first column of row one, and it does not come from any
lifecycle database. It comes from your inventory.

Two caveats worth stating plainly

Vulnerability analysis currently covers 13 products — the runtimes, databases and
app servers where post-EOL exposure is easiest to reason about. The other 449
products in the directory carry lifecycle dates only. If a field comes back empty
for those, it means not analysed, not no vulnerabilities, and any dashboard that
renders it as zero is lying to you.

And CVSS severity is a scoring model, not a measure
of exploitability in your environment. "Zero criticals" does not mean MySQL 5.7 is
fine — 127 unpatched vulnerabilities is a real number. It means that between two
upgrades competing for the same window, severity is a better tiebreaker than volume.

Lifecycle dates are read from vendor policy documents and release notes;
vulnerability data comes from the NVD API. The per-product
source list is published on data sources, so
every figure here is reproducible. Not endorsed or certified by the NVD, and not
affiliated with any vendor — about ·
contact.

Your EOL Risk List Is Probably Sorted Wrong

end-of-life.org — Wed, 12 Aug 2026 03:54:10 +0000

Every "upgrade this now" list I have seen ranks end-of-life software the same way:
count the CVEs published since the version stopped receiving fixes, sort descending,
start at the top.

That ordering is easy to compute and it is misleading.

Here is the current top of that list, pulled from
end-of-life.org, which joins vendor EOL dates against
the NVD and counts what each dead branch never received:

Version	EOL since	CVEs missed	Rated critical
MySQL 5.7	Oct 2023	127	0
Go 1.15	Aug 2021	122	12
Go 1.16	Mar 2022	111	10
Go 1.17	Aug 2022	106	10
MySQL 8.1	Oct 2023	103	0

Key Takeaways

The version at the top of the list by CVE count has zero critical CVEs. The one below it has twelve.

CVE count conflates two different things: how long the branch has been dead, and how fast vulnerabilities accumulate in that ecosystem.

Normalising by time changes the ranking. MySQL accrues missed CVEs roughly 50% faster per year than Go does.

Severity and rate are both in the data already. Neither shows up in a plain descending sort.

The number one entry has no critical vulnerabilities

MySQL 5.7 has missed 127 CVEs since October 2023. Zero of them are rated critical.

Go 1.15 has missed 122 — five fewer — and twelve of those are critical.

If you are triaging with a fixed budget and you work top-down, you spend it on the
MySQL upgrade first. The data in the same table says the Go upgrade is the one
carrying critical-severity exposure.

I am not claiming MySQL 5.7 is safe. 127 unpatched vulnerabilities is 127
unpatched vulnerabilities, and CVSS scores are a
severity model, not a measure of exploitability in your environment. The point is
narrower: the sort key is throwing away the severity column.

Volume also measures how long the corpse has been sitting there

The second problem is that CVE count rewards age.

Go 1.15 went EOL in August 2021. It has been unpatched for 1,820 days. MySQL 5.7
went EOL in October 2023, roughly 1,060 days ago. Go 1.15 had almost twice as long
to accumulate its 122.

Divide by time and the picture inverts:

Version	Days EOL	CVEs missed	CVEs/year
MySQL 5.7	~1,060	127	~44
MySQL 8.1	1,020	103	~37
Go 1.17	1,469	106	~26
Go 1.16	1,609	111	~25
Go 1.15	1,820	122	~24

The Go branches cluster tightly around 24-26 CVEs per year. The MySQL branches sit
at 37-44. Same measurement, same source, and the two ecosystems separate cleanly.
Staying one more year on an EOL MySQL branch costs you roughly 50% more missed
fixes than staying one more year on an EOL Go branch.

That is a forecasting number, which is what you actually want when the question is
"can this upgrade wait another quarter." Raw CVE count is a backward-looking number
dressed up as a risk score.

Details for any single branch — the full timeline, the per-year CVE breakdown, and
the individual CVEs with their CVSS scores — are on the version pages, for example
MySQL 5.7.

Why the two ecosystems differ this much

Honestly: I do not know, and neither does the data.

Plausible contributors are that MySQL advisories arrive in Oracle's quarterly
Critical Patch Update batches under its
Lifetime Support Policy,
that Go's release policy — each major
version supported until two newer ones ship — produces a different branch cadence
entirely, and that NVD attribution practices differ by vendor. Any of those could
produce this gap without either project being less safe than the other.

What I will defend is the narrower claim: if you are ranking branches, rank them
within an ecosystem, or normalise by time, or both. Comparing a raw MySQL count
against a raw Go count and calling the bigger one riskier is comparing two different
measurements.

Computing this yourself

The data is a free JSON API — no key, no signup, no rate limit, CORS open, rebuilt
daily. GET /api/v1/products/{name}.json returns every branch of a product:

const res = await fetch('https://end-of-life.org/api/v1/products/mysql.json');
const { result } = await res.json();

const dead = result.releases
  .filter(r => r.isEol && r.cvesMissedSinceEol)
  .map(r => {
    // eolFrom is either YYYY-MM-DD or YYYY-MM; Date.parse handles both
    const years = (Date.now() - Date.parse(r.eolFrom)) / (365.25 * 864e5);
    return {
      branch: r.name,
      missed: r.cvesMissedSinceEol,
      perYear: +(r.cvesMissedSinceEol / years).toFixed(1),
    };
  })
  .sort((a, b) => b.perYear - a.perYear);

console.table(dead);

The fields worth knowing:

isEol / eolFrom — whether the branch is dead and when it died. There are also eoasFrom (active support ended) and eoesFrom (extended support ended); not every vendor defines all three, and a phase the vendor does not publish comes back null rather than a guess.
cvesMissedSinceEol — the count this whole post is about. It is null for products without CVE analysis, which matters (see below).
hasCveAnalysis on the product object — check this before you trust a null.

Dropping that into a CI job that reads your lockfiles and flags branches above a
per-year threshold is maybe an afternoon of work, and it gives you a number you can
put in front of whoever approves the upgrade. Full endpoint docs are at
end-of-life.org/api.

The limit worth stating

CVE analysis currently covers 13 products — Django, VMware ESXi, Go, Keycloak,
MySQL, Node.js, PHP, PostgreSQL, Python, Ruby on Rails, Ruby, Spring Boot, Apache
Tomcat. The directory tracks 462 products and 8,307 versions, but for the other 449
you get lifecycle dates only, and cvesMissedSinceEol is null.

So this method works today for the layer of your stack most likely to be a runtime
or a database, and not for everything else. A null there means "not analysed,"
not "no CVEs" — do not let a dashboard render it as zero.

What I would actually sort by

Three columns, in this order:

Critical count. Twelve criticals beats 127 mediums for where the first upgrade window goes.
CVEs per year. Forward-looking. Answers "what does one more quarter cost."
Total missed. Useful context, terrible primary key.

The data for all three is sitting in the same response. It is only the sort that
needs fixing.

Lifecycle dates are read from vendor sources — for the two products above, Oracle's
Lifetime Support Policy
and MySQL release notes, and Go's
release history. Vulnerability data comes from the
NVD API. Every date and count in this post is reproducible from
those sources plus the JSON API; the full source list per product is on
data sources. This project is not endorsed or
certified by the NVD and is not affiliated with any vendor —
about · contact.