DEV Community: endoflife-ai

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

Ember.js End of Life: The LTS Cadence & Every Version EOL Date

endoflife-ai — Fri, 26 Jun 2026 17:39:19 +0000

Originally published on endoflife.ai.

Ember.js moves on a steady release train, designating Long-Term Support (LTS) releases on a regular cadence — which means older versions reach end of life just as steadily. As of now, Ember 6.x is the current line, with 6.8 and later supported; Ember 6.4 reached EOL on June 21, 2026, and every 5.x release and earlier is end of life, including the once-ubiquitous 3.28 LTS.

Ember version EOL schedule

Version	End of Life	Status	Risk Score
Ember ≤ 4.x	2023 – 2024	EOL	60
Ember 5.4 (LTS)	Dec 22, 2024	EOL	55
Ember 5.8 (LTS)	Jun 15, 2025	EOL	50
Ember 5.12 (LTS)	Oct 12, 2025	EOL	50
Ember 6.4 (LTS)	Jun 21, 2026	Just EOL	35
Ember 6.8 (LTS)	Dec 7, 2026	Supported	20
Ember 6.11+ (latest)	Active	Current	20

How Ember's LTS cadence works

Ember releases on a roughly six-week train and periodically blesses a release as LTS. The LTS releases are what most teams target — they get a longer, fixed support window than the six-week releases. When that window ends, the LTS (and everything before it) is EOL.

A new LTS arrives roughly every couple of quarters, and an older one drops off at a similar rhythm. Like Angular, Ember rewards a standing upgrade habit: stay on the current or immediately-previous LTS and upgrades are small; let several windows pass and the gap compounds.

Target the LTS, not the bleeding edge. Pin to the most recent LTS (or the one just behind it with an upgrade scheduled), put its EOL date in your roadmap, and move before it lands.

The Octane shift — why 3.x apps got stuck

The reason so many Ember apps are stranded years back isn't the cadence — it's Octane. Ember Octane (default in the 3.x series) modernised Ember substantially: Glimmer components, tracked properties, native classes, and a move away from the classic object model. A genuine improvement, but it changed enough idioms that migrating a large classic-Ember app is real work.

Many teams paused on a late classic 3.x release — 3.28 being the common resting point — and never jumped. Those apps are now multiple majors and several years past EOL (3.28 has been EOL since January 2023).

Ember 6.x — the supported line

Ember 6.8 LTS (supported through December 2026) is the conservative target; the latest release (6.11+) carries the newest features and longest runway. Both score 20 (Low). Modern Ember is Octane-by-default and considerably leaner than the 3.x-era apps people remember.

Upgrading with ember-cli-update

Find your version and LTS gap. ember --version + package.json, cross-referenced against the table.
Run ember-cli-update, one LTS at a time. It migrates files/config toward a target and surfaces diffs to resolve. Step LTS to LTS rather than jumping the whole gap.
Clear deprecations before each major. Ember's deprecation warnings are your migration checklist.
Adopt Octane idioms where you're still classic. Glimmer components, tracked properties, native classes — codemods handle much of it.
Update addons in lockstep. A lagging addon is the most common blocker; replace any that are abandoned.

Stranded on classic Ember?

Apps pinned to 3.28 or earlier sometimes need a real, scheduled project to reach a supported 6.x — the Octane jump plus the version gap is genuine work. Extended support can keep an EOL Ember app patched in the interim.

Full guide, live per-LTS Risk Scores, and the rest of the framework lifecycle data at endoflife.ai. Check your whole stack free with the Stack Scanner.

Bootstrap End of Life: EOL Dates & the jQuery Problem

endoflife-ai — Fri, 26 Jun 2026 17:38:26 +0000

Originally published on endoflife.ai.

Bootstrap is one of the most widely deployed front-end frameworks on the web — and most of that deployment is on versions that are end of life. Bootstrap 5 is the only maintained line (Risk Score 20, Low). Bootstrap 4 reached end of life on December 31, 2022, Bootstrap 3 back in July 2019, and Bootstrap 2 over a decade ago — yet millions of production sites still run 3 and 4.

And Bootstrap carries a risk most CSS frameworks don't: Bootstrap 3 and 4 depend on jQuery, so running them means running a second end-of-life dependency.

Bootstrap version EOL schedule

Version	End of Life	Status	Risk Score
Bootstrap 2	Aug 18, 2013	EOL	60
Bootstrap 3	Jul 23, 2019	EOL	60
Bootstrap 4	Dec 31, 2022	EOL	60
Bootstrap 5 (current)	Maintained	Supported	20

The real risk of EOL Bootstrap

Bootstrap is mostly CSS, so how dangerous is an EOL version really? Less acutely dangerous than an EOL database or runtime, but not zero — and concentrated in three places:

The JavaScript components. Tooltips, popovers, modals, the data-attribute API process input and write to the DOM. Older Bootstrap had real XSS vulnerabilities in exactly these (the data-* sanitizer in particular), patched in later 3.x/4.x point releases. Pinned to an old minor? You may be missing those fixes, with no more coming.
The frozen ecosystem. EOL Bootstrap locks you to themes, plugins, and build tooling that are themselves unmaintained — and, for 3/4, to a specific old jQuery.
Browser drift. Layout/behaviour bugs accumulate as browsers evolve, never to be fixed upstream.

The jQuery problem in Bootstrap 3 & 4

Bootstrap 3 and 4 require jQuery — Bootstrap 5 removed it entirely. So an EOL Bootstrap 3/4 site is almost always also shipping jQuery, usually an old one. Any jQuery below 3.5.0 carries known XSS (CVE-2020-11022/11023). "We're just on old Bootstrap" frequently means "we're also serving vulnerable jQuery" — two EOL dependencies for the price of one.

Upgrading to Bootstrap 5 isn't only a CSS modernisation — it removes the jQuery dependency (Bootstrap 5's JS is vanilla), eliminating an entire class of EOL exposure in one move. See the jQuery EOL guide for which jQuery versions are dangerous.

Bootstrap 5 — the maintained line

Bootstrap 5 is the only line still receiving updates (Risk Score 20). It dropped jQuery for vanilla JS, added a CSS custom-properties layer, expanded the utility API, and added built-in RTL support. Moving Bootstrap 4 → 5 also sheds the jQuery liability — the rare upgrade that reduces your dependency count rather than growing it.

Migrating to Bootstrap 5

Confirm which Bootstrap (and jQuery) you ship. Check your bundle, not your package.json — old Bootstrap hides in vendored CSS and CMS themes.
Update the class names. ml-*/mr-* → ms-*/me-*, .no-gutters → .g-0, .custom-* form classes folded into .form-*, and data-* gained a bs- prefix (data-bs-toggle). Mostly find-and-replace.
Remove jQuery-dependent JavaScript. Replace $('...').modal()-style calls with the Bootstrap 5 JS API; audit your own code so you can drop jQuery entirely.
Re-test interactive components and responsive layouts. Modals, dropdowns, tooltips, the grid, custom themes. Note: Bootstrap 5 dropped IE support.
Adopt the new layers as you go. Lean on CSS custom properties and the utility API to retire bespoke overrides.

Full guide and live data at endoflife.ai. Bootstrap rarely travels alone — scan your whole front-end free with the Stack Scanner.

jQuery End of Life: What's Actually EOL (and What Isn't)

endoflife-ai — Fri, 26 Jun 2026 17:37:22 +0000

Originally published on endoflife.ai.

Let's clear up the most-searched question first: jQuery is not end-of-life. jQuery core is still actively maintained — the 3.x line gets security releases and 4.x is the modern successor. On the EOL Risk Score, jQuery sits at just 20 (Low).

But that headline hides the real problem. The parts of the jQuery ecosystem most sites depend on are end-of-life: jQuery 1.x and 2.x got no releases since 2016, jQuery UI reached EOL on August 5, 2024, and jQuery Mobile was archived years ago. And the catch the Low score doesn't capture — old jQuery versions carry known, patchable XSS vulnerabilities.

jQuery core versions — what's maintained

Version	Maintenance reality	Status	Risk Score
jQuery 1.x	No releases since 1.12.4 (May 2016)	Unmaintained	20
jQuery 2.x	No releases since 2.2.4 (May 2016)	Unmaintained	20
jQuery 3.x	Maintained · latest 3.7.1	Maintained	20
jQuery 4.x	Newest line · drops legacy IE	Current	20

"No EOL date" ≠ "no updates." jQuery 1.x/2.x have a Low score because jQuery never formally declared them EOL — but the project stopped shipping releases for both in May 2016. In practice they're unmaintained; the only supported path is 3.x or 4.x.

The real risk: old versions, known CVEs

The EOL Risk Score measures lifecycle status. It doesn't track version-specific vulnerabilities — and jQuery has well-known ones fixed in specific releases:

CVE-2020-11022 and CVE-2020-11023 — XSS flaws fixed in jQuery 3.5.0 (April 2020). Any jQuery older than 3.5.0 — all of 1.x/2.x and early 3.x — is vulnerable.
CVE-2019-11358 — prototype pollution via jQuery.extend, fixed in jQuery 3.4.0.

If you're running jQuery below 3.5.0, you're shipping known XSS to your users. The fix is free: upgrade to current 3.x (3.7.1) or 4.x.

This is the same blind spot covered in the CVE blind spot — lifecycle status and CVE exposure are two different axes, and you have to check both.

jQuery UI & jQuery Mobile — the EOL pieces

Unlike jQuery core, jQuery UI is genuinely end-of-life — dated to August 5, 2024, with a Risk Score of 55 (Elevated). The widget library (datepickers, dialogs, autocomplete) is no longer developed. jQuery Mobile went further — archived and deprecated years ago.

Replacements: modern component libraries or native HTML (<dialog>, <input type="date">) cover most jQuery UI use cases.

How to fix it

Find which jQuery version you actually ship. jQuery.fn.jquery prints the loaded version in the console. Anything below 3.5.0 is a priority.
Add jQuery Migrate. It restores deprecated APIs and logs every deprecation your code hits — a checklist from your real usage. Use it as a temporary bridge.
Upgrade to current jQuery 3.x (3.7.1). Closes the known XSS CVEs; most compatible target.
Replace jQuery UI and jQuery Mobile. Separately EOL — swap for maintained components or native controls.
Consider whether you still need jQuery. Much of what it was indispensable for is now native (querySelectorAll, fetch, classList). The goal is "patched," not necessarily "removed."

Full guide and live data at endoflife.ai. Scan your front-end free with the Stack Scanner.

Angular End of Life: The 18-Month Treadmill & Every EOL Date

endoflife-ai — Fri, 26 Jun 2026 17:36:09 +0000

Originally published on endoflife.ai.

Angular — the TypeScript framework, versions 2 through 21 — has one of the shortest support windows in mainstream front-end development: roughly 18 months per major version. A new major ships about every six months, so a version reaches end of life every six months too. Right now, Angular 19 has already reached EOL (May 18, 2026), and only Angular 20 and 21 are still supported.

This is a different product from AngularJS (1.x), which is a separate, fully end-of-life framework. Don't confuse the two — this covers modern Angular (2+).

Angular version EOL schedule

Version	End of Life	Status	Risk Score
Angular ≤ 15	2021 – May 2024	EOL	70
Angular 16	Nov 7, 2024	EOL	65
Angular 17	May 14, 2025	EOL	65
Angular 18	Nov 20, 2025	EOL	60
Angular 19	May 18, 2026	Just EOL	55
Angular 20	Nov 27, 2026	Supported	38
Angular 21 (latest)	May 18, 2027	Supported	30

The 18-month support policy

Each major version gets about 18 months of support, split in two: 6 months of active support (regular updates and bug fixes) then 12 months of LTS (critical and security fixes only). After that, the version is EOL.

A new major ships roughly every six months. Do the arithmetic: with a release twice a year and an 18-month window, there are only ever about three supported majors at once — and one drops off every six months. Skip two cycles and you're already on borrowed time.

This is why Angular apps fall behind faster than any other framework. A team that ships on the current Angular and then focuses on features for a year finds itself two versions back and approaching EOL without changing a line of framework code. Angular demands a standing upgrade habit, not a one-time migration.

Angular 20 & 21 — the supported versions

Angular 21 is the current release and the right target for any upgrade today — longest runway (to May 2027) and the lowest Risk Score in the line. Angular 20 is supported through November 2026 and is a reasonable interim stop.

Modern Angular has reduced upgrade pain: standalone components removed NgModule boilerplate, the new control-flow syntax and signals modernised templates and reactivity, and ng update automates most of the mechanical migration between adjacent majors. The rule: there's no "settle here for years" version. Pick the latest, and budget a recurring upgrade every 6–12 months.

How to stay current with ng update

Find your version and the gap. Run ng version, cross-reference the table, see how many majors behind you are.
Upgrade one major at a time. Use the Angular Update Guide and run ng update @angular/core@N @angular/cli@N for each successive major — don't skip, the schematics run between adjacent versions.
Let the schematics do the refactors. ng update runs code migrations automatically — review each diff rather than rubber-stamping.
Update the ecosystem in lockstep. Angular Material, NgRx, and third-party libraries track Angular's majors — a lagging library is the most common blocker.
Make it a standing schedule, not a project. Put the next two EOL dates in your roadmap and upgrade before each one.

Stranded several majors back?

Plenty of production apps are stuck on Angular 12–16 because an upgrade was deferred until the gap became daunting. Those apps run EOL framework code (Risk Scores 60–70). Extended support maintains security-patched builds of older Angular majors so a stranded app stays protected while you plan a staged path back.

Full guide, live Angular Risk Scores, and the rest of the framework lifecycle data at endoflife.ai. Check your whole stack free with the Stack Scanner.

Vue 2 End of Life: EOL Date, Risk, and Migration to Vue 3

endoflife-ai — Fri, 26 Jun 2026 17:34:30 +0000

Originally published on endoflife.ai.

Vue 2 reached end of life on December 31, 2023. Since then, the Vue core team has issued no further updates — no bug fixes, and critically, no security patches. The final Vue 2 release, Vue 2.7 ("Naruto"), is the last version that will ever ship. If you're still running Vue 2 in production — and many teams are — every vulnerability discovered from 2024 onward stays open unless you patch it yourself or buy extended support.

Vue version EOL schedule

Version	End of Life	Status	Risk Score
Vue 2.6	Jun 30, 2022	EOL	70
Vue 2.7 (final Vue 2)	Dec 31, 2023	EOL	70
Vue 3.3	Dec 28, 2023	EOL	70
Vue 3.4	Sep 2, 2024	EOL	65
Vue 3.5 (current)	Active	Supported	30

All of Vue 2 is past end of life. Vue 2.7 — the final and most-deployed Vue 2 release — stopped receiving security patches on December 31, 2023. If you're on any Vue 2 release, you're running unsupported, unpatched front-end code that ships to every one of your users' browsers.

Why Vue 2 EOL is a real security problem

It's tempting to treat a front-end framework as lower-risk than a database or OS — it runs in the browser, not your servers. That's wrong in two ways:

Client-side code is directly attacker-facing. Vue renders untrusted data into the DOM. Framework-level vulnerabilities — XSS through template compilation, prototype pollution in reactivity — execute in your users' sessions.
The dependency tree ages with it. Vue 2 pins you to Vue CLI, vue-router 3, Vuex 3, and a generation of component libraries that are themselves EOL and often won't run on current Node.js.

Vue 2.7 — the final release

Vue 2.7 was a deliberate bridge release. It backported the Composition API, <script setup>, and improved TypeScript support into the Vue 2 runtime, so teams could start writing Vue-3-style code before migrating. That makes 2.7 the best launchpad for a Vue 3 move — but it's still end-of-life. The security clock ran out December 31, 2023 regardless of API style.

On an older Vue 2 minor (2.6 or earlier)? Upgrade to 2.7 first — smallest possible step, still within Vue 2, and it sets up the Vue 3 migration with far less rework.

Migrating from Vue 2 to Vue 3

Vue 3 is a ground-up rewrite, not a drop-in upgrade. Reactivity moved from Object.defineProperty to ES Proxy, the global API changed (new Vue() → createApp()), and several patterns were removed. The official migration build (@vue/compat) runs Vue 3 in Vue-2-compatible mode and flags each incompatibility.

Get to Vue 2.7 and latest dependencies first. Update vue-router, Vuex, and component libraries; adopt the Composition API where practical — that code transfers to Vue 3 almost unchanged.
Switch to @vue/compat. It boots your app in compatibility mode and emits a console warning for every deprecated pattern — your migration to-do list, generated from your real code.
Clear the warnings, one category at a time. Global API (createApp), filters (removed), v-model changes, event-bus removal ($on/$off are gone), functional-component syntax.
Upgrade the ecosystem. vue-router 4, Pinia (successor to Vuex), Vue-3-compatible component libraries. Third-party libraries are usually the biggest blocker.
Drop compat mode and ship on native Vue 3. Pin to the latest Vue 3 minor and keep current — only the newest minor gets fixes.

Can't migrate yet?

For a large Vue 2 app, migration is a real project — often gated on third-party libraries you don't control. That's a legitimate reason it hasn't happened, but not a reason to ship unpatched XSS. Extended (post-EOL) support maintains security-patched forks of Vue 2 and its ecosystem so you stay protected while migrating on a realistic timeline.

Full guide, live Vue Risk Scores, and the rest of the framework lifecycle data at endoflife.ai. Check your whole front-end with the free Stack Scanner.

The State of End-of-Life Software 2026: 32 of 459 Technologies Have Active CVEs

endoflife-ai — Fri, 26 Jun 2026 17:32:59 +0000

Originally published on endoflife.ai.

Every day, endoflife.ai rebuilds a risk picture of the software the world actually runs — 459 technologies, every tracked release scored 0–100 for how dangerous it is to keep running past its support date. This is the June 2026 snapshot of that data: which technologies are most exposed, where end-of-life software intersects with vulnerabilities attackers are already exploiting, and the calendar of major releases going dark this year.

The headline finding isn't that old software exists — it always has. It's where the risk concentrates: the most exposed end-of-life technologies aren't obscure libraries, they're the infrastructure everything else is built on.

Metric	Value
Technologies tracked & scored daily	459
Tied to actively-exploited vulnerabilities (CISA KEV)	32
In the Critical risk band (80–100)	30
With a release reaching EOL during 2026	190

How we measure it — the EOL Risk Score

Every number comes from a 0–100 score computed from four weighted factors:

EOL Recency (0–40) — how long a release has been past end of life.
Attack Surface (0–30) — how widely deployed and exposed the technology is.
CISA KEV Exposure (0–20) — whether it appears in CISA's Known Exploited Vulnerabilities catalog (confirmed active attack).
Extended Support (0–10) — whether a vendor or third party still offers paid patches.

Each technology's headline score reflects its most recently end-of-lifed release — the version a typical lagging deployment is most likely still running. Across all 459, the mean score is 52/100.

The dangerous intersection: EOL meets active exploitation

End-of-life software is a theoretical risk until it meets a real exploit. That's what makes the CISA KEV factor the most important signal — it separates "old but quiet" from "old and being attacked right now."

32 of 459 technologies (7%) are tied to actively-exploited vulnerabilities. And they're not edge cases — it's a roll-call of core infrastructure: Windows, Windows Server, Linux Kernel, RHEL, Debian, Ubuntu, CentOS, Python, Node.js, PHP, PostgreSQL, MySQL, MariaDB, MongoDB, Redis, Elasticsearch, OpenSSL, nginx, Apache Tomcat, Kubernetes, Docker Engine, Jenkins, GitLab, WordPress, Drupal, Joomla, SharePoint, Spring Framework, Spring Boot, Android, iOS, and macOS.

29 of the 30 highest-scoring technologies carry KEV exposure. An unsupported obscure CMS plugin is a contained problem. An unsupported OpenSSL, Linux kernel, or Kubernetes is a systemic one.

The 30 most critical technologies

Technology	Latest retired release	Active exploits	Risk Score
Docker Engine	May 19, 2025	In KEV	95
Windows Server	Oct 24, 2025	In KEV	90
Windows	Nov 11, 2025	In KEV	90
Apache Tomcat	Mar 31, 2024	In KEV	90
Python	Oct 31, 2025	In KEV	90
PostgreSQL	Nov 13, 2025	In KEV	90
MongoDB	Sep 30, 2025	In KEV	90
macOS	Feb 2, 2026	In KEV	90
Kubernetes	Feb 28, 2026	In KEV	90
iOS	Jan 26, 2026	In KEV	90
Elasticsearch	Jan 15, 2026	In KEV	90
Android	Mar 2, 2026	In KEV	90
RHEL	Jun 30, 2024	In KEV	85
Redis	May 25, 2026	In KEV	85
OpenSSL	Apr 9, 2026	In KEV	85
Node.js	Apr 30, 2026	In KEV	85
MySQL	Apr 30, 2026	In KEV	85
MariaDB	May 13, 2026	In KEV	85
Linux Kernel	Apr 22, 2026	In KEV	85
Debian	Aug 14, 2024	In KEV	85
CentOS	Jun 30, 2024	In KEV	85
Ubuntu	Jan 17, 2026	In KEV	80
Spring Framework	Jun 30, 2025	In KEV	80
Spring Boot	Dec 31, 2025	In KEV	80
SharePoint	Apr 11, 2023	In KEV	80
PHP	Dec 31, 2025	In KEV	80
Joomla	Oct 14, 2025	In KEV	80
Jenkins	Jan 21, 2026	In KEV	80
Drupal	Dec 10, 2025	In KEV	80
Amazon Linux	Dec 31, 2023	—	80

Docker Engine tops the list at 95/100 — a long-retired release, an enormous attack surface, and confirmed active exploitation.

The 2026 end-of-life calendar

190 technologies have a release reaching EOL in calendar 2026 — and 16 of those score 75+. The high-risk roster:

2026 EOL date	Technology	Risk Score
Jan 15	Elasticsearch	90
Jan 17	Ubuntu	80
Jan 21	Jenkins	80
Jan 26	iOS	90
Feb 2	macOS	90
Feb 28	Kubernetes	90
Mar 2	Android	90
Apr 9	OpenSSL	85
Apr 22	Linux Kernel	85
Apr 30	MySQL	85
Apr 30	Node.js	85
May 13	MariaDB	85
May 13	nginx	75
May 20	WordPress	75
May 21	GitLab	75
May 25	Redis	85

The first half of 2026 alone retired high-risk releases across the database tier (MySQL, MariaDB, Redis, Elasticsearch), the runtime tier (Node.js, OpenSSL), orchestration (Kubernetes), and OS (Ubuntu, Linux, iOS, macOS, Android).

What it means for your stack

The risk is concentrated, not diffuse. You don't need to audit 459 technologies — just which of the 30 critical ones (and 32 with active exploits) are in your environment, and which version.
EOL is predictable; breaches from it aren't. Every date above was published years ahead. Put each EOL date in your roadmap the day you deploy.
"Newer" isn't always "safer." Some technologies ship short-lived releases that EOL within months — a higher version number can be less supported.

Full interactive tables, live scores, and every technology's page are at endoflife.ai. The same data is free via the API and the Stack Scanner. Data rebuilt daily from the endoflife.date open dataset plus CISA KEV.

MySQL 8.0 is now end-of-life — here's the version map you actually need

endoflife-ai — Thu, 18 Jun 2026 19:30:52 +0000

MySQL 8.0 reached end of life on April 30, 2026. That's the one that matters: 8.0 has been the default MySQL since 2018, so a huge share of production databases just stopped getting security patches from Oracle. If mysql:8.0 is anywhere in your stack, you're now running unsupported software.

Here's the version map, with EOL Risk Scores (0–100) from endoflife.ai:

Version	Type	EOL	Status	Risk
MySQL 5.5	Legacy	Dec 31, 2018	EOL	90
MySQL 5.6	Legacy	Feb 28, 2021	EOL	90
MySQL 5.7	Legacy	Oct 31, 2023	EOL	90
MySQL 8.0	Series	Apr 30, 2026	EOL	75
MySQL 8.4	LTS	Apr 30, 2032	Current LTS	50

The Innovation-vs-LTS trap

This is the part that catches people. In 2023 Oracle split MySQL into two release tracks, and the version number no longer tells you how long a release is supported.

LTS releases (currently 8.4) get ~8 years of support. This is what you run in production.
Innovation releases (8.1, 8.2, 8.3, and the entire 9.x series) ship quarterly and are supported only until the next release lands — roughly three months each.

So MySQL 9.2 looks newer than 8.4, but 8.4 is supported into 2032 while 9.2 went EOL within months. MySQL 9.0 reached EOL back in October 2024. If you adopted a 9.x release and aren't upgrading every single quarter, you're already on an EOL build with a Critical-tier risk profile.

Rule of thumb: unless quarterly upgrades are genuinely part of your ops model, stay on the LTS (8.4) and let the new features arrive in the next LTS.

What to do

On 8.0? Upgrade to 8.4 LTS — it's the supported, in-place path Oracle designed for exactly this transition.
On 5.7? Bigger jump. Plan straight to 8.4, using 8.0 as a compatibility checkpoint, not a destination. Watch the caching_sha2_password default, SQL mode changes, and the data dictionary migration.
Run the check first: mysqlsh → util.checkForServerUpgrade() against a staging copy surfaces deprecated syntax, removed features, and collation changes before you commit.
Managed MySQL (RDS, Aurora, Azure, Cloud SQL) tracks these dates differently — some extend past Oracle's community EOL, some don't. Confirm your provider's specific dates.

Check your whole stack, not just MySQL

MySQL is one clock. Your OS, runtime, and other dependencies each have their own. You can score your full dependency file at once with the free Stack Scanner (no signup), or read the complete version-by-version breakdown here:

Full guide: MySQL End-of-Life Dates — every version

Dates and risk scores sourced from the open endoflife.date dataset; risk scoring and CISA KEV cross-reference by endoflife.ai.

Every Software EOL Date That Matters in 2026 — One Reference

endoflife-ai — Mon, 15 Jun 2026 09:22:55 +0000

We maintain a full reference of 124 versions across 44 products — here are the dates that actually deserve a calendar reminder in 2026.

Just happened

Debian 12 "Bookworm" reached end of life on June 10, 2026. Regular security support has ended; the volunteer LTS team now covers only ~230 packages. If debian:12 is in your Dockerfiles, every image you build from here on has an EOL base layer. Action guide here.

The big dates still ahead in 2026

Date	What dies	Why it hurts
Sep 18, 2026	Oracle JDK 26	Short-lived non-LTS — teams that jumped early get caught
Sep 30, 2026	Java 17 LTS (Premier)	Still one of the most-deployed JDKs in production
Oct 31, 2026	Python 3.10	One of the most-used Python versions; 3.11 follows Oct 2027
Nov 9, 2026	Windows 11 23H2 (Enterprise)	The next Windows migration wave after the Win10 cliff
Dec 31, 2026	PHP 8.2	With 8.1 already EOL, only 8.3+ survives into 2027

Already EOL — and still everywhere

These are past their dates and still show up constantly in production scans:

Node.js 18 and 20 — both EOL (Apr 2025 / Apr 2026). Node 22 LTS is the floor now.
Spring Boot 2.7 — EOL since 2023, still the most common Spring version in legacy estates.
PHP 8.1 — EOL Dec 2025.
Veeam 11 & 12.0 — backup infrastructure running unpatched is its own special category of bad.
CentOS 7/8 — fully discontinued; no vendor to buy support from (third-party extended support is the only patch path).
Ubuntu 20.04 — out of standard support; Ubuntu Pro or migration.

The pattern worth internalizing

EOL events cluster. June 2026 alone had Debian 12, Debian 11 LTS (June 30), and Kubernetes versions aging out in the same window. If your stack touches five ecosystems, you have five independent clocks — and none of them email you.

The full sortable reference (124 versions, updated at every deploy, with risk scores and add-to-calendar reminders per product): endoflife.ai/article-eol-dates-2026

Or check your whole dependency file at once with the Stack Scanner — free, no signup.

EOL, EOS, LTS, CVE — Every Software Lifecycle Term, Explained Like You're New Here

endoflife-ai — Thu, 11 Jun 2026 22:02:14 +0000

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 flaw found after that date stays open forever, on every system still running it.

This guide assumes zero prior knowledge. By the end you'll be able to read any vendor lifecycle page without a translator.

The life of a piece of software

Every version moves through the same phases, whatever the vendor calls them:

Phase	What it means	What you get
Release (GA)	Declared production-ready	Features, bug fixes, security patches
Active support	The healthy middle of life	Fixes and patches
Maintenance / security-only	The wind-down	Security patches only
End of life (EOL)	The maker walks away	Nothing, ever again
Extended support	Paid overtime	Security patches past EOL, for a price

The crucial point: software doesn't stop working at EOL. Nothing visibly breaks, so nothing prompts action — while security holes quietly accumulate. That's exactly what makes it dangerous.

The acronym decoder

EOL (End of Life) — the maker stops all fixes. The big one.
EOS — usually a synonym for EOL; occasionally "end of sale." Check which a vendor means.
EOSL (End of Service Life) — the hardware version: switches, servers, storage.
GA (General Availability) — the official release date. The lifecycle clock starts here.
LTS (Long-Term Support) — a version promised support for years. What you run in production.
STS — short-term support, for early adopters. Oracle calls these "Innovation Releases."
ELS / ESU / ELTS — vendor names for paid post-EOL support (Red Hat / Microsoft / Debian respectively). Same idea, different logos.
CVE (Common Vulnerabilities and Exposures) — the global ID system for security flaws (CVE-2026-12345).
CVSS — the 0–10 severity score on each CVE. 9+ is critical.
NVD — the US government's public catalog of all CVEs. Attackers read it too.
KEV (Known Exploited Vulnerabilities) — CISA's list of CVEs actively used in real attacks.
SBOM (Software Bill of Materials) — the ingredient list of your software. What makes EOL auditing possible at scale.
SCA (Software Composition Analysis) — dependency scanners. Useful, but most don't flag EOL status.

What's actually in a "stack"?

Each layer has its own EOL clock. Bottom-up:

Operating system / distribution — Windows, macOS, or a Linux distro (Ubuntu, Debian, RHEL): the kernel plus thousands of tools, versioned and supported as one product. When Debian 12 hits EOL, the whole bundle stops getting coordinated fixes.

Runtime — the engine that executes your code. JavaScript needs Node.js; Python code needs the Python interpreter; Java needs the JDK. You don't write a runtime — you write code that runs on one. High-stakes EOL items, because runtimes process untrusted input.

Framework — a pre-built application skeleton: Django, Rails, Spring Boot, Laravel. A framework rides on a runtime — a Django app needs both Django and Python in support. Two clocks; either expiring exposes you.

Library / dependency — smaller building blocks pulled in by a package manager (npm, pip, Composer). Modern apps use hundreds. Each can be abandoned by its maintainer — EOL without a press release. (The classic distinction: your code calls a library; a framework calls your code.)

Database — PostgreSQL, MySQL, MongoDB. Holds the crown jewels; EOLs on long cycles, which lulls teams into forgetting it.

Containers & base images — FROM debian:12 bakes Debian 12's EOL clock into every container you build, even brand-new deployments.

Firmware/hardware — the layer organizations track least. See EOSL above.

How version numbers work

Most software uses major.minor.patch (Python 3.11.9). EOL almost always applies to the major.minor line — "Python 3.11 is EOL" means every 3.11.x, and no 3.11.10 will ever ship. Patch upgrades are routine hygiene; crossing minor/major lines is a migration. That's why teams pin versions — and why pinned versions quietly age into EOL.

Why this matters: the CVE blind spot

A zero-day is a flaw nobody knows about — scary but rare, and it gets patched once found. EOL software inverts this: the flaw is public — documented on the NVD, scored, often with 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 scanners give EOL software a clean bill of health, because they check for known unpatched CVEs — not for the fact that the patch pipeline itself is dead.

If you can't upgrade in time

Extended support keeps patches flowing past EOL. It comes from the maker (Red Hat ELS, Ubuntu Pro, Microsoft ESU) or from third parties such as TuxCare, which patch software the maker has abandoned entirely — CentOS being the canonical case, fully discontinued with no vendor program at all. Either way: it's a bridge to a planned migration, not a destination.

Where to start

Every layer of your stack has an expiry date, nothing announces itself when it passes, and the fix is knowing the dates before they arrive. Look up any of 455+ products free at endoflife.ai — or scan a whole dependency file at once with the Stack Scanner. No signup.

Oracle Database End-of-Life Dates — Premier & Extended Support for Every Version

endoflife-ai — Tue, 09 Jun 2026 16:47:56 +0000

If you've ever tried to answer the simple question "when does my Oracle Database version go end of life?" you've probably discovered there's no single date. Oracle doesn't do "EOL" the way Linux distros or runtimes do. Instead, every release moves through three support phases — and one of them sounds supportive but quietly leaves you with zero new security patches.

Here's the whole picture in plain language.

The short version: Oracle 19c is the safe long-term release (Premier Support to Dec 31, 2029, Extended to Dec 31, 2032). 23ai (now branded 26ai) is the newest long-term release. Oracle 18c, 12c, and 11g are all past support and receive only Sustaining Support — which means no new CVE patches.

The Oracle Lifetime Support table

Release	GA Release	Premier Support Ends	Extended Support Ends	Status
23ai / 26ai (LTR)	2023–2024	Dec 31, 2031	Available	✅ Active
21c (Innovation)	Aug 13, 2021	Jul 31, 2027	None	✅ Active
19c (LTR)	Apr 25, 2019	Dec 31, 2029	Dec 31, 2032	✅ Active · Recommended
18c	Jul 23, 2018	Jun 30, 2021	None	❌ EOL
12c Release 2 (12.2)	Mar 1, 2017	Mar 31, 2022	None	❌ EOL
12c Release 1 (12.1)	Jun 25, 2013	Jul 31, 2018	Jul 31, 2022	❌ EOL
11g Release 2	Sep 1, 2009	Jan 31, 2015	Dec 31, 2020	❌ EOL

The three phases (and the one that fools people)

Premier Support — the first ~5 years for a Long-Term Release. Full coverage: bug fixes, security patches, Critical Patch Updates, new certifications. This is what you want to be on.

Extended Support — an optional paid add-on, available only for Long-Term Releases, that extends full coverage for up to 3 more years. Oracle has sometimes waived the first year's fee. Innovation Releases (like 21c) don't get this at all.

Sustaining Support — offered indefinitely, which is exactly why it's misleading. It includes no new security patches, no bug fixes, no error corrections, and no new certifications — just access to patches that already existed and the knowledge base.

⚠️ This is the trap: Oracle can say a release is "still supported" when it's actually on Sustaining Support — getting no new CVE fixes. If you're past your Extended Support date, you are running unpatched. Your vulnerability scanner won't necessarily flag it, because the CVE affected-version ranges often don't list your ancient release. That's the CVE blind spot.

Long-Term vs Innovation Releases

Since 19c, Oracle splits releases into two tracks:

Long-Term Releases (LTR) — e.g. 19c and 23ai. ~5 years Premier + up to 3 years Extended. Standardize production here.
Innovation Releases — e.g. 21c. ~2 years Premier, no Extended. Great for kicking the tires on new features, bad for systems you'll run for years.

What about 23ai... 23c... 26ai?

Yes, the naming is a mess. It launched as 23c, was renamed 23ai to highlight its built-in AI features (like AI Vector Search), and the release line was later rebranded 26ai — while keeping 23 as the internal version number. It's a Long-Term Release with Premier Support through December 31, 2031, and it's the target if you want the longest runway on a new deployment.

If you're on 11g, 12c, or 18c

You've been running without new security fixes for years (11g since 2020, 12c since 2022, 18c since 2021). Your options:

Upgrade to a Long-Term Release — 19c (most proven) or 23ai (newest). Oracle's AutoUpgrade tool handles most paths.
Buy Extended Support — only available for LTRs (e.g. 19c through 2032), as a paid bridge while you migrate.
Third-party / Market-Driven Support — can patch versions Oracle no longer will, but it's a stopgap, not a destination.

Check your exact version with:

SELECT BANNER_FULL FROM V$VERSION;

TL;DR

If you're on 19c, you're fine until at least 2029. If you're on 18c, 12c, or 11g, you're effectively end of life and unpatched — plan a move to 19c or 23ai now.

I keep a live, always-updated version of this — with every Oracle Database version, its support phase, and a 0–100 EOL Risk Score — here: Oracle Database EOL dates on endoflife.ai. You can also check any other product (Node, Python, PHP, RHEL, Kubernetes, 450+ more) at endoflife.ai.

Your EOL Dates Are Deadlines. Now They Live on Your Calendar.

endoflife-ai — Sat, 06 Jun 2026 11:53:07 +0000

Originally published on endoflife.ai.

An end-of-life date is a deadline. On one side of it, your software receives security patches. On the other side, it does not — permanently. Every vulnerability discovered after that date is disclosed publicly, assigned a CVE, and frequently weaponized, with no fix ever coming from the vendor. This is the CVE blind spot, and it's the single most predictable security risk in any stack: you always know the exact day it begins.

And yet EOL dates slip past almost everyone. They don't trigger a scanner alert. They don't open a ticket. They aren't on anyone's sprint board. They are, quite literally, calendar events that nobody put on the calendar.

We just fixed that last part.

Add to Calendar, on every page

Every product page and version page on endoflife.ai that has a future end-of-life date now carries an Add to Calendar button, right under the status banner. One click downloads a standard calendar file (.ics) with the EOL date and three reminders already built in — 90, 30, and 7 days before the deadline. A second button drops the same event straight into Google Calendar.

It works in Apple Calendar, Outlook, and Google Calendar. There's no account, no email signup, and nothing to install — the reminders fire from your own calendar, on your own schedule, and keep working whether or not you ever return to the site. Open Node.js, PHP, Kubernetes, or any of 455+ products, pick the version you run, and the date is on your calendar in seconds.

Why 90 / 30 / 7?
The three reminders map to how migrations actually happen. 90 days out: scope the work, pick the target version, get it into a sprint. 30 days out: the migration should be in progress and testing. 7 days out: final verification — and if you're not done, time to stand up compensating controls and document them. The lead time is the difference between a planned upgrade and an emergency.

Lead time is a security control

The cost of an EOL migration is not fixed — it depends entirely on when you start. A move from Node.js 18 to a supported release, planned during a normal cycle, costs engineering time measured in days. The same move, started the week a critical CVE drops against the now-unpatchable version, costs that plus incident response, emergency change approvals, and the very real chance that an attacker got there first.

CISA puts it bluntly. Its catalog of cybersecurity Bad Practices lists the "use of unsupported (or end-of-life) software" as "dangerous and significantly elevates risk to national security, national economic security, and national public health and safety" — calling the practice "especially egregious in technologies accessible from the Internet." When the nation's cyber defense agency files something under bad practices, alongside default passwords and single-factor admin access, that's not a nudge. That's a line.

The exploitation timeline backs it up. Once a product is past EOL, any new vulnerability that lands in CISA's Known Exploited Vulnerabilities (KEV) catalog has, for you, no patch path at all — your only remediation is replacing the software outright. The earlier you see the date coming, the cheaper that replacement is.

Why auditors care about the date itself

Here's what surprises most teams: several major frameworks don't just frown on running EOL software — they require you to track lifecycle dates and hold a documented plan to act on them. The calendar reminder you just set is, in audit terms, evidence.

PCI DSS 4.0.1 — Requirement 12.3.4

The Payment Card Industry standard added a requirement aimed squarely at this. Requirement 12.3.4 mandates that all hardware and software in scope is reviewed at least once every 12 months to confirm it still receives security fixes from the vendor, to document any vendor "end of life" announcements, and to maintain a plan approved by senior management to remediate outdated technologies. It moved from best practice to mandatory on 31 March 2025, so it is now fully assessed. Requirement 6.3.3 separately requires that components be protected from known vulnerabilities via timely patching. A lifecycle calendar with lead-time reminders is precisely the artifact a QSA wants to see behind 12.3.4.

NIST SP 800-53 & FedRAMP — SA-22

Control SA-22, "Unsupported System Components," is explicit: organizations must replace components when vendor support ends, or formally arrange alternative support. Paired with SI-2 (flaw remediation), it gives assessors a direct hook. Because FedRAMP inherits the 800-53 baseline, any cloud service serving the U.S. government carries SA-22 as well — and an unsupported component without a plan becomes a POA&M item.

ISO 27001:2022 — Annex A 8.8

Control 8.8, "Management of technical vulnerabilities," was strengthened in the 2022 revision to emphasize a proactive process: maintain an asset inventory with version numbers, obtain timely information about vulnerabilities, and act. Software for which no patch can ever exist is a structural failure of exactly that control.

SOC 2 — Trust Services Criteria CC7.1

SOC 2 names no specific technologies; it tests whether your controls fit your risks. Criterion CC7.1 covers detecting new vulnerabilities and susceptibilities. An auditor will ask how you identify them — and if your answer has no process for tracking software end-of-life, that's a gap. If EOL software is then found running, the gap becomes a finding.

HIPAA Security Rule

For ePHI, the HIPAA Security Rule requires a risk analysis (45 CFR §164.308) and technical safeguards (§164.312). NIST's implementation guide, SP 800-66 Revision 2 (February 2024), frames unsupported software as an identifiable, manageable risk. OCR's enforcement consistently ties penalty severity to whether an organization knew about a risk and failed to act — which makes knowingly running EOL software the worse position to be in.

The pattern across every framework
None of these require perfect, always-current software. They require that you know your lifecycle risks and manage them deliberately — with awareness, a plan, and a timeline. EOL software that's documented, compensated, and scheduled for remediation is a managed risk. EOL software you didn't see coming is a finding.

Framework / Body	Control	What it expects regarding EOL	Severity
PCI DSS 4.0.1	Req. 12.3.4, 6.3.3	Annual review for EOL/vendor support + senior-approved remediation plan (mandatory since Mar 2025)	Critical
NIST 800-53 / FedRAMP	SA-22, SI-2	Replace unsupported components or arrange alternative support; POA&M if not	Critical
ISO 27001:2022	Annex A 8.8	Proactive vulnerability management with versioned asset inventory	High
SOC 2	TSC CC7.1	A process to detect new vulnerabilities, including lifecycle tracking	High
HIPAA	§164.308, §164.312	Risk analysis covering unsupported software; known-and-unaddressed risk raises OCR exposure	Critical
CISA	Bad Practices · KEV · BOD 22-01	EOL software named a "bad practice"; KEV entries carry fixed remediation deadlines	Critical

The reach extends beyond U.S. frameworks. The EU's GDPR Article 32 requires security measures appropriate to "the state of the art" — a standard that running years-past-EOL software plainly undercuts. For financial entities, the EU's DORA regulation (in force since January 2025) and the NIS2 Directive both impose ICT lifecycle and vulnerability-management obligations in the same spirit.

From a date to a defensible plan

A calendar reminder is the trigger. Here's the workflow it plugs into:

Know — Inventory your stack. Use the Stack Scanner on your package.json, requirements.txt, Gemfile, or container base images to map what you actually run against current EOL dates.
Prioritize — Score the risk. The EOL Risk Score weighs EOL recency, attack surface, CISA KEV exposure, and extended-support availability so you triage the dangerous components first.
Schedule — Put the dates on the calendar. For every version you depend on, hit Add to Calendar on its page. The 90/30/7-day reminders become your standing remediation timeline — the documented plan auditors ask to see.
Automate — Scale it. The endoflife.ai API exposes EOL dates for 455+ products programmatically, so you can wire lifecycle alerts into CI/CD, SBOM tooling, or your own dashboards.

The date was never the hard part. EOL dates are published years in advance; that's the entire premise of endoflife.date, the open dataset this site is built on. The hard part has always been not seeing it coming — letting a known deadline pass in silence until it surfaces as an incident, an audit finding, or both.

Now the deadline shows up where you'll actually see it: on your calendar, with enough warning to do something about it.

Check any of 455+ products, see its EOL Risk Score, and add the deadline to your calendar — free, no signup, at endoflife.ai.