Sunday, 19 July 2026

Oracle Critical Patch Updates and Critical Security Patch Updates: What You Need to Know Before July 21, 2026

Oracle's security patching calendar just got a lot busier — and a lot more important to track. With a new Critical Patch Update landing this week and Critical Security Patch Updates now filling the gaps between quarterly releases, DBAs and security teams have more patch windows to plan around than ever before. Here's a rundown of what these programs are, what's changed recently, and what you should be doing right now.

What is a Critical Patch Update (CPU)?

Critical Patch Updates provide security patches for supported Oracle on-premises products. A CPU is a collection of patches addressing multiple security vulnerabilities — both in Oracle's own code and in third-party components bundled into Oracle products. These patches are usually cumulative, meaning a current CPU typically rolls up fixes from prior releases, and they're available to customers with valid support contracts.

CPUs are released on a predictable quarterly cadence: the third Tuesday of January, April, July, and October. The upcoming schedule is:

  • 21 July 2026
  • 20 October 2026
  • 19 January 2027
  • 20 April 2027

What is a Critical Security Patch Update (CSPU)?

Newer to Oracle's lineup, Critical Security Patch Updates provide targeted, high-priority security fixes in a smaller, more focused format — designed to be easier to apply with minimal disruption than a full quarterly CPU. Rather than replacing the CPU program, CSPUs complement it, giving customers more frequent opportunities to close out high-priority vulnerabilities between the big quarterly releases. Like CPUs, they require a valid support contract.

Oracle released the first Critical Security Patch Update on May 28, 2026, and has continued the cadence with a June 2026 release. Going forward, CSPUs land on the third Tuesday of February, March, May, June, August, September, November, and December — effectively filling every month that doesn't already have a CPU. The upcoming CSPU dates are:

  • 18 August 2026
  • 15 September 2026
  • 17 November 2026
  • 15 December 2026

Put together, CPUs and CSPUs mean Oracle now ships a security update essentially every month of the year.

Where things stand as of July 2026

Checking Oracle's Critical Patch Updates, Critical Security Patch Updates, Security Alerts and Bulletins page, the most recently completed quarterly release is the April 2026 CPU (Revision 2, published April 24, 2026). Since then, Oracle has issued two Critical Security Patch Updates — May 2026 (Rev 1, May 28) and June 2026 (Rev 1, June 16) — along with standalone security alerts for individual high-impact CVEs, including CVE-2026-35273 (Rev 1, June 10, 2026).

That brings us to the next big date on the calendar: July 21, 2026, when the next quarterly Critical Patch Update is due.

Why the July 2026 CPU deserves extra attention

Early advisory details point to this being a heavier-than-usual release. Reports on the pre-release notification indicate the July 2026 CPU addresses roughly 5 critical-severity vulnerabilities (CVSS 9.0+) and 12 or more high-severity flaws, spread across widely deployed products including Oracle WebLogic Server, PeopleSoft, Oracle Identity Manager, Oracle WebCenter, WebCenter Capture, and Oracle VirtualBox.

The most serious issue flagged so far is a pre-authentication remote code execution vulnerability in PeopleSoft (CVSS 9.8), which is reportedly already being actively exploited in the wild in combination with CVE-2026-35273 by a known threat actor group. Other near-maximum-severity issues include unauthenticated RCE vulnerabilities in WebLogic Server (CVSS 9.9) and Identity Manager (CVSS 9.9), plus two HTTP-exploitable RCE flaws in WebCenter Capture (CVSS 9.9 each).

If you run PeopleSoft, WebLogic, Identity Manager, or WebCenter in production, this isn't a "patch it next month" release — it's a "get it on the calendar for this week" release, especially given the active exploitation reports.

Why Oracle is pushing faster patching, not just more patches

A recent Oracle Database blog post, Prepare Now: Apply the Upcoming Oracle Database Release Update Immediately Upon Availability, makes the case for why this matters beyond any single CVE. The post urges customers to prepare now for the upcoming Database Release Update — including Oracle Database 19c Release Update 19.32 and Oracle AI Database 26ai Release Update 23.26.3 — and to apply it promptly across all systems once it's available.

AI models are accelerating both vulnerability discovery and exploitation, and are increasingly capable of chaining multiple weaknesses across the application and data stack into complex, multi-step attacks. In other words, the gap between a vulnerability becoming public and it being weaponized is shrinking, which shrinks the safe window for "we'll get to it next sprint" patching.

Oracle's specific pre-release recommendations include:

  • Inventorying all database infrastructure components so nothing gets missed
  • Confirming systems are running supported Long-Term Support releases
  • Taking advantage of Oracle's complimentary patching and security tooling
  • Building out accelerated testing procedures so patches don't stall in QA
  • Reviewing high-availability technologies to enable minimal-downtime deployment
  • Validating backup and recovery processes before, not after, you need them

What this means for your patch calendar

With CPUs and CSPUs now running nearly every month, ad hoc patching is no longer a workable strategy. A few practical takeaways:

  1. Build the recurring cadence into your change management process now. Third-Tuesday releases are predictable — there's no reason to be caught off guard by them.
  2. Treat CSPUs as real work, not optional extras. They're smaller by design, but they exist specifically to close high-priority gaps between quarterly CPUs.
  3. Prioritize by exploitability, not just CVSS score. The July 2026 CPU is a good example — actively exploited flaws (like the PeopleSoft RCE) should jump the queue regardless of what else is in the release.
  4. Pre-stage your testing and HA/downtime plans before the release drops, following Oracle's own guidance, so the time between "patch available" and "patch applied in production" is measured in days, not weeks.

Sources:

 

No comments:

Post a Comment

Note: only a member of this blog may post a comment.