DEV Community: endoflife-ai

Exploited at CVSS 10.0 - And the Vendor Never Checked Whether EOL Versions Are Affected

endoflife-ai — Tue, 28 Jul 2026 16:56:58 +0000

Originally published at endoflife.ai.

On July 27, CISA added a maximum-severity flaw in Arista's VeloCloud Orchestrator to its Known Exploited Vulnerabilities catalog and gave federal agencies until July 30 to fix it — three days.

Arista's advisory is clear and well written: it names the affected builds, names the fixed builds, publishes attacker IP addresses, and states plainly that the flaw "was discovered externally and is known to be actively exploited." If you run a supported version of VCO, you know exactly what to do.

And then there is one line, sitting quietly among the version tables, that tells a very different group of people almost nothing:

"End of support software versions have not been assessed."

Eight words. If you're running an end-of-support VeloCloud Orchestrator, that sentence is the entire answer you're going to get about a CVSS 10.0 vulnerability that attackers are using right now.

What Arista actually disclosed

Field	Value
CVE	CVE-2026-16812
CVSS v3.1 / v4.0	10.0 / 10.0
Type	OS command injection, VeloCloud Orchestrator (VCO) on-prem
Exploitation	Discovered externally; known to be actively exploited
Added to CISA KEV	July 27, 2026
Federal remediation due	July 30, 2026

Affected and fixed builds:

Branch	Vulnerable	Fixed in
VCO 5.2.x	before 5.2.3.14	5.2.3.14
VCO 6.1.x	before 6.1.3.4	6.1.3.4
VCO 6.4.x	before 6.4.2.4	6.4.2.4
VCO 7.0.x	before 7.0.0.1	7.0.0.1
End-of-support versions	Not assessed	—

Arista also published three IPs observed in attacks: 8.19.75.217, 206.72.242.124, 206.72.242.162. That's genuinely useful disclosure — more than many vendors provide. This isn't a criticism of Arista's handling. It's about what the last row of that table means.

"Not assessed" is not "not affected"

These two statements look similar and mean opposite things:

"Version X is not affected." Someone tested it. You're safe. Move on.
"Version X has not been assessed." Nobody tested it. You don't know. Nobody is going to tell you.

The natural reading of an advisory is that anything not listed as vulnerable is fine. That reading is wrong here — and it's wrong the same way across most vendor advisories. Vendors scope security testing to supported releases, because that's what support contracts oblige them to fix. Unsupported releases fall outside the investigation — not because they're believed safe, but because there'd be no patch to ship even if they were found vulnerable.

So the position for someone on an end-of-support VCO is worse than it first appears. The vulnerability is confirmed exploited in the wild. The code path is old enough to plausibly exist in earlier builds. There's no assessment, no advisory update coming, and no fix. The exposure isn't merely unpatched — it's unmeasured.

The three-day clock, and what it accidentally reveals

CISA added two vulnerabilities to the KEV catalog on July 27. Their deadlines are not the same:

CVE	Product	Due	Window
CVE-2026-16812	Arista VeloCloud Orchestrator	July 30	3 days
CVE-2025-68686	Fortinet FortiOS	August 10	14 days

Same catalog, same day, deadlines four times apart. This is BOD 26-04 working as designed: federal remediation deadlines now scale with composite risk — exposure, exploited status, automatability, impact — not a severity number. The VeloCloud flaw needs no credentials, is network-reachable, and hands over the host. The Fortinet issue requires prior filesystem-level compromise. One is a front door; the other is a cupboard inside a house you've already broken into.

Both KEV entries carry the same required action, and it's worth quoting how it ends: apply vendor mitigations, "or discontinue use of the product if mitigations are unavailable."

Read that against "end of support software versions have not been assessed." For an unsupported VCO, vendor mitigations are unavailable. CISA's own instruction, followed to its conclusion, says stop using it.

If you run VeloCloud Orchestrator today

On a supported branch: upgrade to 5.2.3.14 / 6.1.3.4 / 6.4.2.4 / 7.0.0.1+. Check logs against the three published attacker IPs first — with active exploitation confirmed, assume you may be looking at an incident, not a maintenance window.

On an end-of-support branch:

Restrict access to the VCO web interface now. The attack needs network reachability and no credentials. Network controls are the one mitigation that doesn't depend on the vendor.
Hunt before you assume. "Not assessed" cuts both ways — you can't rule your version in, but you can't rule it out either.
Don't wait for an advisory update. There's no assessment scheduled. Your version's absence from the affected list is not future clearance; it's permanent silence.
Plan the upgrade as an incident cost, not a project.

The pattern this exposes

This isn't really a story about one networking vendor. The usual description of end-of-life is that patches stop. True — and it understates the problem. What actually stops, in order:

Patches stop. The well-understood part.
Assessment stops. New vulnerabilities are no longer checked against your version — your risk becomes unmeasurable, not just unaddressed.
Advisories go quiet. Your version stops appearing in affected-product lists — which reads like safety and means absence.
Scanners lose the thread. Tooling keyed to vendor advisories inherits the vendor's scope. No advisory entry, no finding.

That fourth step is the one that catches teams out. A scanner reporting nothing for an EOL system is not evidence of safety — it may just be repeating the vendor's silence back to you.

The defence isn't a better scanner. It's knowing the lifecycle status of everything you run before an advisory lands — so when one does, you already know whether you're inside the vendor's field of view or outside it.

We track end-of-life dates and CVE risk for 490+ products at endoflife.ai — free checker, API, and risk scores. Sources: Arista Advisory 0144, CISA KEV catalog (v2026.07.27).

CISA rewrote how the US government handles dying software — twice this year

endoflife-ai — Mon, 27 Jul 2026 14:40:07 +0000

Two binding directives landed in 2026 that most of the private sector hasn't noticed — and together they're the clearest public statement yet of what competent vulnerability management looks like.

BOD 26-04 (June 10): severity scores are out, risk is in

Since 2021, federal patching ran on a simple rule: CVE lands in CISA's Known Exploited Vulnerabilities catalog → fixed clock starts. BOD 26-04 supersedes that entirely. Now four questions set the deadline for every vulnerability on every asset:

Asset Exposure — is it publicly reachable?
KEV Status — is the CVE actively exploited in the wild?
Exploit Automation — can an adversary automate the whole attack?
Technical Impact — partial or total control after exploitation?

Worst case on all four: three calendar days to remediate, plus mandatory forensic triage to check whether you're already compromised. Lowest tier: legitimately wait for the next scheduled upgrade. CISA pre-computes three of the four answers for every CVE through its Vulnrichment program.

The design says the quiet part loudly: severity is not risk. A CVSS 9.8 on an internal box with no exploit in the wild can matter less than a 7.5 being mass-exploited on your edge.

BOD 26-02 (February 5): end-of-support became a compliance deadline

The one almost nobody covered. This directive targets a single category — end-of-support edge devices: the firewalls, VPN appliances, and routers that face the internet and no longer receive vendor patches. Agencies got three months to find and remediate them, using a CISA-maintained EOS Edge Device List (yes — the US government now curates its own end-of-life database). The underlying OMB policy is blunt: unsupported systems must be "phased out as rapidly as possible."

The gap between the two directives

26-04 optimizes patching for software that can be patched. 26-02 evicts hardware that no longer can be. The gap: end-of-life software that isn't an edge device. The directive defines remediation as "patching, decommissioning the system, or another action" — but for EOL software, the patching option is permanently gone. Every future KEV entry against a dead product arrives pre-aged: exploited, often automatable, unfixable except by migration. Risk that cannot decay.

That's why lifecycle status is effectively the fifth risk variable — the one that determines whether the patch-based timelines are achievable at all. (It's the variable we build our EOL risk scores around, so yes, we're biased — but the government got here on its own.)

The 20-minute private-sector version

Inventory with lifecycle status — you can't triage what you haven't dated.
Adopt the four questions for patch priority; Vulnrichment answers three of them for free.
Treat EOL as its own tier — anything past end of support can never satisfy a patch deadline again. Migrate, or bridge with extended support while you do.

Both directives are public, battle-tested at federal scale, and free to copy: BOD 26-04 · BOD 26-02. Full analysis with the FAQ: endoflife.ai/article-cisa-bod-26-04-eol

One badge that tells your users when your dependencies die

endoflife-ai — Sun, 26 Jul 2026 22:41:21 +0000

Every README makes claims about support. Almost none of them stay true.

"Requires Node 18+" — written in 2023, when Node 18 was the fresh LTS. Node 18 died in April 2025. The README didn't notice. Neither did most of the people reading it.

I run endoflife.ai, a site that tracks end-of-life dates for 488 products, and the most requested thing after the data itself has been: can my README just show this automatically? So we built badge endpoints for everything we track — here's what they look like and how to use them.

The badge

[![Node.js end of life](https://img.shields.io/endpoint?url=https%3A%2F%2Fendoflife.ai%2Fbadge%2Fnodejs.json)](https://endoflife.ai/nodejs)

That renders a standard Shields.io badge showing the current support status of the newest Node.js release line — and it updates itself. When the status changes, the badge changes. Nobody edits the README.

Here's the live one:

Swap nodejs for whatever your project depends on: python, postgresql, django, spring-boot, php, kubernetes — 488 products have endpoints.

Pin it to the version you actually support

The more useful variant for most projects — badge your minimum supported version, so users can see when your floor goes EOL:

[![Python 3.10 EOL](https://img.shields.io/endpoint?url=https%3A%2F%2Fendoflife.ai%2Fbadge%2Fpython%2F3.10.json)](https://endoflife.ai/python/3.10)

Python 3.10 dies October 31, 2026. The day it does, that badge flips — and your issue tracker finds out why you should bump the floor before your users do.

There's also a risk-score version

[![EOL risk](https://img.shields.io/endpoint?url=https%3A%2F%2Fendoflife.ai%2Fbadge%2Fscore%2Fnodejs.json)](https://endoflife.ai/score/nodejs)

This one renders a 0–100 EOL risk score (factors: days to EOL, CVE exposure, whether the version appears in CISA's exploited-vulnerabilities catalog). Useful for internal dashboards and platform-team wikis more than public READMEs.

How it works (nothing clever)

Each badge is a static JSON file in the Shields endpoint format, regenerated nightly from vendor lifecycle policies — the same dataset behind the site. No tracking, no API key, no rate limits beyond Shields' own caching. If you'd rather consume the raw data, every endpoint has a JSON API equivalent documented here.

The dates come from vendor policy pages and the endoflife.date community dataset (we're contributors), cross-checked nightly. When vendors change dates quietly — Microsoft moved a Windows 10 ESU date a full year with zero announcement in June — we correct loudly.

Why I think this matters

An EOL date in a README is a promise that decays. A badge is a promise that keeps itself. If your project pins a runtime, a framework, or a database version, your users deserve to know when that floor rots out from under them — preferably before the CVEs arrive with no patches behind them.

If a product you depend on is missing from the list, tell me and we'll add it.

The Next SharePoint 9.8 Arrived in Eight Days - And It Was the Last One With a Patch

endoflife-ai — Fri, 24 Jul 2026 22:09:13 +0000

Originally published at endoflife.ai.

On July 14, 2026, two things happened to SharePoint Server 2016 and 2019 at once: they reached end of extended support, and they received their final security update. At the time, the obvious question was how long before the next critical flaw showed up with no fix behind it.

The answer turned out to be eight days.

On July 22, CISA added CVE-2026-50522 to its Known Exploited Vulnerabilities catalog - a deserialization flaw in SharePoint Server rated CVSS 9.8, yielding remote code execution. A public proof-of-concept exploit appeared on July 20; active exploitation followed within hours. Federal agencies were given until July 25 to remediate. Three days.

The twist that matters

This one was patched for 2016 and 2019 - in the July 14 updates, the same batch that closed CVE-2026-58644, and the same batch that was their last ever.

So a fully updated 2016 or 2019 farm is covered against CVE-2026-50522. That is exactly why it's worth writing about: it is the final flaw those versions are on the right side of. Every SharePoint vulnerability disclosed from here on has no fix for 2016 and 2019 - at any price.

Why "it was patched" is not the reassurance it sounds like

Two things are true at once:

If you applied the July 14 updates, you are protected against this specific flaw. That update earned its keep twice over - two critical, exploited-in-the-wild RCEs in one drop.

If you did not, you now have a public exploit and active in-the-wild attacks pointed at a version that can never be patched again. The July 14 update is still available and you should apply it today - but there is no next one. For a supported product, "we're a bit behind on patching" is a scheduling problem. For SharePoint 2016 and 2019 after July 14, it is the difference between the last fix and no fix.

There is no Extended Security Updates program for SharePoint - unlike Windows 10 or Windows Server. No paid extension, no third-party equivalent, because nobody outside Microsoft can patch proprietary SharePoint code. July 14 was a hard cutoff.

This is a base rate, not a bad week

CISA has flagged a run of actively exploited SharePoint vulnerabilities in a matter of months - CVE-2026-56164, CVE-2026-58644, and now CVE-2026-50522 among them - and issued a dedicated SharePoint hardening alert on July 14. SharePoint on-premises is internet-facing, holds the documents worth stealing, and sits inside the Windows identity fabric. That cadence does not slow down because a support date passed. What changed is that, from the next flaw onward, the response option for 2016 and 2019 is gone.

What to do this week if you're on 2016 or 2019

Confirm the July 14, 2026 updates are installed on every farm. A public exploit is circulating.
Check for prior compromise. CISA has reported attackers harvesting IIS machine keys from SharePoint to establish persistence - stolen keys survive patching. If a farm was internet-facing and unpatched during the exploitation window, rotate machine keys and treat an incident review as part of the response.
Take internet-facing farms off the public internet. Migration is a quarter of work; removing internet exposure is an afternoon, and it converts an unpatchable internet-facing target into an unpatchable internal one.
Pick a destination: SharePoint Server Subscription Edition (on-premises, subscription licensing), SharePoint Online in Microsoft 365 (farm solutions don't migrate), or another platform. A typical enterprise migration runs 6-18 months - the clock is already running.

The general lesson

An end-of-support date changes nothing about your software and everything about your options. CVE-2026-50522 is the cleanest possible demonstration: identical bug class, identical attacker behavior, identical severity to the flaws before it - and the only variable that moved is whether a fix exists on the other side. On July 13 it would have. Going forward it won't.

Plan around the last patch date, not the last release date - and check whether a product even has an ESU-style escape hatch before assuming a deadline is soft. SharePoint doesn't.

Track end-of-life dates and risk for 480+ products at endoflife.ai - or check the full SharePoint timeline.

Gold Eagle Can't Patch What Nobody Maintains: The EOL Hole in the White House's New Vulnerability Pipeline

endoflife-ai — Mon, 20 Jul 2026 22:29:03 +0000

On July 14, the White House launched Gold Eagle, a national vulnerability coordination clearinghouse created by Executive Order 14409. The premise is sound and the timing is not subtle: AI systems are now discovering software vulnerabilities faster than human processes can verify, prioritize, and fix them, so the government is building machine-speed coordination to match. Gold Eagle is managed by the Treasury Department with contributions from CISA, DHS, and DoD, takes reports through the VINCE platform operated with Carnegie Mellon's Software Engineering Institute, and uses frontier AI models to help find and triage flaws.

The numbers behind the launch are worth sitting with. The first half of 2026 produced 35,364 CVEs — more in six months than any full year before 2024 — with June alone contributing a record 7,454. FIRST's mid-year forecast now projects roughly 66,000 CVEs for 2026, 46% above its own February estimate. One detail from that forecast deserves more attention than it's getting: exploitable risk has stayed roughly flat. Discovery is what exploded. AI didn't suddenly make software more dangerous — it made the danger visible faster than anyone can respond to it.

Gold Eagle is a reasonable answer to that problem. But there's a hole in the pipeline.

A clearinghouse routes fixes. EOL software has no address.

Strip away the architecture and every vulnerability coordination system does the same thing: it receives a report, verifies it, and routes it to the party who can ship the fix — the vendor, the maintainer, the project. The entire model rests on someone being at the end of the pipe.

For end-of-life software, no one is. When a version's support window closes, the maintainer's obligation ends. A vulnerability found in an EOL version doesn't get triaged into a patch queue — it gets triaged into nothing. Verify it, prioritize it, route it: the pipeline executes perfectly and delivers the report to an empty chair.

The arithmetic of the blind spot: AI-assisted discovery doesn't distinguish between supported and unsupported code — if anything, older code yields flaws more readily. So as discovery scales toward 66,000 CVEs a year, the number found in end-of-life versions scales with it. Every one of those is permanent: no patch is coming, ever. Machine-speed discovery plus fixed-at-zero remediation equals a pile of unpatchable, publicly documented vulnerabilities growing at machine speed.

This isn't a design flaw in Gold Eagle — no clearinghouse can compel a maintainer to support software whose lifecycle has ended. It's a boundary condition. But it means the organizations most exposed to the CVE surge are precisely the ones running software the new national pipeline cannot help: the CentOS 7 estates, the AngularJS frontends, the old Spring services, the PHP 7 apps still quietly serving production traffic.

The triage question nobody's pipeline asks first

For any newly disclosed vulnerability, the first question that determines everything downstream is not severity, not exploitability — it's "is the affected version still supported?" The answer forks the entire response:

Lifecycle status	What the disclosure means	Your move
Supported version	A patch exists or is coming — the pipeline works	Standard triage: assess, prioritize, patch
End-of-life version	No patch is coming — the pipeline ends at nothing	Upgrade, isolate, or bridge with extended support — patching is not on the menu
EOL version, CVE lists only supported versions as affected	The worst case: your version is likely vulnerable but appears in no scanner	Assume affected — the CVE blind spot

As triage itself becomes AI-driven — which is the whole point of Gold Eagle — that lifecycle question has to be answerable by machines, instantly, per component. Lifecycle data is becoming infrastructure that automated pipelines consume (we wrote about exactly this shift two days before the launch), and Gold Eagle is now the most prominent machine reader in the world.

What this means if you run infrastructure

1. Your lifecycle inventory just became your triage pre-filter. With disclosure volume heading toward 66,000 a year, per-CVE handling only scales if you can instantly partition your estate into "patchable" and "not patchable." That partition is your EOL status map — and it changes monthly: the median supported lifespan across the ecosystem is just 18 months.

2. EOL components need a decision, not a backlog entry. Every end-of-life system in your inventory now sits in the path of an accelerating disclosure firehose with no patch valve. The realistic options are the same three as always — upgrade, isolate, or extended support as a bridge — but "we'll get to it next year" now means absorbing a year of permanent CVEs at 2026 discovery rates. And the H2 2026 calendar is dense with deadlines moving systems into this category: OpenSSL 3.0, Oracle JDK 17, PostgreSQL 14, PHP 8.2, .NET 8 and 9.

3. Watch the flat-exploitation line, but don't lean on it. FIRST's observation that exploitable risk has stayed flat is genuinely reassuring for supported software, where patches drain the pool. For EOL software the pool only fills. The gap between "documented vulnerabilities" and "exploited vulnerabilities" is a lag, not a law — and for unpatchable systems, every documented flaw waits indefinitely for its turn.

The bottom line

Gold Eagle is the clearest official acknowledgment yet that vulnerability management has crossed into the machine-speed era. It will likely make patching faster where patches exist. But it also sharpens the line between two kinds of software: the kind connected to a maintainer, which the national pipeline can now help faster than ever — and the kind that isn't, which no pipeline can help at all.

Knowing which side of that line every component in your stack sits on, at all times, is no longer hygiene. It's the entry ticket to functioning triage. You can check any version in seconds or scan your whole stack — against dates verified against vendor sources.

Originally published on endoflife.ai — the software lifecycle database tracking EOL dates and risk scores for 485 products.

The EU Cyber Resilience Act Has an EOL Problem — and the Deadline Isn't the One You Think

endoflife-ai — Sat, 18 Jul 2026 02:15:28 +0000

Originally published at endoflife.ai.

Most conversations about the EU Cyber Resilience Act (Regulation (EU) 2024/2847) anchor on one date: the main obligations apply from December 11, 2027. That date is real — and comfortably far away, which is exactly the problem.

Buried inside the CRA is a much nearer deadline: the vulnerability and incident reporting obligations begin September 11, 2026. That's weeks away, not next year's problem. And the debt those obligations expose is one most teams have never inventoried: every end-of-life component sitting inside a product they ship.

Why the CRA turns EOL into a regulatory problem

The CRA applies to "products with digital elements" placed on the EU market — software and connected products, regardless of where the manufacturer is based. Under the regulation as adopted, manufacturers must:

Know their components (SBOM-style documentation obligations)
Handle vulnerabilities and provide security updates through a declared support period
Report actively exploited vulnerabilities and severe incidents — starting September 11, 2026
Face penalties up to the higher of €15M or 2.5% of global annual turnover for the most serious infringements

Here's the collision: you cannot provide security updates for a product whose components no longer receive security updates. An EOL library inside a shipped product is a support-period promise you cannot keep. Before the CRA, that was tech debt. Under the CRA, it's a compliance gap with a fine attached.

(Not legal advice — obligations vary by product category; verify against the regulation text and current guidance.)

What a component inventory actually finds

These aren't hypotheticals — they're the most common findings in real dependency scans, with dates verified against vendor lifecycle data:

Component	EOL date	Status today
Debian 10 base images	Sep 10, 2022	~4 years unpatched
AngularJS (any version)	Dec 31, 2021	~4.5 years unpatched
OpenSSL 3.0	Sep 7, 2026	dies 4 days before the CRA reporting deadline
.NET 8	Nov 10, 2026	dies during the CRA's first reporting quarter

That OpenSSL line is worth a second look: the TLS library embedded in half the world's software loses upstream support four days before the CRA's reporting obligations begin.

The lead-time trap

The real danger isn't the deadline — it's the arithmetic in front of it. Component inventory takes months. Remediation takes quarters. Migrating off every EOL dependency competes directly with your product roadmap. A team that starts discovery in 2027 has already missed the runway; the reporting obligations will be a year old before their inventory is done.

The compliance-ready EOL process

Four working parts, all automatable:

Continuous component inventory — scan dependency files with a stack scanner, check individual products in a free checker, and gate CI on the free API so an EOL component fails loudly instead of shipping quietly:

curl https://api.endoflife.ai/v1/status/dotnet/8
# "is_eol": false — until November 10, 2026.

Lifecycle dates tracked against a live source, not a spreadsheet — vendors move dates; a January export is a liability by June. endoflife.ai/eol-watch tracks what's coming, and every product page publishes an .ics calendar feed.
Risk-ranked remediation — an inventory with two hundred findings needs an ordering. Risk scores rank components by recency, exposure, and exploitation signals, so the migration queue starts with the components most likely to produce exactly the incidents the CRA makes reportable.
A plan for components you can't migrate in time — commercial extended-support vendors keep security patches flowing for EOL components, which maps directly onto the "updates during the support period" obligation. It's a bridge, not a destination — but for a 2026 deadline, bridges matter.

The reframe

The CRA converts lifecycle hygiene from an engineering virtue into a market-access requirement for the EU. The teams treating it as a 2027 problem are the ones who will discover, in 2027, that it was a 2026 problem.

Full breakdown with verified dates: endoflife.ai/article-eu-cra-eol-compliance

We Measured the Lifespan of 7,144 Software Versions. The Median Is 18 Months.

endoflife-ai — Fri, 17 Jul 2026 11:36:09 +0000

Originally published at endoflife.ai.

We run a database that tracks end-of-life dates for 485 software products — every version, every release date, every day the security patches stop. Which means we're sitting on something nobody else has bothered to assemble: enough lifecycle data to answer a simple question with actual numbers.

How long does a software version actually live?

We measured every version in the dataset with both a firm release date and a firm end-of-life date — 7,144 versions across 463 products — and computed the span between them.

The headline: 18 months

The median supported lifespan of a software version is 1.5 years. The mean is 2.3 years (a long tail of enterprise products drags it up).

Sit with that. The thing you deployed, integrated, and built muscle memory around has — statistically — about eighteen months of security patches from the day it shipped. If your upgrade cadence is "every two or three years," the math says you spend a meaningful slice of every cycle running unpatched software. Not because you're negligent — because the clock is shorter than most people's mental model of it.

By category: cloud dies fastest, hardware lives longest

Category	Versions measured	Median lifespan
Hardware	100	2.9 yrs
Operating systems	370	1.6 yrs
Databases	228	1.6 yrs
Security tools	61	1.3 yrs
Frameworks	195	1.1 yrs
Runtimes	221	1.0 yr
Cloud services	142	0.9 yrs

Two things jump out:

The stack rots from the top. The layers you interact with most — runtimes, frameworks, managed cloud services — turn over fastest. The infrastructure underneath (OS, database, hardware) gives you roughly 60–190% more runway. Your Node version will die before your Postgres version, which will die before your server.
Cloud services have the shortest leash of anything we measured. A managed service version's median lifespan is under a year — and unlike self-hosted software, when a cloud version dies you don't get to quietly keep running it. The provider migrates you on their schedule.

The extremes

Longest-lived (median across versions): Internet Explorer at 17.0 years — say what you want about IE, Microsoft supported it longer than some of its users' entire careers. Then Atlassian Data Center (12.2), Raspberry Pi (11.7), Apache HTTP Server (11.6), and NVIDIA GPUs (11.5).

Shortest-lived: a cluster of rolling-release projects — Chrome, Firefox, Rust, Prometheus, Neo4j among them — where each version gets roughly five weeks before the next one replaces it. That model works because upgrades are continuous and boring. The danger zone isn't rapid release; it's rapid release consumed at an enterprise pace.

Methodology, briefly

All data comes from the endoflife.ai dataset (built on the open-source endoflife.date project plus vendor lifecycle pages). We only measured versions with firm dates on both ends — no TBDs, no estimates — and used medians because enterprise long-tails skew means. Full methodology and tables are in the original article.

What to do with this number

If the median version lives 18 months, then "check lifecycle dates once, at adoption time" is a broken process — the answer changes underneath you. The fix is making the check continuous:

Look up anything in seconds: free checker, or scan a whole dependency file with the stack scanner
Gate it in CI with the free API:

curl https://api.endoflife.ai/v1/status/python/3.10
# "is_eol": false — until October 31, 2026.

Watch the big deadlines: the back half of 2026 alone kills OpenSSL 3.0, Oracle JDK 17, Python 3.10, .NET 8 and 9, PostgreSQL 14, and PHP 8.2 — the full calendar is at endoflife.ai/eol-watch

Eighteen months. Plan accordingly.

Your ESXi Hosts Are on Two Clocks Now: Support Dates and the Broadcom Licensing Squeeze

endoflife-ai — Thu, 16 Jul 2026 02:22:49 +0000

Originally published at endoflife.ai.

If you run ESXi, you're managing two countdowns at once — and they interact badly.

Clock one: support dates. vSphere/ESXi 7.x reached end of general support on October 2, 2025 (Broadcom extended it six months from the original April date — a one-time mercy, already spent). After end of general support: no more bug fixes or security patches, no support cases. Hypervisors are a top-tier attack target; an unpatched hypervisor is a very different risk than an unpatched app server, because everything above it inherits the compromise.

Clock two: licensing. Broadcom killed perpetual licenses in December 2023. Everything is subscription now, bundles have consolidated, and renewal quotes have become the stuff of sysadmin forum legend. The practical effect: staying current with VMware isn't just an upgrade project anymore, it's a recurring budget line that many orgs are re-evaluating from scratch.

The trap between the clocks

Plenty of teams responded to the licensing shock by freezing — staying on 7.x, skipping the renewal, running on inertia. That converts a licensing problem into a security problem: you're now on an unsupported hypervisor with no patch path, which is strictly worse than either paying up or migrating.

The realistic options

Renew under subscription and move to 8.x — least disruption, highest recurring cost. Check current version support windows against Broadcom's own lifecycle matrix before committing; the dates have moved before.
Migrate hypervisors — Proxmox VE, Hyper-V, and Nutanix all absorb refugees. Real work (tooling, backup integration, muscle memory), but a one-time cost versus a forever subscription. Proxmox's own lifecycle is worth checking as part of due diligence.
Hybrid retreat — shrink the VMware footprint to the workloads that genuinely need it, move the commodity VMs elsewhere, renew a smaller subscription.

Whatever the choice, it should be made by a date on a calendar, not by drift. Every ESXi version's current status is tracked live at endoflife.ai/esxi — and the rest of your stack's deadlines (SharePoint and SQL Server 2016 just died July 14; OpenSSL 3.0, .NET 8/9, PostgreSQL 14, and PHP 8.2 all go before year-end) are at endoflife.ai/eol-watch.

Free checker, free API, dates verified against vendor lifecycle sources.

.NET 8 and .NET 9 Both Die on November 10 - Yes, the LTS Too

endoflife-ai — Thu, 16 Jul 2026 02:21:19 +0000

Originally published at endoflife.ai.

Here's a date collision that surprises people: .NET 8 and .NET 9 reach end of support on the same day — November 10, 2026.

The instinctive reaction is "but 8 is the LTS!" — and that's exactly the trap. LTS doesn't mean long, it means longer. The math:

.NET 8 (LTS): released November 2023, supported 3 years → dies November 10, 2026
.NET 9 (STS): released November 2024, supported 2 years → dies November 10, 2026

Different tracks, same cliff. Anyone who "played it safe" on the LTS and anyone who rode the STS end up in the identical position this November.

What end of support actually means

After November 10, Microsoft ships no security patches for either runtime — including for vulnerabilities that get actively exploited later. Your app keeps running; it just stops getting defended. CVEs published against the runtime after that date are permanent for you.

For teams with compliance obligations, "unsupported runtime in production" is an audit finding, not a philosophical debate.

The only forward path is .NET 10

.NET 10 (LTS) shipped November 11, 2025 and is supported to November 14, 2028. For most 8→10 moves the upgrade is mercifully boring — retarget, run the test suite, chase a handful of breaking changes. The teams that get hurt are the ones who discover a transitive dependency pinned to an EOL runtime in December, not the ones who retargeted in September.

Worth separating in your head: .NET Framework 4.8 (the old Windows-only one) is a different animal — it has no fixed end date and lives as long as the Windows version hosting it. Modern .NET (Core lineage) is the one on the November clock. If you're still on Framework, your deadline is your Windows Server's deadline instead.

Put a date on it

The November 10 cutoff sits inside a brutal H2 2026 calendar: SharePoint 2016/2019 and SQL Server 2016 already died July 14, OpenSSL 3.0 goes September 7, Python 3.10 on October 31, PostgreSQL 14 on November 12, PHP 8.2 on December 31.

Every date above is verified against vendor lifecycle sources. Full deadline coverage lives at endoflife.ai/eol-watch, you can check any product's status in seconds with the EOL checker, or scan a whole project file with the stack scanner. There's also a free API if you'd rather gate this in CI:

curl https://api.endoflife.ai/v1/status/dotnet/8
# "is_eol": false ... until November 10.

Windows Server 2012 Loses Its Last Safety Net on October 13 - Here's the Actual Decision Tree

endoflife-ai — Thu, 16 Jul 2026 02:19:24 +0000

Originally published at endoflife.ai.

Windows Server 2012 and 2012 R2 officially left extended support back in October 2023. But almost nobody actually said goodbye — Microsoft sold three years of Extended Security Updates (ESU), and a huge slice of the installed base has been quietly riding that program ever since.

That ride ends on October 13, 2026. ESU Year 3 is the final year. There is no Year 4.

What actually stops

ESU was already a reduced diet: Critical and Important security fixes only — no new features, no non-security bug fixes, no design changes. After October 13:

No security patches of any severity, even for actively exploited vulnerabilities
No Microsoft support tickets for these systems
Compliance frameworks (PCI, SOC 2, cyber-insurance questionnaires) start flagging the OS as unsupported software

If the workload matters enough to have paid for ESU three years running, it matters enough to have a plan for October 14.

Why these boxes still exist

In most shops it isn't laziness — it's the app layer. The 2012-era server is usually alive because it hosts a legacy .NET Framework application, a line-of-business tool with no vendor, or something with a hardware dongle attached. The OS deadline is really an application deadline wearing a costume.

(Related: .NET Framework's lifecycle is tied to the Windows version hosting it — so a 2012 box dying can take its runtime support with it.)

The decision tree, honestly

Can you migrate the workload before October? Do it. Windows Server 2022/2025, or containerize the app if it will tolerate it.
Can't migrate but can lift the VM to Azure? ESU is free on Azure (VMs, Azure Stack, Azure VMware Solution) — Microsoft's deliberate carrot. Same server, same app, patches keep flowing, no ESU invoice. It's a bridge, not a destination, but it's a real one.
Stuck on-prem past October? Your options narrow to network isolation, compensating controls, and third-party support arrangements — plus a migration plan with an actual date on it.

The bigger picture

October 13 isn't an isolated event. The back half of 2026 is a wall of deadlines: SharePoint 2016/2019 and SQL Server 2016 already hit end-of-support on July 14, then Python 3.10 (Oct 31), .NET 8 and 9 (both Nov 10), PostgreSQL 14 (Nov 12), and PHP 8.2 (Dec 31).

We track all of it — dates verified against vendor lifecycle pages — at endoflife.ai/eol-watch, and there's a free EOL checker if you want to know where the rest of your stack stands.

We built a free API for software end-of-life dates and risk scores (460+ products)

endoflife-ai — Mon, 13 Jul 2026 03:29:34 +0000

Originally published at endoflife.ai/api.

Every outage post-mortem has a cousin: the "we were running an EOL version and didn't know" security incident. Debian 12 just went EOL this month, Spring Framework 6.2 and Spring Boot 3.5 hit end of support in June, and PostgreSQL 14 goes EOL in November. If your tooling can't answer "is anything in my stack out of support?", you find out the hard way.

We run endoflife.ai, which tracks end-of-life dates and security-support status for 460+ software products and scores every version with a 0-100 EOL Risk Score (factors: how long past EOL, attack surface, CISA KEV exposure, whether extended support exists). Today the whole dataset is queryable over a plain REST API.

One request, no auth

curl https://api.endoflife.ai/v1/score/nodejs/18

{
  "product": "nodejs",
  "version": "18",
  "eol_date": "2025-04-30",
  "status": "eol",
  "days_past_eol": 439,
  "score": 85,
  "grade": "F",
  "band": "Critical",
  "extended_support_available": true
}

What's in the box

GET /v1/score/:slug/:version - risk score for a specific version
GET /v1/status/:slug/:version - simple is-it-supported check for CI gates
POST /v1/batch - score your whole stack in one call
GET /v1/metrics?stack=nodejs:18,python:3.8 - Prometheus exposition format, ready to scrape into Grafana
GET /v1/badge/:slug/:version - Shields.io endpoint badges for your README
OpenAPI 3.0 spec - import into Postman/Insomnia or generate a client

Limits

Anonymous: 100 requests/day. A free API key (emailed instantly, no card) raises that to 500/day. Paid tiers exist for production volumes.

Lifecycle data is served live from endoflife.date cycle data (cached at the edge), with our own scoring layer on top: EOL recency, attack-surface weighting, CISA KEV mapping, and extended-support vendor coverage.

A CI example

Fail a pipeline when anything in the stack goes EOL:

STATUS=$(curl -s https://api.endoflife.ai/v1/status/nodejs/18 | jq -r .is_eol)
if [ "$STATUS" = "true" ]; then
  echo "::error::Node 18 is past end-of-life"
  exit 1
fi

(There's also a ready-made GitHub Action, a VS Code extension, and an MCP server if you'd rather your AI agent checks for you.)

Docs and live playground: endoflife.ai/api

Questions or weird edge cases? Comments welcome.

endoflife.ai is now available as an MCP server

endoflife-ai — Tue, 30 Jun 2026 15:19:43 +0000

AI agents can now query software end-of-life dates and EOL Risk Scores directly from endoflife.ai — 459+ products, 8,000+ versions, updated daily.

Connect it in one line:

{ "mcpServers": { "endoflife": { "url": "https://mcp.endoflife.ai" } } }

Ask your agent "is Node 18 still supported?" or "what's the risk score for PostgreSQL 14?" and get a live answer pulled from our dataset — including whether the product appears on CISA's Known Exploited Vulnerabilities list.

No API key required. Full docs at https://endoflife.ai/mcp