Oracle Just Shipped 1,449 Security Patches in One Quarter. We Checked How Much of It Is Actually New.

Oracle's July 2026 Critical Patch Update (CPU) is nearly three times larger than any release in the company's history. To understand it, we parsed all 23 of Oracle's quarterly advisories going back to 2021, matched them against the official CVE record, and compared Oracle against eight other major vendors. We set out to answer three questions: How much of this is genuinely new? Does it really reflect AI-accelerated patching? And how unusual is it?

TL;DR

• This release is genuinely huge: Oracle shipped 1,449 security patches in July 2026. That's 3.7 times its usual quarterly volume (2021–2025) and nearly triple its previous all-time record of 520 patches, set in April 2022.
  
• It's not just the new monthly patches repackaged: In May 2026, Oracle added monthly patch releases on top of its quarterly ones. But almost none of those carried over: only 1.8% of July's fixes had already appeared in the May or June monthly updates. The quarterly release is nearly all new material.
  
• It's not the usual open-source cleanup: Normally about two-thirds of an Oracle patch bundle fixes bugs in third-party software Oracle ships with its products. This time it flipped: 77% of the fixes (1,110 CVEs) are for flaws in Oracle's own code — versus a historical norm of roughly 102 per quarter.
  
• These flaws are brand new to the public, and Oracle found them itself: Half of July's vulnerabilities became publicly known only about 13 days before the patch — and 95% of the Oracle-code fixes credit no outside researcher. Outside reporters were credited on no more bugs than in a typical quarter, so this surge came from inside Oracle, not from the security community.
  
• The timing matches Oracle's AI claims: In late April 2026, Oracle said it is "using AI, including frontier models, to improve how issues are found and to accelerate how fixes are delivered". Its output of self-discovered bugs had been flat for five years, then jumped roughly tenfold in the first full quarter after that announcement. The correlation is strong, but no independent party has verified that AI is the cause.
  
• The whole industry is finding more bugs, but not to this extent: Microsoft, Adobe, Red Hat, and VMware all topped 1.5x their own baselines in 2026, while SAP, Cisco, IBM, and Apple stayed flat. None came anywhere near Oracle's ~10x jump.
  
• What it means for third-party risk teams: If your vendors run Oracle E-Business Suite, PeopleSoft, or WebLogic, how fast they work through a 1,449-patch quarter is now a real, measurable signal of their security discipline — and releases this size may become routine.
  

A record by any count

On July 21, 2026, Oracle released its quarterly Critical Patch Update (CPU) with a headline number that made even patch-fatigued administrators look twice: 1,449 new security patches across 32 product families.

Depending on who's counting, you'll see different totals — 1,235 from Tenable, 1,449 from Oracle, or figures up to 1,461. They're all describing the same release. Our parse of the advisory reconciles them:

• 1,235 — the unique CVEs listed in Oracle's primary risk-matrix rows. This is Tenable's method.
• 1,449 — Oracle's own headline figure: the number of distinct security patches.
• 1,461 — every unique CVE, including the "the patch for X also addresses Y" footnotes and bundled third-party fixes.

Two denominators appear throughout this analysis, so let's clarify them now:

When we talk about a percentage of the whole release, we use 1,461 — the count of all unique CVEs. When we talk attribution percentages (who assigned the CVE), we use 1,449 — the CVEs that matched a record in the official CVE List. (12 of the 1,461 hadn't yet propagated to the CVE record when we ran the analysis. And yes, the fact that 1,449 matched CVEs happens to equal 1,449 patches is pure coincidence — they're different things)

Whichever count you prefer, the historical comparison is unambiguous. Unless we say otherwise, every baseline in this piece uses the 2021–2025 period — the 20 quarterly CPUs before the current year. Across that window Oracle averaged 390 patches per quarter and never exceeded 520. Even 2026's own January and April CPUs (337 and 481) stayed inside that range. July 2026 is 3.7x that average and 2.8x the all-time record — and the record it broke (April 2022) was itself inflated by an industry-wide emergency, the Spring4Shell cleanup.

So the volume is real. The more interesting question is what's in it.

Four deflationary explanations, tested

When a vendor's patch count triples, the seasoned reaction is skepticism: big numbers usually mean bundling, double-counting, or housekeeping. We tested the four most plausible deflationary explanations against the data. Three fail outright. The fourth deserves more honesty than it usually gets.

Hypothesis 1: It's just the new monthly patches rolled up (rejected)

In May 2026 Oracle began shipping monthly Critical Security Patch Updates (CSPUs) between quarterly CPUs — 77 patches in May, 245 in June. July is the first quarterly CPU released under this new cadence, so a reasonable guess is that roughly 320 of its patches are simply the monthly fixes restated. They aren't.

We pulled every CVE from the May and June monthly advisories and checked them against July: only 27 of the CPU's 1,461 CVEs — 1.8% — had appeared in a monthly update. The monthlies and the quarterly are almost entirely separate sets of fixes, which also means Oracle's total 2026 output is even larger than the July CPU alone suggests.

Hypothesis 2: It's a third-party open-source sweep (rejected)

This is the usual anatomy of a big Oracle CPU. Oracle products bundle huge amounts of open-source software, so its quarterly updates routinely sweep in months' worth of Apache, OpenSSL, and Linux-ecosystem CVEs.

In April 2026, Qualys found that 78% of that quarter's CPU patches were for non-Oracle CVEs; our own parse put it at 75.8%, and the 2021–2025 average at 66.8%. If July were more of the same, the "new Oracle security work" would be a small slice of the headline. Instead, July flips the ratio. Matching every CVE against version 5 of the official CVE List shows that 76.6% of the matched CVEs — 1,110 of 1,449 — were assigned by Oracle's own CVE Numbering Authority (CNA).‍

These are vulnerabilities in Oracle's own code, disclosed through Oracle's own process. The third-party remainder (339 CVEs) is led by GitHub-assigned open-source CVEs (91), Apache (59), and VMware (31), with the rest scattered across dozens of smaller CNAs — a small fraction by comparison.

Hypothesis 3: It's re-listing old CVEs across product lines (rejected)

Oracle counts a CVE once per affected product line, and its quarterly advisories routinely re-list CVEs carried over from prior quarters — so maybe July is padded with old, already-known bugs. The data says no.

Historically, only 63.4% of the CVEs in a given CPU are appearing in an Oracle advisory for the first time. In July 2026, 91.9% are first-ever appearances — the highest share of any quarter we measured. And only 5.2% of July's CVEs were more than a year old at patch time, versus a 2021–2025 average of 24.0%. This is not a backlog being cleared out.

Hypothesis 4: It's a disclosure-policy change, not a discovery breakthrough. (cannot be excluded)

This is the strongest skeptical reading, and our data genuinely cannot rule it out. Vendors quietly fix internally discovered bugs without ever assigning them a CVE far more often than anyone admits. If Oracle simply started assigning CVEs to flaws it previously fixed in silence — the way Microsoft began doing for cloud vulnerabilities in 2024 — the CVE count would explode with no actual change in how many bugs Oracle discovers.

Crucially, the "freshness" metrics above are equally consistent with this reading: an internally found bug gets its CVE reserved at patch time whether it was found last month or five years ago.

Here's what we can say against this interpretation.

We found no announced change to Oracle's CVE policy (Oracle's CPU documentation has long stated that CPUs include fixes for internally found issues). No analyst has identified such a change. And Oracle's own explanation attributes the shift to discovery — "how issues are found" — not to disclosure.

The two explanations also aren't mutually exclusive: AI-assisted triage could be exactly what made it feasible to assign CVEs en masse to internal findings in the first place. (And one thing the credit data settles either way: the wave came from inside Oracle, not from a surge in external bug reports — more on that in the anatomy section below.)

So the conclusion this analysis stands on is deliberately about disclosure, not discovery: Oracle is now disclosing and fixing security flaws in its own code at roughly ten times its historical rate. Whether the finding changed or only the telling changed — Oracle says the finding — is the one question only Oracle can answer.

The anatomy of the wave

Strip away the failed hypotheses and the real shape of the release emerges from the CVE metadata:

• 1,110 Oracle-assigned CVEs in a single quarter — 10.9x the historical norm: From 2021 through 2025, Oracle's own CNA contributed a remarkably steady 60–180 CVEs per CPU, averaging 102. The break isn't gradual; it's abrupt. Even 2026's own January and April CPUs were normal, at 68 and 109 Oracle CVEs.
• It's concentrated in Oracle's big, aging application codebases: E-Business Suite leads with 410 risk-matrix entries — every one of them an Oracle-assigned CVE — followed by Fusion Middleware (345 entries, 92% Oracle-assigned) and PeopleSoft (84 entries, 96% Oracle-assigned). Product families built around bundled open source, like Oracle Communications, stayed majority third-party. In other words, the wave hit the products Oracle has been shipping for twenty years — exactly where a new discovery capability, or a new disclosure policy, would turn up the most accumulated material.
• The flaws are fresh, coordinated, and internal: The median July CVE was published 0 days from the patch date, and 75.1% were published within three days of the CPU — the signature of internally discovered, coordinated disclosure. The median CVE was reserved just 13 days before release, and 75.6% were fixed within 30 days of any public disclosure.
• External researchers didn't cause this: The most direct test is Oracle's own credit statement. The July advisory credits outside reporters for just 54 CVEs — squarely inside the 2021–2025 range of 14–91 per quarter. And of the 1,110 Oracle-assigned CVEs, 95% carry no external credit at all, versus roughly half in recent quarters. Whatever found these flaws, it operates inside Oracle.
• Severity kept its usual shape — this isn't padding with trivial bugs: The release overall is 19.0% critical (CVSS ≥ 9.0) and 50.9% high, in line with historical CPUs, and the Oracle-assigned and third-party subsets have essentially identical critical rates (18.9% and 18.6%). At this volume, that works out to 277 critical vulnerabilities in one release — including the permanent fixes for the PeopleSoft pre-authentication chain (CVE-2026-35273 / CVE-2026-35278, both CVSS 9.8) that ShinyHunters exploited against 300+ servers at 100+ organizations in May and June (Moxfive's incident guidance).
• Almost none of it is known to be exploited — yet: Beyond that PeopleSoft pair, only three CVEs in the release carry known-exploited markers in the CVE record at the time of writing (one of them a 2021 Linux kernel flaw). Same-day CVEs lag in enrichment, though, so treat this as a snapshot, not an all-clear.
• The run-rate is unprecedented: Counting CPUs and monthlies together, Oracle's own CNA has published 1,541 CVEs in under seven months of 2026 — more than 2022, 2023, 2024, and 2025  (1,395), and nearly double its busiest prior full year (811, in 2020), with five months still to go.

In short: whichever way Hypothesis 4 resolves, this is what it looks like when a vendor discloses a decade's worth of vulnerabilities in its own code in one quarter.

The AI timeline

Why would a five-year-flat series jump an order of magnitude in ninety days? Oracle has, unusually, already answered on the record.

In late April 2026, Oracle's security blog published "Accelerating Vulnerability Detection and Response at Oracle":

"Oracle is using AI, including frontier models, to improve how issues are found and to accelerate how fixes are delivered, including the introduction of monthly CSPUs."

"Oracle has access to leading frontier AI models, including Anthropic's Claude Mythos Preview and OpenAI's most capable models through Trusted Access for Cyber."

Oracle's database team went further, urging customers onto current release updates because, starting April 2026, they "include fixes to vulnerabilities that could be identified with leading frontier AI models."

The sequence in the data lines up with the sequence of announcements:

Analysts connected the same dots. SiliconANGLE's Dave Vellante called Oracle's April advisory "a cybersecurity harbinger," pointing to frontier-model vulnerability discovery as the catalyst and noting that the April and July updates would be "the first to incorporate security hardening informed directly by testing with advanced AI models."

Now, Oracle has never explicitly said "the July CPU is large because AI found these bugs" — that causal link is our inference from timing, composition, and Oracle's own statements. Second, no independent party has audited how many of the 1,110 were AI-discovered, and the disclosure-policy alternative (Hypothesis 4) remains open. What the data establishes is the what — a tenfold disclosure surge, concentrated in Oracle's own code, immediately following Oracle's AI announcement. The why rests on Oracle's word.

How exceptional is this? The apples-to-apples test

A single vendor's spike could still be a quirk of that one vendor. So we indexed every major vendor's quarterly CVE output — as recorded in the official CVE List, counting only the CVEs assigned by each vendor's own CNA — against that vendor's own 2021–2024 quarterly average. We ended the peer baseline at 2024 on purpose: it's the last window that clearly predates AI-era discovery effects, so any 2025–2026 acceleration shows up in the multiple rather than being quietly absorbed into the baseline.

One note for reading the Oracle row. The table counts CVEs published per calendar quarter, across all of a vendor's releases in that quarter. Oracle's quarterly CPUs land in January (Q1), April (Q2), July (Q3), and October (Q4) — so the record July 21 CPU shows up as the Q3 figure. Oracle's elevated Q2 (3.6x) is not the April CPU, which was normal; it's the first two monthly CSPUs (May 28 and June 16) stacking on top of it. The acceleration started with the monthlies and peaked with the quarterly release.

† Partial quarter (three weeks, through July 21) — already above baseline. Other vendors' partial-Q3 counts are withheld (—) as not meaningful. Oracle's Q3 figure is complete: its quarterly release simply lands at the start of the quarter (July 21). The two Oracle multiples in this piece measure different things: 10.9x compares CVEs in the July CPU against the average CPU (102/quarter); 10.5x compares calendar-quarter published CVEs against the 2021–2024 quarterly mean.

Two things are true at once:

1. The AI-era surge is industry-wide

‍On the Q2 column alone — the clean comparison — Microsoft, Red Hat, VMware, and Adobe all ran 1.7–5.6x their own baselines, while SAP, Cisco, IBM, and Apple stayed flat. Measured by Microsoft's own advisory feed (the MSRC API, which includes CVEs Microsoft ships fixes for but didn't assign — bundled Chrome, open-source components, and cloud CVEs), Microsoft's Q2 reached 3,142 CVEs, roughly 4x its 2021–2023 average — the window before Microsoft's own counting broadened (see caveats), and a broader unit than the CNA count in the table, which is why the two Microsoft figures differ.

The inflation is visible everywhere you look: 48,185 CVEs were published in 2025, up 21% on top of 2024's 38%; NIST announced in April 2026 that the NVD will no longer enrich every CVE; and Adobe and Cisco both moved to twice-monthly security release cadences. Behind it sit AI discovery programs — Google's Big Sleep, Microsoft's Security Copilot, Anthropic's, XBOW's — already shipping CVEs at scale. Oracle is riding a wave, not inventing one.

2. Oracle's magnitude is unique

The vendors that surged did so at 1.7–5.6x. Oracle's July release alone is an order of magnitude above its baseline — in its own code, in a single quarter. Whether that reflects the most aggressive AI adoption in the industry, the largest accumulated stock of undisclosed vulnerabilities, or a disclosure-policy shift riding an AI announcement — the honest answer is probably some of each — Oracle's July CPU is the single largest step-change in vendor vulnerability disclosure we can find anywhere in the modern CVE record.

What this means for security teams

1. Treat this as the new normal, not a one-off outlier

The "record CPU" framing actually undersells the problem. Because only 1.8% of July's CVEs were repeats from the monthlies, those monthly CSPUs are additive — they're extra work, not previews of the quarterly. If discovery stays AI-accelerated, any quarterly patch planning built around ~400 Oracle patches is now off by a factor of three or more, and the work arrives on a combined monthly-plus-quarterly cadence.

2. Freshness cuts both ways

A median of 13 days from CVE reservation to patch is genuinely fast remediation. But it also means defenders get no head start: three-quarters of these vulnerabilities entered the public record on patch day. And remediation at this speed and scale carries its own operational risk — 1,449 patches produced on an accelerated pipeline is also 1,449 opportunities for regressions and incomplete fixes. Staged rollouts and post-patch validation matter more in an AI-paced patching regime, not less.

3. The same tooling is available to attackers

Oracle frames its own program as a response to "AI-enabled cybersecurity threats," and Anthropic's Mythos announcement warned that over 99% of the vulnerabilities it found were still unpatched. The window between disclosure and exploitation was already shrinking; volume at this scale strains every downstream process — triage, testing, change windows — that sits between a vendor's patch and your production systems.

4. Prioritize by exposure, not by count

 277 critical CVEs in one release will break any CVSS-ranked to-do list. The concentration data tells you where to start: E-Business Suite (410 entries, the largest single share of the release), Fusion Middleware (219 vulnerabilities that are exploitable over the network without authentication, per Tenable), and PeopleSoft — where the actively exploited ShinyHunters chain finally gets its permanent fix. Internet-facing instances of those three families are the release's real urgency.

5. For third-party risk teams, patch latency is now a live signal

Your vendors' Oracle estates — E-Business Suite ERPs, PeopleSoft HR systems, WebLogic-hosted applications — just received the largest patch obligation in the platform's history. The PeopleSoft campaign already showed what unpatched exposure costs: HR and payroll data exfiltrated from 100+ organizations. How quickly a vendor absorbs a 1,449-patch quarter — and whether its internet-facing Oracle surfaces stay stale — is now a measurable difference between vendors, not background noise.