On 21 July 2026, Oracle published its quarterly Critical Patch Update — and it is the largest single security release in the company’s history. The July 2026 CPU addresses 1,434 distinct CVEs with 1,449 patches spanning 334 products, of which roughly 600 are remotely exploitable without any authentication. For context, that is more than double the scale of a typical Oracle CPU, and it lands in the same month that UK regulators formally designated Oracle a Critical Third Party to the financial sector. Every UK organisation running any Oracle product — E-Business Suite, MySQL, PeopleSoft, Fusion Middleware, GoldenGate, or the Oracle Database itself — now has a hard patching deadline and a very short window to meet it.

The headline number is alarming enough, but the detail is worse. A CVSS 9.9 maximum-severity flaw affects every supported version of the Oracle Database Server, from 19.3 through 23.26.2. A pre-authentication remote code execution flaw in PeopleSoft (CVE-2026-35278, CVSS 9.8) was already being exploited in the wild by the ShinyHunters group against more than 300 servers and over 100 organisations before this patch shipped. And 86% of the fixes address vulnerabilities in bundled open-source components, meaning the exposure reaches far beyond code Oracle wrote itself. This briefing breaks down what shipped on 21 July, which products carry the greatest risk for UK SMEs, and what a disciplined database security audit looks like this week.

1,434

CVEs fixed in the July 2026 CPU — the largest quarterly release in Oracle’s history

600+

Flaws remotely exploitable without authentication — no credentials required

9.9

Maximum CVSS score — a Database Server flaw affecting all versions 19.3–23.26.2

334

Distinct Oracle products receiving patches across 1,449 total fixes

What Oracle actually shipped on 21 July 2026

Oracle’s Critical Patch Update is a quarterly, coordinated release that bundles security fixes across the company’s entire product portfolio into a single day. The July 2026 edition broke every previous record. Where a large CPU historically sat in the 300–450 CVE range, this one addresses 1,434 CVEs with 1,449 patches across 334 products — a step-change in volume rather than an incremental increase. Oracle attributes the jump in part to AI-assisted vulnerability discovery, using its Antares model family alongside an internal automated code-checking capability to surface flaws at a scale manual review could never reach.

The distribution is heavily weighted toward Oracle’s enterprise applications and middleware. Oracle E-Business Suite received 410 patches, 45 of them exploitable without authentication. Fusion Middleware received 355 patches, of which 219 are remotely exploitable without credentials and 154 are rated critical. PeopleSoft received 84 patches, headlined by the already-exploited CVE-2026-35278. The Oracle Database Server carried the single highest score of the release at CVSS 9.9, affecting all supported versions from 19.3 to 23.26.2. On the lighter end, MySQL received 54 patches (9 remotely exploitable, none rated critical), GoldenGate 27 patches (CVSS 9.1 maximum), and Oracle SQL Developer 5 patches — all five remotely exploitable.

The most strategically important detail is that 86% of the patched CVEs are not in Oracle’s own code at all — they are in third-party open-source components bundled inside Oracle products. This reflects the modern reality of enterprise software: the attack surface is a supply chain of libraries, frameworks and runtimes, and a single vulnerable component — a logging library, an XML parser, a serialisation framework — can appear in dozens of products simultaneously. It also means that “we only run one Oracle product” is not the reassurance it sounds like, because the same underlying flaw may be reachable through several different entry points.

A PeopleSoft zero-day was weaponised before this patch shipped

The single most urgent item in the July 2026 CPU is CVE-2026-35278, a CVSS 9.8 pre-authentication remote code execution flaw in Oracle PeopleSoft. It was already being exploited in the wild by the ShinyHunters extortion group before Oracle released the fix — a genuine zero-day. Reporting attributes more than 300 compromised servers across 100-plus organisations to this single flaw. Pre-authentication RCE means an attacker needs no username, no password and no foothold: network access to a vulnerable PeopleSoft instance is sufficient to run arbitrary code. Any UK organisation running PeopleSoft that has not applied the July CPU should treat its installation as a live target, not a theoretical risk. If PeopleSoft is internet-reachable in any form, assume it has already been scanned.

How the July 2026 CPU came together — a chronology

This release did not appear in isolation. It is the culmination of a year in which Oracle’s enterprise products moved from a niche concern to one of the most actively targeted software estates in the market, and in which UK regulators tightened the compliance framework around the vendors the financial sector depends on. The timeline below sets the July CPU in that context.

August 2025 — Cl0p targets Oracle E-Business Suite

The Cl0p ransomware operation weaponises a critical authentication-bypass flaw in Oracle E-Business Suite, exposing financial, payroll and HR data at dozens of organisations. It establishes EBS as a priority target for professional extortion groups and sets the template for the year that follows: find an unauthenticated flaw in an Oracle enterprise application, monetise it through data theft rather than encryption.

June 2026 — ShinyHunters begin exploiting PeopleSoft

The ShinyHunters group begins exploiting CVE-2026-35278, a pre-authentication remote code execution flaw in PeopleSoft, before any Oracle advisory exists. Over the following weeks the campaign compromises more than 300 servers across in excess of 100 organisations, harvesting data for extortion. Because the flaw requires no authentication and executes on the application tier, defenders without dedicated PeopleSoft monitoring have almost no visibility of the intrusion.

July 2026 — Oracle’s AI discovery pipeline surfaces a record backlog

Oracle’s internal use of its Antares model family and an automated internal code-checking capability accelerates vulnerability discovery across the product portfolio. The result is an unprecedented number of validated findings queued for a single CPU — the mechanism behind the record 1,434-CVE total. AI-assisted discovery cuts both ways: it helps Oracle find flaws faster, and it signals that threat actors are using the same techniques against the same code.

13 July 2026 — Oracle designated a UK Critical Third Party

UK regulators formally designate Oracle a Critical Third Party (CTP) to the financial sector, placing it within the oversight regime for suppliers whose failure could threaten financial stability. The designation raises the compliance stakes for every regulated firm and its supply chain: an unpatched Oracle system is no longer just an IT risk, it is a matter that touches operational-resilience obligations.

21 July 2026 — Oracle releases the July 2026 Critical Patch Update

Oracle ships 1,449 patches addressing 1,434 CVEs across 334 products — the largest quarterly release in its history. The headline items: a CVSS 9.9 Database Server flaw affecting all versions 19.3–23.26.2; the already-exploited PeopleSoft CVE-2026-35278; 219 unauthenticated Fusion Middleware flaws; and 45 unauthenticated E-Business Suite flaws. The Cyber Essentials v3.3 14-day clock for critical patches starts today.

22 July 2026 — Security community publishes CPU analysis

Vulnerability-management vendors and threat-intelligence teams publish detailed breakdowns of the release, flagging the Database Server 9.9, the PeopleSoft zero-day and the Fusion Middleware unauthenticated cluster as the priority triage targets. The consistent message: prioritise by exploitability and exposure, not by CVE count, and treat any internet-reachable Oracle application tier as an emergency.

26 July 2026 — Today: five days into a closing window

Five days after release, patch-diff reverse engineering of the highest-value flaws is well underway in threat-actor circles, and automated scanning for unpatched Fusion Middleware and PeopleSoft instances is active. UK organisations still on the pre-July baseline are inside the exploitation window for the most severe items. The instruction — apply the CPU — is obvious; the hard part is that most UK SMEs cannot quickly confirm which Oracle components they run, where they are reachable from, or whether the July patches have landed on every node.

Where the risk sits — patch counts by Oracle product family

A CPU this large is impossible to action as a single undifferentiated task. The only workable approach is to triage by product family, weighting each by the number of unauthenticated, remotely exploitable flaws it carries — because those are the ones an attacker can reach without first stealing a credential. The chart below shows the relative patch weight of the major product families in the July 2026 release, scaled to the family carrying the largest share of the fixes.

E-Business Suite (410 patches, 45 unauthenticated)

Highest volume

Fusion Middleware (355 patches, 219 unauthenticated, 154 critical)

Highest exposure

PeopleSoft (84 patches, CVE-2026-35278 exploited in wild)

Actively exploited

MySQL (54 patches, 9 remotely exploitable, 0 critical)

Moderate

GoldenGate (27 patches, CVSS 9.1 max)

Elevated

Database Server (CVSS 9.9 max, all versions 19.3–23.26.2)

Highest severity

SQL Developer (5 patches, all remotely exploitable)

Small but total

Two families dominate the priority list. Fusion Middleware is the standout exposure risk: 219 of its 355 patches are exploitable with no authentication, and 154 are critical — a concentration of internet-reachable, credential-free flaws that any exposed WebLogic, HTTP Server or SOA component turns into a direct entry point. PeopleSoft is the standout active risk, because its headline flaw is already being exploited rather than merely exploitable. The Database Server 9.9 sits slightly apart: its severity is maximal and its version coverage is total, but the practical risk depends on whether an attacker can reach the database tier directly — which, in a well-segmented estate, they should not be able to do.

The open-source problem — why 86% of these CVEs are not Oracle’s code

The most instructive single statistic in this CPU is not the 1,434 total — it is that 86% of the patched vulnerabilities live in bundled open-source components rather than in code Oracle authored. Modern enterprise software is assembled, not written from scratch: an Oracle product may embed dozens of open-source libraries for logging, serialisation, XML processing, cryptography, HTTP handling and more. When one of those libraries has a flaw, every product that bundles it inherits the flaw — which is precisely why a single underlying CVE can generate patches across many different Oracle products at once.

Share of July 2026 CPU CVEs residing in bundled open-source components rather than Oracle-authored code — the software-supply-chain surface that most organisations never inventory

For a UK SME, the practical consequence is that you cannot patch what you cannot see. Very few organisations maintain a software bill of materials (SBOM) for their commercial products, so when a bundled component is found vulnerable, they have no way to know which of their systems is affected without waiting for the vendor’s advisory and its consolidated patch. Oracle’s CPU model handles this for you — but only if you apply it. The 86% figure is the clearest argument for treating quarterly CPU application as a non-negotiable governance item: it is the single control that closes the supply-chain exposure you have no independent visibility into.

The Oracle exposure grid — where UK SMEs score themselves

Not every Oracle estate carries the same risk from this release. The scorecard below reflects the eight factors that most determine whether an organisation is at immediate risk, at risk of a secondary wave, or effectively protected despite being on an older baseline. Score yourself honestly against each row before deciding your triage order.

July 2026 Oracle CPU exposure assessment — UK SME self-scoring

PeopleSoft instance internet-reachable and not yet on the July CPU High

Fusion Middleware (WebLogic / HTTP Server / SOA) exposed to untrusted networks High

E-Business Suite application tier reachable via HTTP from outside the LAN High

Oracle Database Server not yet patched and not network-segmented from app tiers High

No live inventory of which Oracle products and versions are actually running Mid

No anomalous-access monitoring on Oracle application or database tiers Mid

GoldenGate or MySQL in use but excluded from the quarterly CPU cycle Mid

Cyber Essentials v3.3 14-day patching SLA not documented for Oracle systems Low

Any organisation scoring High on the first two rows is at immediate risk and should treat the July CPU as an emergency change rather than a scheduled one. An internet-reachable PeopleSoft instance maps directly onto an actively-exploited flaw, and an exposed Fusion Middleware component maps onto 219 credential-free entry points. The Mid and Low rows are not the emergency — but they are the reason the emergency keeps recurring, because without an inventory, monitoring and a documented SLA, every future CPU becomes another scramble.

What a compromise costs — recovery bands by organisation size

The cost of a successful exploitation of a July 2026 CPU flaw varies enormously with the product compromised and the data it holds, but it is anchored to measurable categories: incident response, forensic investigation, regulatory notification, and the operational cost of taking a business-critical Oracle system offline. The table below gives indicative recovery-cost bands for UK organisations of different sizes, based on the typical scenario of an unauthenticated application-tier compromise (PeopleSoft or Fusion Middleware) leading to data theft and extortion.

Organisation size	Typical Oracle footprint	Likely detection lag	Indicative recovery cost band
Small business (10–50 staff)	MySQL, one packaged Oracle app or hosted module	7–30 days (limited monitoring)	£25,000–£120,000
SME (50–250 staff)	E-Business Suite or PeopleSoft plus supporting middleware	5–21 days	£120,000–£600,000
Mid-market (250–1,000 staff)	Multiple Oracle apps, Fusion Middleware, Database Server	3–14 days	£500,000–£2.5m
Large / regulated (1,000+ staff)	Full Oracle estate, CTP-scoped financial systems	1–7 days (mature SOC)	£2m+ plus regulatory and resilience impact

These figures do not include the harder-to-quantify costs: reputational damage where customer or supplier data is stolen, the ICO 72-hour notification clock where personal data is involved, contractual penalties for a supply-chain breach, and — for financial-sector firms now that Oracle is a designated Critical Third Party — the operational-resilience scrutiny that follows any material outage of a critical dependency. For a UK SME without cyber insurance that explicitly covers enterprise-application compromise, a single successful exploitation of a flaw in this CPU can be existential.

Reactive versus proactive Oracle patch management

Reactive posture

What most UK SMEs running Oracle do today

Apply Oracle CPUs weeks or months after release, pending internal change control
No live inventory of which Oracle products, modules and versions are running
Application tiers (PeopleSoft, EBS, WebLogic) partially reachable from untrusted networks
No visibility of bundled open-source components inside Oracle products
Database and application access logs not reviewed between patches
Discover compromise only when data appears on an extortion site
Cyber Essentials v3.3 14-day patching window not tracked for Oracle systems
CTP designation treated as a legal note, not an operational-resilience trigger

Proactive posture

Where Cloudswitched takes your database and application security

Oracle CPU patching scheduled within 14 days of release on a documented SLA
Live inventory of every Oracle product, version and node maintained continuously
Application tiers isolated from internet ingress and untrusted internal zones
Software bill of materials mapped so bundled-component flaws are traceable
Database and application access-log review built into the IT admin cycle
Anomaly detection on Oracle application and database query patterns
CE v3.3 patching SLA documented and evidenced for every Oracle system
Critical-dependency resilience reviewed quarterly against the CTP framework

18%

Estimated share of UK SMEs with a documented Oracle CPU patching schedule aligned to the CE v3.3 14-day SLA — leaving the large majority to absorb a record 1,434-CVE release without a defined process

Practical tip: triage by exposure before you triage by severity

With 1,434 CVEs, patching “in CVSS order” is a trap — a 9.9 on an internal, well-segmented database tier is less urgent than a 9.8 on an internet-reachable PeopleSoft instance an attacker is actively scanning for. Work the list in three passes. Pass one: anything unauthenticated and internet-reachable — Fusion Middleware, PeopleSoft, exposed EBS. Pass two: unauthenticated flaws on internally-reachable application tiers. Pass three: everything requiring authentication or local access, including most Database Server items in a segmented estate. If you cannot patch an exposed application tier within the 14-day window, the fastest compensating control is to remove its reachability — restrict inbound HTTP to trusted sources at the firewall or WAF until the CPU is applied. Reachability is the variable you control fastest.

At-a-glance reference: the July 2026 CPU by product family

Product family	Patches	Notable severity / exploitability	Priority for UK SMEs
Oracle E-Business Suite	410	45 exploitable without authentication	High if app tier is externally reachable
Fusion Middleware	355	219 unauthenticated, 154 critical	Critical — highest unauthenticated exposure
PeopleSoft	84	CVE-2026-35278, CVSS 9.8 pre-auth RCE, exploited in wild	Critical — active exploitation confirmed
Oracle Database Server	—	CVSS 9.9 max, all versions 19.3–23.26.2	High — depends on tier segmentation
MySQL	54	9 remotely exploitable, 0 critical	Moderate — patch on the standard cycle
GoldenGate	27	CVSS 9.1 maximum	Elevated where replication is business-critical
Oracle SQL Developer	5	All 5 remotely exploitable	Small but total — patch developer tooling too

The single clearest takeaway from this table is that CVE count and urgency are not the same thing. E-Business Suite carries the most patches, but Fusion Middleware carries the most unauthenticated exposure, and PeopleSoft carries the only flaw already being exploited. A UK SME with limited change-management capacity should read this table top-to-bottom by the “priority” column, not by patch volume: PeopleSoft and Fusion Middleware first, then Database Server and EBS, then MySQL, GoldenGate and SQL Developer on the standard cycle.

Related briefings from the Cloudswitched news series

This record Oracle CPU sits within a wider 2026 pattern of enterprise-software targeting, AI-accelerated vulnerability discovery and tightening UK compliance. Our recent briefings connect directly: the July 2026 Microsoft Patch Tuesday (622 CVEs, SharePoint and ADFS zero-days) shows the same month’s patch load on the Microsoft side and the volume problem facing UK IT teams; the Proofpoint AI ransomware report (58% of UK victims paid) illustrates why extortion groups like ShinyHunters invest in unauthenticated enterprise-app flaws; the Check Point June 2026 UK attack data (1,589 weekly attacks) quantifies the background rate of automated scanning that finds unpatched systems; the Scattered Spider TfL sentencing covers the social-engineering route into the same enterprise estates; and the NCSC/FSB router advisory reinforces why network reachability is the variable that turns a theoretical CVE into an exploited one. For the cloud-dependency angle, the Azure West US outage resilience briefing pairs naturally with Oracle’s new Critical Third Party status.

Do you know exactly which Oracle products you run — and whether they are patched?

The July 2026 CPU is impossible to action without a live inventory of your Oracle estate and a map of where each component is reachable from. Cloudswitched Database Reporting and Analytics gives you exactly that: a continuous view of your database and application platforms, their versions, their patch status against current CVE catalogues, and the anomaly monitoring that tells you if a flaw has already been used against you.

Talk to us about Database Reporting & Analytics

Frequently asked questions

Why is the July 2026 Oracle CPU so much larger than previous releases?

The July 2026 CPU addresses 1,434 CVEs with 1,449 patches across 334 products, roughly double the scale of a typical large Oracle release. The primary driver is AI-assisted vulnerability discovery: Oracle has been using its Antares model family alongside an internal automated code-checking capability to surface flaws at a scale manual review could not reach. A secondary factor is the open-source supply chain — 86% of the patched CVEs are in bundled third-party components, and a single vulnerable library can generate patches across many Oracle products at once. The larger number is not evidence that Oracle software suddenly became less secure; it reflects a step-change in how quickly flaws are being found and validated for release.

Which single flaw should we patch first?

If you run PeopleSoft, patch CVE-2026-35278 first. It is a CVSS 9.8 pre-authentication remote code execution flaw that was already being exploited in the wild by the ShinyHunters group before Oracle shipped the fix — reporting attributes over 300 compromised servers across more than 100 organisations to it. Pre-authentication RCE means an attacker needs no credentials, so any internet-reachable PeopleSoft instance is a live target. If you do not run PeopleSoft, your first priority is any internet-facing Fusion Middleware component, because that family carries 219 unauthenticated flaws, 154 of them critical. Triage by exposure and exploitability, not by CVSS score alone.

We only run MySQL. Do we still need to act urgently?

Less urgently than an EBS, PeopleSoft or Fusion Middleware operator, but you should still patch on your normal cycle. MySQL received 54 patches in this CPU, of which 9 are remotely exploitable and none are rated critical. That is a materially lower risk profile than the enterprise-application families. The sensible approach is to schedule MySQL patching within your documented maintenance window rather than as an emergency change — but do not skip it, because “no critical flaws” is not the same as “no exploitable flaws”, and unpatched database servers are a standard target for automated scanning. If MySQL underpins a customer-facing or revenue-critical system, tighten the window accordingly.

What does the CVSS 9.9 Database Server flaw mean for us in practice?

The July CPU includes a maximum-severity flaw affecting every supported Oracle Database Server version from 19.3 through 23.26.2 — effectively the entire supported estate. A 9.9 score signals near-total impact on confidentiality, integrity and availability. Whether it is an immediate emergency for you depends on reachability: in a well-segmented environment where the database tier is only accessible from trusted application servers, an attacker cannot reach the flaw without first compromising something else, which buys you time to patch within the 14-day window. In a flat network where the database is broadly reachable, it is an emergency. Either way, apply the patch — but let your network architecture determine whether it goes in tonight or within the fortnight.

Why does it matter that 86% of these flaws are in open-source components?

Because it changes how you have to think about your exposure. When 86% of the patched CVEs live in bundled open-source libraries rather than Oracle’s own code, the same underlying flaw can appear in multiple Oracle products simultaneously — and you have no independent way to see it, because almost no organisation maintains a software bill of materials for its commercial products. You are entirely dependent on the vendor’s advisory and consolidated patch to close the gap. That is precisely why quarterly CPU application should be treated as a mandatory governance control: it is the single action that closes a supply-chain exposure you cannot inventory yourself. It also explains why patch counts have grown — the industry is getting better at tracking vulnerable components across products.

What does Oracle’s UK Critical Third Party designation change for us?

On 13 July 2026, UK regulators formally designated Oracle a Critical Third Party (CTP) to the financial sector — a status reserved for suppliers whose disruption could threaten financial stability. If you are a regulated financial firm, or you supply one, this raises the stakes on unpatched Oracle systems from an IT risk to an operational-resilience matter that regulators can scrutinise. In practice it means Oracle dependencies should appear in your important-business-services mapping, your impact tolerances, and your third-party resilience testing. For a non-financial SME the designation is less directly binding, but it is a strong signal of the direction of travel: enterprise-software dependencies are increasingly treated as systemic risks that boards are expected to govern, not just IT teams.

Our Oracle systems are hosted or managed by a third party. Whose job is patching?

It depends entirely on your contract, and this is exactly the question to resolve in writing this week. Many Oracle managed-service agreements split responsibility — the provider manages infrastructure while the customer retains “application-layer” patching, or vice versa. Do not assume the July CPU has been applied. Ask your provider directly: “Has the July 2026 Oracle CPU been applied to every Oracle product and node in our environment, and can you provide a patch-confirmation report?” Be specific about the high-priority items: PeopleSoft CVE-2026-35278, the Fusion Middleware unauthenticated cluster, and the Database Server 9.9. If your provider cannot confirm application with evidence, treat the systems as unpatched until they can.

How does the Cyber Essentials v3.3 14-day rule apply to a CPU this large?

Cyber Essentials v3.3 requires critical and high-severity patches to be applied within 14 days of release for certified or certifying organisations. That clock started on 21 July 2026 for every applicable flaw in this CPU. The scale of the release does not extend the deadline — but it does make prioritisation essential, because no SME can validate and deploy 1,449 patches evenly across a fortnight. The compliant and practical approach is to demonstrate a risk-based programme: patch the internet-reachable, unauthenticated, critical items first and evidence it, then work through the remainder within the window. Auditors and cyber insurers increasingly expect a documented, evidenced SLA rather than a claim that everything was patched at once. If you cannot meet 14 days on an exposed system, document the compensating control (typically removing reachability) as your interim measure.

We do not run any Oracle products. Is any of this relevant to us?

Two reasons it may be. First, supply chain: if your customers, suppliers, banks or regulators run Oracle enterprise systems and are compromised, the impact can reach you through fraudulent payment instructions, stolen credentials that are reused, or leaked data that includes your organisation’s records. Second, the pattern is platform-agnostic. The lessons here — maintain a live inventory of your database and application estate, know where each component is reachable from, track patch status against current CVE catalogues, and document a patching SLA — apply equally whether you run PostgreSQL, Microsoft SQL Server, MySQL or a bespoke line-of-business database. AI-accelerated vulnerability discovery is now being applied to every major software platform, and record patch loads will not stay unique to Oracle.

What should we do if we suspect we have already been compromised?

If you suspect exploitation — particularly on a PeopleSoft instance, given the confirmed active campaign — work in this order: contain, preserve, review, notify. Contain by restricting network access to the affected system rather than patching immediately. Preserve by taking a forensic snapshot before you change anything, because applying a patch can overwrite the evidence your insurer and investigators will need. Review the application and database access logs for unauthenticated requests and unusual process activity from the point the relevant flaw became exploitable. Notify your cyber insurer’s incident hotline, your managed security or incident-response partner, and — if personal data was accessed — begin the ICO 72-hour clock. Do not patch first and investigate later if you have genuine grounds to suspect a breach: preserve, then investigate, then remediate.

Turn a record Oracle CPU into scheduled maintenance, not a weekend emergency

The July 2026 release — 1,434 CVEs, a live PeopleSoft zero-day, 219 unauthenticated Fusion Middleware flaws — is exactly the kind of event that overwhelms an SME without a defined process. Cloudswitched Database Reporting and Analytics gives you a continuous inventory of your database and application estate, patch-status tracking against current CVE catalogues, exposure mapping, and anomaly monitoring on your most sensitive systems — so that the next record CPU is absorbed as routine, evidenced, 14-day maintenance.

Talk to us about Database Reporting & Analytics

Tags:Database ReportingCyber SecurityIT SupportNetwork Admin

CloudSwitched

London-based managed IT services provider offering support, cloud solutions and cybersecurity for SMEs.