Oracle Shipped 1,449 Patches. On Out-of-Support Versions, It Didn't Even Look.

Published: July 25, 2026  ·  EOL Watch — news analysis

On July 21, Oracle released the largest Critical Patch Update in the program's twenty-one-year history. The advisory's own line is unambiguous: this CPU contains 1,449 new security patches. Tenable's analysis puts the unique CVE count at roughly 1,235, spread across Database, Fusion Middleware, MySQL, Java SE, E-Business Suite, PeopleSoft, JD Edwards, Communications and Financial Services. CSO reported ten CVSS 10.0 flaws in Fusion Middleware alone.

It was not a quiet quarter on the other side either. The same update delivered the full fix for the PeopleSoft PeopleTools flaw chain that the ShinyHunters group used between late May and early June to compromise servers at more than a hundred organizations. Oracle vulnerabilities are being weaponized at scale, right now.

Every security outlet covered the number. Almost none covered the paragraph near the bottom of the advisory, which is the part that should worry you more.

The paragraph nobody quotes

Under the heading Critical Patch Update Supported Products and Versions, Oracle's July 2026 advisory sets out the rule plainly. Patches under the CPU programme are provided only for versions in the Premier Support or Extended Support phases of the Lifetime Support Policy. And then, of releases outside those phases:

Such releases, Oracle writes, "are not tested for the presence of vulnerabilities addressed by this Critical Patch Update." And it adds that "it is likely that earlier versions of affected releases are also affected by these vulnerabilities."

— Oracle Critical Patch Update Advisory, July 2026

Read those two clauses together and they say something stronger than "we stopped patching you." They say: we stopped measuring you, and we expect you are exposed. Oracle's recommendation that follows is a single sentence advising customers to upgrade to supported versions.

This is not new language — it appears in every quarterly CPU. That is exactly why it slips past. Boilerplate that never changes stops being read, and this particular boilerplate is the single most consequential sentence in the document for anyone running older Oracle software.

You can watch the policy operating in the tables

The abstraction becomes concrete one row at a time. Each risk matrix in the advisory has a column headed — and this is Oracle's own wording — "Supported Versions Affected." Not "versions affected." Supported ones.

The MySQL matrix is the cleanest illustration, because two products from the same family sit on adjacent lines. Across the MySQL entries, the affected-version cells read like this:

MySQL Cluster 8.0 is listed as affected. MySQL Server 8.0 is not listed at all. These are not distant products; they share lineage and a great deal of code. The difference between them in this advisory is not that one has bugs and the other doesn't. It is that one is still inside the support window and therefore inside the test scope, and the other passed its end-of-life date twelve weeks ago and dropped out of both.

July 2026 is the first full Critical Patch Update since MySQL 8.0's April 30 cutoff. This is what the transition looks like from the outside: your version simply stops appearing.

The flagship product tells the same story in a single line. The advisory's affected-products entry for the database reads:

Oracle Database Server, versions 19.3–19.31, 21.3–21.22, 23.4.0–23.26.2

Three release trains. 18c, 12.2, 12.1 and 11.2 are not there — not as "unaffected", simply not there. Anyone still running 12.2 in production, and plenty of organizations are, will find nothing about their version in a document listing 1,235 vulnerabilities. That silence is the product of a scoping rule, not a security assessment.

"Not listed" is not "not vulnerable"

This is the CVE blind spot in an unusually pure form, and it fools people in a specific way.

The normal blind spot is that a scanner reports no known CVEs for an EOL package because nobody is filing CVEs against it any more. Here the mechanism runs one level higher: the vendor's own advisory — the authoritative document your risk register cites — produces an empty result for your version, and an empty result reads like a good result. A team can check the July 2026 CPU for Oracle Database 12.2, find nothing, and record that as no action required. The advisory even tells them why that inference is invalid, in a paragraph they have scrolled past for years.

The asymmetry is worth stating precisely, because it is the whole argument:

The trap: you can be paying Oracle and still get nothing

Here is where Oracle's model diverges from most vendors, and where a lot of organizations are quietly wrong about their own position.

Oracle's Lifetime Support Policy has three phases. Premier Support runs roughly five years from general availability. Extended Support typically adds three more, for an uplift on the maintenance fee. After that comes Sustaining Support — and Sustaining Support never ends. You can hold an active, fully paid Oracle support contract indefinitely.

What that contract stops delivering is the part you care about. Oracle's Software Technical Support Policies state that Sustaining Support does not include new program updates, fixes, security alerts, critical security patch updates, or critical patch updates. You keep access to patches issued during the Premier window. You receive no new ones, ever.

The same shape appears in Oracle Linux, where Sustaining Support explicitly excludes access to new patches, fixes and security alerts while preserving access to those created during the Premier period.

Which Oracle versions are past the line right now

These are the dates as of publication. "Extended" means a paid extension is available or was available; past both dates means a release is in Sustaining Support, where no new CPU content arrives.

The Java rows deserve a note, because they are the ones people get wrong most often. Oracle JDK 8 and 11 are not abandoned — they are patched for as long as you hold a Java SE Subscription. What changed is that the patches moved behind a paywall rather than disappearing. If you are running Oracle's JDK builds without a subscription, you are in the same position as an out-of-support database: quarterly CPUs land, and none of them are for you.

What to actually do

Three things, in order, and none of them require a migration decision this week.

1. Establish which support phase each Oracle deployment is in — not whether it has a support contract. These are different questions and only one of them predicts whether patches arrive. The distinction to write down for each system is Premier / Extended / Sustaining, with the date it changes.

2. Stop treating advisory absence as evidence. For anything in Sustaining Support, the July 2026 CPU tells you nothing. If a control or an audit response currently rests on "our version wasn't in the advisory," that control is not doing what it appears to do. The defensible framing is that exposure is unmeasured, and unmeasured is not the same as zero.

3. Price the three options against each other — buy back into scope (Extended Support or a Java SE Subscription where one exists), upgrade to a supported release, or accept the risk explicitly with compensating controls: network segmentation, restricted access, enhanced monitoring. The third is a legitimate choice, but only when it is written down as a choice. Most of the risk in practice comes from organizations in position three believing they are in position one.

There is a fourth thing, and it is the cheapest: check the dates. Check any Oracle version in seconds, scan your whole stack, or read our Oracle Database lifecycle guide — all against dates verified against vendor sources.

The lesson, restated

A record-breaking patch release is usually reported as reassurance: the vendor is working, the process is functioning, 1,449 things got fixed. For anyone inside the support window, that reading is correct.

For everyone else, the same document says the opposite, in the vendor's own words. Oracle is not being evasive here — it publishes the limitation openly every quarter, and it goes further than most vendors by stating that older releases are likely affected. The gap is not in Oracle's disclosure. It is that the disclosure appears in a paragraph of unchanging boilerplate, below a table of 1,449 things that look like progress.

An end-of-support date changes nothing about your software and everything about your options. Oracle's quarterly cadence makes the point four times a year: after the date passes, the CPU keeps arriving, it keeps getting bigger, and none of it is addressed to you.

Frequently Asked Questions

Related Resources

• Oracle Database End of Life: Every Version's Support Status
• Oracle Java Licensing and the Subscription Cliff
• MySQL End of Life: Complete Version Support and EOL Dates
• Oracle Linux End of Life Dates and Extended Support
• The CVE Blind Spot: Why Scanners Miss EOL Vulnerabilities
• What Actually Happens The Day After End of Life
• Full Oracle Database lifecycle timeline