EOL 2026, the Mid-Year Report: The Year the Dates Got Dangerous — and Stopped Holding Still

Published: August 10, 2026  ·  Original analysis  ·  Every claim below traces to a primary source — the live CISA KEV catalog (downloaded August 10, 2026), vendor lifecycle pages fetched the same day, the EUR-Lex text of the Cyber Resilience Act, and our own tracked lifecycle data — methodology

At the start of this year you could still describe end-of-life tracking as calendar management: find the vendor's date, write it down, migrate before it arrives. Seven months of evidence later, that model is broken — in two different directions at once.

The dates got dangerous. In 2026, running software past its end-of-life date stopped being an abstract hygiene problem and became a documented exploitation problem, with a US government ledger to prove it. And the dates stopped holding still. The most consequential deadlines of the year moved, split, or turned out to mean something different than everyone had written down — edited in place by vendors, tiered behind entitlements, or defined in license documents rather than patch schedules.

This is the mid-year accounting of both: the biggest EOL surprises of 2026 so far, with receipts. A full-year edition follows in December.

Part I — The dates got dangerous

1. The dead don't stay buried

The single most clarifying dataset of the year is one nobody publishes as a headline: the age of the vulnerabilities CISA keeps confirming as actively exploited. We downloaded the live Known Exploited Vulnerabilities catalog (version 2026.08.10, 1,662 entries) and counted: of the 178 vulnerabilities added in 2026 through August 7, 29 are CVEs at least three years old, 21 are at least five years old, and 10 date from 2012 or earlier — including three from 2008.

Read that again: roughly one in six vulnerabilities the US government confirmed as under active attack this year is old enough that the software it lives in has often aged out of support entirely. On a single day — May 20, 2026 — CISA added five CVEs dated 2008–2010, among them CVE-2008-4250, the Conficker-era Windows flaw. Attackers are not browsing this quarter's disclosures; they are working through the industry's accumulated lifecycle debt.

The sharpest example: in February 2026, CISA added two GitLab server-side request forgery flaws — CVE-2021-39935 (added February 3) and CVE-2021-22175 (added February 18) — to the catalog. GitLab patched both in December 2021. The in-the-wild exploitation confirmation came five years later, aimed at instances that never took a patch that has existed for half a decade. We covered what that means for GitLab's unusually short support window in our GitLab 19.0 analysis, and we return to it in Part II.

2. The prophecy: FortiOS 7.0 showed everyone the fuse

If you want to know what "End of Support" means in operational terms, 2026 supplied a controlled experiment. FortiOS 7.0 — the operating system on FortiGate perimeter firewalls — reached End of Support on September 30, 2025. On July 27, 2026, just under ten months later, CVE-2025-68686 entered the KEV catalog: a symlink-persistence flaw that survives patching, affecting (per Fortinet's own advisory FG-IR-25-934) every 7.0 and 6.4 release. Fixed builds exist only on the supported 7.4 and 7.6 trains. For the dead trains, Fortinet's remediation guidance is three words: migrate to a fixed release.

That is the complete anatomy of a modern EOL failure — actively exploited, past end of life, and never getting a fix — compressed into ten months, on the single worst category of device to run unsupported: an internet-facing security appliance. It is also a countdown with a successor: FortiOS 7.2 crosses the identical line on September 30, 2026, 51 days from this article's publication. We laid out the 7.2 decision fork here; the 7.0 story is the evidence that the date is not a formality.

3. The last patch ever fixed a flaw already under attack

SharePoint Server 2016 and 2019 reached end of support on July 14, 2026, and received their final security update that day. That last-ever patch fixed CVE-2026-58644 — which entered the KEV catalog on July 16, two days later, with a three-day federal remediation deadline. The window between "fully supported" and "actively exploited with the clock stopped" was not months. It was a weekend.

Then it got worse: on July 22 — eight days after EOL — a second SharePoint flaw, CVE-2026-50522 (a 9.8-severity remote code execution bug), hit the KEV catalog. Its fix shipped in that same July 14 update, the one no future update will ever follow. Every SharePoint 2016/2019 instance that missed the last train is now permanently exposed to two confirmed-exploited vulnerabilities, and there is no ESU program for SharePoint. We covered it as it happened: the EOL, the first post-EOL exploitation, and the second flaw.

4. The permanently vulnerable ledger

These are not anecdotes; they are entries in a checkable list. Our Exploited & Unpatchable feed tracks software that meets three conditions simultaneously: in CISA's KEV catalog (actively exploited), past end of life, and confirmed by the vendor's own advisory to be receiving no fix, ever. Every entry is human-verified against the advisory and the live catalog, and an entry is deleted the moment a backport appears. The feed holds twelve entries; four were KEV-listed in 2026 alone:

The older entries fill out the pattern — four of the twelve carry CISA's "known ransomware campaign use" flag, including VMware ESXi 7.0, where Broadcom's compatibility matrix states "No Patch Planned" in writing. Two smaller 2026 artifacts complete the picture. Arista's advisory for the 10.0-severity VeloCloud Orchestrator flaw states that end-of-support versions "have not been assessed" — EOL software no longer even gets an answer (our coverage). And July's JADEPUFFER campaign — reported as the first documented ransomware operation run by an AI agent — needed no zero-days at all: it entered through a Langflow flaw that had been in the KEV catalog since May 2025, plus default credentials and a signing key published in 2020. All lifecycle debt, no novelty (analysis).

Part II — The dates stopped holding still

5. The quiet extension: Microsoft moved the Windows 10 wall a year, via an editor's note

The most consequential EOL date on Earth belongs to Windows 10, which reached end of support on October 14, 2025 while running — per StatCounter, July 2026 — on 29.88% of desktop Windows worldwide. The expected 2026 story was hundreds of millions of machines racing the consumer Extended Security Updates deadline of October 2026.

Instead, on June 25, 2026, Microsoft extended consumer ESU by a full year — to October 12, 2027 — and announced it as an editor's note appended to an existing Windows Experience Blog post. Not a keynote, not a lifecycle bulletin: an editor's note. Microsoft's end-of-support page now states that enrolled devices "will continue to receive critical and important security updates through October 12, 2027," with enrollment open until that date (free with settings sync, 1,000 Microsoft Rewards points, or $30).

The extension is genuinely good news for the roughly three-in-ten desktops still on Windows 10. It is also the year's cleanest demonstration of the second thesis: a deadline that an entire industry had planned around — publishers, IT departments, PC vendors — moved by a year, mid-year, in a way you would only catch by re-reading a page you thought you had already read. Every article, runbook, and migration plan that hard-coded "October 2026" became silently wrong on June 25. Ours included: we re-verified and refreshed our own Windows 10 migration guide and decision guide against Microsoft's live pages for this report.

6. The legal EOL: JDK 17's cliff is a license document

Autumn's most-watched "end of life" — Oracle JDK 17, September 30, 2026 — turns out not to be a patch cutoff at all. As we unpacked in our JDK 17 analysis, September 30 ends Oracle Premier Support, a paid-tier seam: Extended Support continues to September 2029, and Oracle's roadmap waives the Extended Support fee for that entire period. The event free users actually cared about — the end of Oracle's no-fee production license for JDK 17 — happened in September 2024, two years before the famous date. And Java 17 itself dies on no particular date: Eclipse Temurin ships free builds to October 2027, Amazon Corretto to October 2029, Azul Zulu to September 2029.

In other words, the industry's loudest 2026 "EOL" is a licensing artifact whose real-world meaning varies by two-plus years depending on whose logo is on the installer — and the same month hides a second license cliff, as Oracle JDK 21 updates released after September 2026 leave the free-use license too. A calendar that cannot express "it depends on your contract" cannot express Java.

7. Dates that rot in place

Here is a failure mode that barely existed in the old model: being wrong by faithfully citing the vendor. AWS's Lambda runtime deprecation schedule once said function creation for the deprecated Node.js 20 runtime would be blocked on August 31, 2026 — and well-read third-party guides published exactly that. AWS then edited the schedule in place: its live runtimes page now sets block-function-create at February 1, 2027 and block-function-update at March 3, 2027 for the entire deprecated cohort, with a note crediting "customer feedback" for the delay. The third-party pages still say August. They were right when written; the ground moved under them.

Two nuances keep this honest. The stale dates are snapshots of AWS's own earlier schedule, not fabrications — the failure is treating a living document as an archive. And the reprieve is operational, not security: AWS's policy is that deprecated runtimes "may no longer" receive security patches, so Node.js 20 functions have been running without that assurance since April 30, 2026 regardless of the 2027 dates. We documented the move on August 1 in our Lambda deprecation timeline.

This is not an AWS quirk; it is the systemic condition. In July we cross-checked 54 products in our dataset against their vendors' official lifecycle documentation: 33 verified exactly, 12 required date corrections, and 7 had no vendor-published dates at all. All six upstream correction PRs from that audit were merged by the endoflife.date maintainers on July 21 (the full drift study). EOL dates are not facts you record once; they are claims you have to keep re-verifying. That finding is, not coincidentally, the reason this site re-checks its data continuously instead of publishing a calendar and walking away.

8. The conditional calendar

The year's subtlest lesson: "when does support end?" increasingly returns a conditional, not a date.

OpenShift 4.18 is the purest case, as we detailed in our 4.18 analysis: universal maintenance ends August 25, 2026 — and then patches continue only behind Red Hat's EUS entitlement, which is included on Premium subscriptions (to February 2027) but a paid add-on on Standard. Same cluster, same version, same date: seven months of runway or two weeks, depending on a contract line item. FortiOS runs a two-stage decline — 7.2 lost regular engineering fixes in March 2025, eighteen months before its September 30 "End of Support" headline date. And GitLab compresses the whole concept: its policy patches only the current monthly release plus two prior, so every version exits the security window ~91 days after it ships — on a product whose KEV record (see Part I) shows exactly what falling off the treadmill costs. Ubuntu LTS gives you five years; GitLab gives you a quarter. Neither number is on the box.

Part III — The deadline that reports back

The third development of 2026 is that regulators stopped treating EOL as advice. On the US side, CISA's binding operational directives now order federal agencies to get end-of-life devices off the network edge and to patch on risk-based deadlines (our BOD coverage) — the KEV due-dates quoted throughout Part I are those deadlines at work; CVE-2026-58644's was three days.

On the EU side, the Cyber Resilience Act's schedule is widely misread as "December 2027." The regulation's own Article 71 says otherwise: the main obligations apply from December 11, 2027, however — Article 14, the manufacturers' obligation to report actively exploited vulnerabilities and severe incidents, applies from September 11, 2026. Thirty-three days from this article's publication, an exploited vulnerability in a product sold in the EU becomes a legal reporting event. The CRA also fixes the support-period floor manufacturers must state: at least five years unless the product's expected life is shorter (Article 13), with penalties reaching €15 million or 2.5% of global turnover. The European Commission published its first application guidance on July 27, 2026 — mid-year, another date that arrived early while everyone watched 2027 (our CRA compliance guide).

One calendar collision deserves its own sentence: OpenSSL 3.0 — the first 3.x LTS, embedded in an uncountable number of EU-shipped products — reaches end of life on September 7, 2026, four days before the CRA's exploited-vulnerability reporting regime switches on.

What the second half holds

The back half of 2026 is the densest EOL calendar in years — we mapped it in the H2 2026 pileup. The headline dates:

If the first half is any guide, at least one of these dates will move, at least one will turn out to mean less than it sounds, and something not on this table will end up in the KEV catalog within weeks of its EOL date. That is not cynicism; it is the base rate this article just documented.

The scoreboard, and what it means

Mid-year totals for the two theses. The dates got dangerous: 178 KEV additions, one in six of them three-plus years old; a ten-month EOL-to-unpatchable fuse demonstrated on a perimeter firewall; a last-ever patch beaten to the catalog by its own exploitation; twelve products on the permanently-vulnerable ledger, four confirmed exploited this year. The dates stopped holding still: the world's biggest EOL deadline moved a year via an editor's note; a cloud vendor edited its cutoff dates in place under everyone's citations; the season's loudest "EOL" is a license-tier seam; and one in five of the vendor dates we audited needed correction.

Both halves of the story point at the same conclusion: an EOL date is not a fact you look up once — it is a claim that has to be continuously re-verified against the vendor, cross-referenced against the exploitation record, and read with its fine print. That is the entire design argument for this site: we track 480+ products with vendor-verified, continuously re-checked dates, score every version's real-world exposure with the EOL Risk Score™, maintain the Exploited & Unpatchable feed as the ledger of worst cases, and answer "is my version dead?" in seconds. The December edition will close the books on the year — including a public accounting of which H2 predictions above held.

Frequently Asked Questions

Related

• The Exploited & Unpatchable feed — the full twelve-entry ledger, with JSON feed
• The H2 2026 EOL Pileup — the survival plan for September–December
• EOL Dates Drift — our 54-product vendor cross-check, and the six upstream corrections it produced
• The 2026 EOL Calendar — every tracked date this year
• EOL Watch — deadline coverage as it happens