Let me ask you something.
When was the last time your vulnerability scanner flagged an EOL runtime?
Not a CVE. Not a known exploit. Just — "hey, this runtime has been end-of-life for 383 days and will never receive another security patch."
If your answer is never, you're not alone. And that's exactly the problem.
The Gap Nobody Owns
The security industry has spent the last decade getting very good at one thing: finding known vulnerabilities in software that's still supported.
Snyk. Mend. Sonatype. JFrog Xray. Dependabot. These are excellent tools. They scan your dependencies, check them against CVE databases, and tell you which packages have known vulnerabilities.
But they all share the same blind spot.
They only check for vulnerabilities in software that vendors are still patching.
When Node.js 18 went end-of-life on April 30, 2025 — every CVE disclosed after that date started accumulating with no patch path. The vulnerability is public. Listed on NVD. Rated by CVSS. Often with exploit code on GitHub. And your scanner? Clean. Green. No alerts.
That's the EOL blind spot.
Why It's More Dangerous Than a Zero-Day
Think about this carefully.
With a zero-day vulnerability, nobody knows it exists yet. The attacker has to find it, develop an exploit, and deploy it before defenders can respond. The window is narrow. The skill required is high.
With EOL software, the vulnerability is public knowledge. The CVE is listed. The CVSS score is published. The exploit code is on GitHub. Defenders can't patch it because no patch exists. Attackers don't need sophisticated research — they just need a list of EOL software and a copy of Metasploit.
Your scanner gives EOL software a clean bill of health. Attackers know exactly what's there.
That asymmetry is what makes EOL software uniquely dangerous. It's not a gap in attacker knowledge. It's a gap in defender tooling.
Why The Gap Exists
I've thought about this a lot. There are four real reasons this blind spot persists.
1. It's unglamorous
Zero-days get headlines. EOL software going unpatched for three years doesn't. Nobody writes "Node.js 18 has been EOL for 383 days" as breaking news. It's slow, boring, and cumulative — which makes it more dangerous, not less. The security industry chases novelty. EOL is the opposite of novel.
2. Vendors have no incentive to flag it
Snyk makes money when you fix package vulnerabilities. They have zero financial incentive to tell you "your runtime is EOL and our tool can't help you with that." Same for every SCA vendor. The blind spot is structural, not accidental. The tools that could flag it are the same tools that benefit from you not knowing about it.
3. Responsibility falls in the gap between teams
Security teams say EOL runtimes are an ops problem. Ops teams say EOL runtimes are a security problem. Nobody owns the runtime lifecycle. It falls through the crack between two departments — and in that crack, Node.js 16 runs unpatched for two years.
4. There was no authoritative reference
Before endoflife.ai — where did you go to check if Node.js 18 was EOL with a quantified risk score? endoflife.date has the dates but no scoring. NVD has CVEs but not EOL status. Vendor docs are scattered and inconsistent. There was no single authoritative source that said "here's the score, here's the risk, here's what to do."
That last point is the one I decided to do something about.
What We Built
endoflife.ai is a free public platform tracking end-of-life dates for 455+ software products — every major runtime, OS, framework, database, and cloud platform.
But dates alone aren't enough. "Node.js 18 EOL: April 30, 2025" is a fact. It doesn't tell you what to do about it or how urgent it is relative to everything else on your plate.
So we built the EOL Risk Score™ — a proprietary 0–100 score measuring the actual security and operational risk of running a specific version in production.
Four factors:
| Factor | Weight | What it measures |
|---|---|---|
| EOL Recency | 40pts | How long since support ended |
| Attack Surface | 30pts | How broadly deployed and exploitable |
| CISA KEV Exposure | 20pts | Known exploited vulnerabilities in the CISA catalog |
| Extended Support | 10pts | Whether commercial extended support exists |
Validated scores:
- Node.js 14 — 90 Critical (3+ years past EOL)
- Node.js 16 — 90 Critical (cut short 7 months early due to OpenSSL EOL)
- Node.js 18 — 85 Critical (383 days past EOL)
- Node.js 20 — 78 Critical (just hit EOL April 30, 2026)
- Ubuntu 20.04 — 80 Critical (352 days past EOL)
- Python 3.8 — 88 Critical (EOL Oct 2024, system Python on Ubuntu 20.04)
- Node.js 22 — 50 Medium (Active LTS, supported until 2027)
Every product and version has a dedicated score card at a shareable URL — endoflife.ai/score/nodejs/18 — with an OG image that renders on LinkedIn and X.
The API
The data is also available via API at api.endoflife.ai.
curl https://api.endoflife.ai/v1/score/nodejs/18
{
"product": "nodejs",
"version": "18",
"eol_date": "2025-04-30",
"status": "eol",
"days_past_eol": 383,
"score": 85,
"band": "Critical",
"factors": {
"eol_recency": 35,
"attack_surface": 30,
"cisa_kev_exposure": 20,
"extended_support": 0
}
}
Free tier — 100 requests/day, no key required. Pro tier — $199/mo, unlimited, batch endpoint for scanning entire stacks.
The API is what powers integrations with Datadog, Snyk, Renovate, Backstage, and any security tool that needs runtime EOL data as a machine-readable feed.
The Double EOL Problem Coming in October 2026
Here's something almost nobody is writing about yet.
Python 3.10 and Python 3.11 both reach end of life on October 31, 2026 — the same date.
Two major Python versions going EOL simultaneously means a significant portion of the Python ecosystem will be unpatched at the same moment. If you're running either version, you have approximately five months to migrate.
The migration to Python 3.12 is straightforward for most codebases — but "straightforward" still takes 4–8 weeks when you factor in dependency compatibility testing, CI pipeline updates, and staged rollouts.
Start now.
What This Means for Security Teams
EOL software needs to be treated as a vulnerability class — not a maintenance task.
That means:
- Adding EOL status to your risk register alongside CVE severity
- Including runtime EOL checks in your CI/CD pipeline
- Flagging EOL runtimes in your observability platform alongside performance metrics
- Requiring EOL dates in your SBOM alongside dependency versions
- Briefing leadership with EOL Risk Scores™ the same way you'd brief them on critical CVEs
The CISO who walks into the boardroom with "Node.js 18 scores 85/100 Critical — here's our migration timeline" is having a different conversation than the one who says "some of our runtimes are a bit outdated."
Numbers change conversations.
The Platform
Everything on endoflife.ai is free:
- 455+ product pages with complete version history and EOL dates
- 8,001 score card pages — one for every tracked version
- EOL Checker — instant lookup for any product
- Stack Scanner — upload a dependency file, get a full EOL audit
- Free API — 100 requests/day, no account required
- Methodology — full scoring documentation at endoflife.ai/risk-score
If your team needs unlimited API access for integrations, the Pro tier is $199/month.
If you're a security platform, observability vendor, or developer tool that wants to integrate EOL intelligence — the API is ready and we're actively building partnerships. Reach out at partners@endoflife.ai.
The EOL blind spot is real. The tools to close it exist now.
Check your stack at endoflife.ai.
This article is part of The EOL Intelligence Report series. EOL dates sourced from endoflife.date. CISA KEV data from the US Cybersecurity and Infrastructure Security Agency.
Top comments (0)