Oracle's July 2026 CPU: 1,449 Vulnerabilities Patched, and Patching Just Changed
In July 2026, Oracle released the largest Critical Patch Update (CPU) in its history: 1,449 security fixes in a single batch, covering nearly the entire portfolio, from Oracle Database to Fusion Middleware. For anyone running Oracle environments day to day, the number alone is a signal: the era of "patch quarterly and move on" is clearly over.
This article explains what happened, why the volume spiked, which flaws demand immediate attention, and what it actually changes in the daily routine of whoever is responsible for keeping these environments secure.
Why the Patch Volume Spiked
Of the 1,449 patches, only 64 were reported by external researchers. The overwhelming majority came from Oracle's own internal processes, in a scenario where security experts point to growing use of AI-assisted vulnerability detection tooling as a central factor. This isn't a sign that Oracle's software got worse: it's a sign that the ability to find flaws (both inside and outside the company) is improving faster than IT teams' ability to apply fixes.
Microsoft experienced the same phenomenon the same month, with 622 CVEs fixed in its July Patch Tuesday. Security executives already treat this as the new normal: increasingly large patch batches, with less reaction time for whoever has to apply them.
The Flaws That Matter Most
Ten of the 1,449 fixes received the maximum severity score (CVSS 10.0), all concentrated in Oracle Fusion Middleware. Two drew special attention from the Dutch National Cyber Security Centre (NCSC):
CVE-2026-47056, in Oracle Data Integrator, allows compromise by an unauthenticated attacker.
CVE-2026-60217, in Oracle Coherence, carries the same risk: remote exploitation with no credentials required.
Environments using ODI for data integration or Coherence for distributed caching should treat these two as top priority, regardless of any patching schedule already planned.
What Changes in the DBA's Routine
In response to the growing volume, Oracle started issuing, in addition to the traditional quarterly CPU, monthly Critical Security Patch Updates (CSPUs) to speed up fixes for the most urgent flaws. In practice, this means the patching calendar for any serious Oracle environment can no longer default to quarterly.
A practical checklist for adapting the routine:
Move from a quarterly application cycle to a monthly evaluation cycle, even if actual application of some patches remains quarterly due to maintenance-window constraints.
Prioritize by CVSS and by real exposure of your environment — don't apply everything blindly without triage; not every critical patch applies to your scenario (a Coherence patch doesn't matter if you don't use Coherence).
Keep a staging environment current enough to test critical patches within days, not weeks.
Formally document which CVEs were evaluated and the decision made (apply, defer, not applicable) — this becomes governance evidence during audits.
Frequently Asked Questions
Does the patch record mean Oracle Database got less secure?
Not necessarily. The increase largely reflects a greater capacity (Oracle's and the market's) to find vulnerabilities before they're exploited, not necessarily more flaws being introduced.
Do I need to apply all 1,449 patches to my environment?
No. The vast majority won't apply to your specific scenario — triage by installed product and real exposure is essential before any application.
What exactly is a CSPU, and how does it differ from the quarterly CPU?
A Critical Security Patch Update (CSPU) is a monthly release focused on the most urgent vulnerabilities, created to reduce the exposure window between discovering a critical flaw and fixing it, without waiting for the next quarterly CPU.
Do the two critical CVEs (ODI and Coherence) affect every Oracle environment?
No. They specifically affect users of Oracle Data Integrator and Oracle Coherence. Environments that don't use those products aren't impacted by these two specific flaws, but should still review the remaining 1,447 against their own installed footprint.
Need help building a continuous patching process for your Oracle environment instead of chasing the next CPU? Talk to the PeopleDBA Consulting team and schedule a specialized assessment.
