Oracle Critical Patch Updates, Critical Security Patch Updates and Security Alerts: Release Calendar

Oracle's Patching Schedule: Why the Release Calendar Matters

Oracle publishes security fixes through three separate mechanisms. Each has its own timing, scope, and urgency. If you run Oracle products in production — EBS, Oracle Database, APEX, Middleware, or any combination — the release calendar for oracle critical patch updates, critical security patch updates and security alerts is not background reading. It is operational information your team needs to act on.

Critical Patch Updates (CPUs) are Oracle's primary vehicle for security fixes. Released four times per year, on the Tuesday closest to the 17th of January, April, July, and October. A single CPU can cover dozens or hundreds of vulnerabilities across Oracle's entire product range, which means one quarterly release can touch your whole Oracle estate at once. That alone should shape how you plan testing windows and change freezes.

Critical Security Patch Updates (CSPUs) are a subset of the CPU process — Oracle historically used them where security-only fixes needed separating from broader patch content. Most patching has since moved under the unified CPU banner. But the CSPU designation still appears in Oracle's documentation, particularly for older product lines. It matters when you are reviewing historical advisories or maintaining legacy environments that haven't fully migrated.

Security Alerts sit outside the quarterly schedule entirely.

Oracle issues these when a vulnerability is severe enough — or actively exploited in the wild — that it cannot wait for the next CPU. We see organisations treat Security Alerts like standard patches, queuing them into the next maintenance window. That is a meaningful risk exposure. They need their own response process, separate from your quarterly rhythm.

So what does this three-tier structure actually mean in practice?

Your patching programme has to account for both the predictable and the unpredictable. The quarterly CPU dates give you fixed points to plan around. Security Alerts do not give you that courtesy.

For teams running Oracle E-Business Suite, this is especially complicated. EBS carries its own patch prerequisites, compatibility dependencies, and testing requirements that make fast turnarounds on unscheduled patches genuinely difficult.

The severity ratings Oracle publishes alongside each CPU — using CVSS scoring — also need context, not just a headline number. A critical CVSS score on a component with no network exposure carries different urgency than a medium-score vulnerability sitting on a public-facing endpoint. Reading the calendar means reading it in context.

Treating the Oracle patch release calendar as a passive reference is where most organisations fall short. It is a planning tool. Whether you are managing a single Oracle Database instance or a complex EBS and Middleware estate, aligning your internal processes to Oracle's release cadence — and having a clear, tested protocol for out-of-cycle Security Alerts — is the baseline everything else in your Oracle security programme depends on.

What Is an Oracle Critical Patch Update (CPU)?

An Oracle Critical Patch Update (CPU) is the formal mechanism Oracle uses to deliver security fixes across its entire product portfolio. If you manage Oracle software — database, middleware, enterprise applications — the CPU is the document and patch bundle you need to understand and act on.

Oracle Critical Patch Update (CPU)

An Oracle Critical Patch Update is a quarterly collection of security patches that addresses vulnerabilities across Oracle's product portfolio, released in January, April, July, and October each year.

How CPUs Are Released and Why the Schedule Matters

Oracle publishes CPUs on a fixed quarterly schedule: the Tuesday closest to the 17th of January, April, July, and October. The predictability is intentional. It lets organisations plan patching windows, allocate testing resources, and fit remediation into existing change management cycles.

The schedule is published well in advance as part of the broader oracle critical patch updates, critical security patch updates and security alerts: release calendar. A CPU release should never catch a prepared team off guard.

Each CPU is cumulative. Miss April, apply July — you still get all the April fixes. No sequential patching required. That's a genuine practical benefit for teams on longer maintenance cycles.

It is not, however, a reason to delay.

Reading a CPU Advisory

Each advisory is built around a risk matrix. For every product family covered, Oracle lists the affected versions, the vulnerable component, the attack vector, and the CVSS score.

CVSS scores run from 0 to 10:

• Critical (9.0–10.0): Remotely exploitable, no authentication required. Act immediately.
• High (7.0–8.9): Significant risk, typically exploitable remotely or with low-privilege access.
• Medium (4.0–6.9): Exploitation usually requires specific conditions or authenticated access.
• Low (0.1–3.9): Limited impact, constrained by access requirements or scope.

Pay close attention to the attack vector column. Oracle flags whether a vulnerability is remotely exploitable without credentials — listed as "network" attack vector with "none" for authentication. Anything carrying those attributes alongside a high or critical CVSS score should be treated as an emergency. Regardless of your standard patching cadence.

CPU vs. CSPU vs. Security Alert: Understanding the Differences

The CPU is not Oracle's only patching vehicle. Two others sit alongside it: the Critical Security Patch Update (CSPU) and the Security Alert. Each serves a different purpose and carries different urgency.

Confusing them — or applying the same response timeline to all three — is a common and costly mistake.

Security Alerts are the most time-sensitive of the three. Oracle issues them when a vulnerability is already being exploited in the wild, or when the risk is severe enough that waiting for the next CPU is not acceptable.

When one lands, your team begins the patch assessment process immediately. Not at the next scheduled maintenance window.

Why the Cumulative Model Demands a Consistent Patching Discipline

Because CPUs are cumulative, some teams fall into the habit of skipping cycles — patching every six or twelve months instead. We see this regularly during technical audits. It feels manageable until it isn't.

The CVSS scores in a CPU reflect vulnerability severity at the time of disclosure. Six months later, some of those same vulnerabilities have public exploits, working proof-of-concept code, or active ransomware campaigns built around them.

The cumulative format is a convenience. Not an invitation to delay.

A sound baseline: assess every CPU on release day, prioritise anything scoring 7.0 or above, and get those patches applied within 30 days. Lower-severity fixes should follow before the next CPU arrives. For Security Alerts, the process starts the moment Oracle publishes the advisory — not the following Monday.

Critical Security Patch Updates (CSPUs): Out-of-Band Emergency Fixes

Oracle's quarterly CPU schedule handles planned, non-urgent vulnerabilities well enough. But some flaws can't wait three months.

When Oracle identifies something actively exploited in the wild — or a zero-day with immediate risk to production systems — it issues a Critical Security Patch Update (CSPU). A patch released outside the normal quarterly window entirely.

Critical Security Patch Update (CSPU)

A CSPU is an emergency security patch issued by Oracle outside its standard quarterly CPU schedule to address a critical vulnerability that poses an immediate, actively exploited risk to Oracle products.

What Triggers a CSPU?

Oracle doesn't issue these often. They're reserved for specific, high-severity conditions:

• Active exploitation in the wild — a vulnerability already being used in real attacks before a patch exists
• Zero-day disclosures — a flaw that's publicly known and unpatched, giving attackers a head start
• CVSS scores indicating critical risk — typically a base score of 9.0 or above, where exploitation requires no authentication or user interaction
• Coordinated disclosure pressure — security researchers or government agencies like CISA pushing Oracle to act ahead of schedule

When any of these apply, Oracle publishes a Security Alert and releases the patch. The urgency is at least equal to a standard quarterly CPU. Usually higher, because the threat is already live.

For a detailed breakdown of how these differ from standard patches, read our guide on what is a CSPU.

How to Subscribe to Oracle Security Alerts

Oracle provides a dedicated notification service so security and IT teams hear about a CSPU the moment it's published. To subscribe:

Many organisations also pipe Oracle's security announcements into their SIEM platform or a threat intelligence feed.

Worth doing.

A CSPU can drop on any day of the week, including weekends, with no advance notice.

Why Oracle EBS and Database Environments Need an Accelerated Response Playbook

This is where most organisations struggle.

Oracle E-Business Suite and Oracle Database environments typically sit at the centre of financial, HR, or supply chain operations. Patching has real business impact — downtime to plan, testing cycles to run, change management to follow. None of that disappears when a CSPU lands.

The threat timeline doesn't pause for your change advisory board.

A pre-agreed accelerated response playbook solves this. It needs to define:

• ✓Who owns the initial assessment — typically your security team, not just the DBA
• ✓A fast-track testing window — how quickly can you validate the patch in a non-production environment?
• ✓Emergency change approval authority — who can sign off an out-of-hours deployment?
• ✓Rollback procedures — what happens if the patch causes a regression?

We see this repeatedly during audits. Organisations without a playbook spend the first 24 to 48 hours of a CSPU event in internal debate rather than actually remediating. That gap is exactly what attackers count on.

Treating CSPUs as an edge case is a risk your business can't afford. They sit alongside the standard oracle critical patch updates, critical security patch updates and security alerts: release calendar — but they run on a completely different timeline. Build your response capability before you need it.

Security Alerts: Targeted Advisories for High-Severity Vulnerabilities

Security Alerts are different from both Critical Patch Updates and Critical Security Patch Updates — and the distinction matters. CPUs follow a fixed quarterly schedule. CSPUs are unscheduled emergency releases covering a defined scope. Security Alerts are something else entirely.

Narrow. Product-specific. Published when a vulnerability is considered too severe, or too actively exploited, to wait for any scheduled release window.

They're Oracle's most urgent patching communication. Issued outside all calendars. Tied to a single vulnerability — or a tightly related cluster of flaws in a specific product line.

Oracle doesn't publish Security Alerts on any predictable timetable. They appear when the threat warrants it. Organisations that rely solely on quarterly calendar reminders will miss them entirely unless they have active monitoring in place.

How Government Bodies Amplify Oracle Security Alerts

Security Alerts don't exist in isolation. When Oracle publishes one for a high-severity vulnerability — particularly in widely deployed enterprise products — national cybersecurity agencies respond. The UK's National Cyber Security Centre (NCSC) and the US Cybersecurity and Infrastructure Security Agency (CISA) routinely issue their own advisories referencing the same Oracle alert, reinforcing the urgency and pushing it well beyond Oracle's own customer base.

This has real operational consequences.

An NCSC advisory citing an Oracle Security Alert carries regulatory and reputational weight that a vendor bulletin alone often doesn't. In regulated sectors — finance, public services, critical national infrastructure — an NCSC or CISA advisory frequently triggers internal escalation procedures that a standard Oracle notification wouldn't touch.

The government advisory landscape effectively acts as a secondary amplification system. It pulls Oracle Security Alerts into risk and compliance conversations that might otherwise stall.

For Oracle E-Business Suite specifically, this dynamic has been particularly pronounced. NCSC advisories have called directly for immediate patching action on critical EBS vulnerabilities. Understanding how those government communications relate to Oracle's own alert structure shapes how patch prioritisation decisions get made internally — it's not background reading. Our analysis of the NCSC advisory landscape for Oracle EBS covers this in detail at /insights/security/oracle-ebs/ncsc-advisory/, with further reading available at /insights/oracle-ebs-security-ncsc-advisory/.

Operational Urgency for Oracle EBS 12.1 and 12.2 Environments

Unpatched Oracle EBS environments sit at the centre of the Security Alert risk picture. EBS 12.1 and 12.2 are consistently among the most targeted Oracle products in Security Alerts and government advisories — partly because of the sensitivity of the data involved (financials, HR records, supply chain data), and partly because so many installations are behind on patching.

The situation for EBS 12.1 is particularly stark.

Premier Support ended in December 2021. It's now in Sustaining Support, which does not include new security patches for newly discovered vulnerabilities. If you're still running EBS 12.1 without a compensating control strategy, you are not receiving Security Alert patches. Full stop.

EBS 12.2 remains under active support — but its modular architecture creates its own complications. Security Alert patches for specific components, such as the Oracle Application Framework or individual EBS modules, require careful dependency analysis before you can safely apply them.

So what does that mean in practice? Security Alerts, by design, demand an immediate response. There's no managed window, no scheduled downtime planning cycle, no opportunity to batch the fix with the next quarterly CPU. When Oracle publishes a Security Alert for EBS, the question isn't really whether to patch — it's whether your organisation has the process in place to act quickly without breaking things.

Most don't. We see this constantly during technical audits.

Organisations without a tested, documented emergency patching procedure for Oracle EBS are effectively unprepared for Security Alerts. Testing environments ready to go. Rollback plans documented. Stakeholder communication protocols agreed in advance. These aren't optional additions to your Oracle patching programme — they're prerequisites for managing it at all.

The Oracle Patch Release Calendar: Quarterly Windows and Key Dates

Oracle publishes Critical Patch Updates on a fixed quarterly schedule: the second Tuesday of January, April, July, and October. That rhythm has held for years. It gives security and operations teams a predictable window to plan testing, change control approvals, and deployment — but only if you're actually using it.

Missing a cycle isn't just a compliance issue. It means running known-vulnerable software for up to three additional months until the next CPU lands.

Understanding the calendar is half the battle. The other half is building an internal process that maps to Oracle's schedule before patches drop, not after.

How the Quarterly Schedule Works

Oracle announces upcoming CPU dates well in advance through its security alerts portal. The pre-announcement typically comes several weeks out and confirms the date, scope, and any embargo notices. On release day, Oracle publishes the full advisory — the Risk Matrix, affected products, CVE references, and CVSS scores, all at once.

Don't wait for release day to start preparing.

The gap between pre-announcement and release is your window to audit Oracle product versions in your environment, confirm what's in production, and identify who owns each system's change control process.

Teams that treat release day as day one are already behind.

2025–2026 CPU Release Date Reference

The dates below cover confirmed and projected CPU releases for 2025 and 2026. Use them as planning anchors — your change control and testing cycles should be mapped backwards from each release date, not built around whatever's convenient at the time.

For a full breakdown of scope, affected products, and patch priorities for the Q4 2026 release, see our October 2026 CPU deep-dive.

Planning Around the Calendar

A common mistake we see is teams treating CPU release day as the starting gun. By that point, your test environment should already be staged, your change control window reserved, and stakeholder communications drafted. That preparation alone consistently cuts the time between patch release and production deployment — which directly shrinks the window attackers have to exploit publicly disclosed vulnerabilities.

So what does that look like for larger environments?

If your organisation runs Oracle across multiple product families — Database, WebLogic, E-Business Suite, Fusion Middleware — you'll need separate testing tracks for each. Not all patches in a CPU are interdependent. Applying them in the wrong sequence can introduce new problems. Always check Oracle's patch application order notes in the advisory before you start.

One more thing worth flagging.

Between quarterly CPUs, Oracle occasionally issues Security Alerts for actively exploited vulnerabilities. These don't wait for the calendar. Oracle critical patch updates, critical security patch updates and security alerts: release calendar information is only useful if someone on your team is watching it continuously — not just checking in on CPU day.

Patch Planning for Oracle EBS, Database, APEX and Middleware

Patching a mixed Oracle estate is never a single-system job. Most production environments run Oracle E-Business Suite on top of an Oracle Database, with WebLogic Server handling the application tier — and potentially Oracle APEX or Oracle Forms and Reports sitting alongside it. Each component has its own patch stream, its own prerequisites, and its own testing demands.

Get the sequencing wrong and you risk broken integrations, invalidated certifications, or one layer of your stack still exposed after everything else has been patched.

This section covers how to plan and execute patching across all four layers in a controlled, repeatable way.

Understanding the Dependency Stack

Before you schedule anything, map the dependency chain.

Oracle's certification matrix dictates which database version a given EBS release requires, which JDK version WebLogic needs, and which database drivers APEX relies on. Those relationships determine your patching order. Skipping this step is where most failed patch cycles start.

The general sequencing rule:

For a detailed walkthrough of the database and EBS application tier patching relationship, see our guidance on EBS and database patching.

Pre-Patch Planning: What to Do Before the Maintenance Window Opens

Patch day failures almost always trace back to preparation gaps.

We see this constantly during technical audits — teams that rushed into the maintenance window without completing the groundwork.

Read the patch README files in full. Oracle includes prerequisite patch numbers, conflict resolution instructions, and known issues specific to each platform. Not optional reading.

Check the Oracle Patch and Upgrades portal for superseded patches. A patch released in January may already be superseded by a later bundle — applying the older version wastes time and leaves gaps.

Validate that your cloned or non-production environment mirrors production closely enough to be meaningful. Same database version, same ORACLE_HOME structure, representative data volumes for post-patch functional testing. If the test environment is stale, the test results are worthless.

Confirm backup completion and verify restore capability. A verified backup — not just a completed one — is the baseline requirement before any production patching begins.

How AppsolveGroup Supports Your Oracle Patching Programme

Treating the Oracle patch release calendar as a passive reference is where most organisations fall short. It is a planning tool.

Stay Ahead of Oracle's Patch Calendar — Talk to AppsolveGroup

You might also find helpful