Wednesday, April 29, 2026

Oracle CPU April 2026: A Practical DBA View for Database and EBS Environments

Oracle CPU April 2026 - What DBAs Should Know

Oracle CPU April 2026: What DBAs Should Know Before Patching 19c, 21c, 23ai/26ai and EBS Environments

Blog article draft prepared in HTML format with source links included.

Oracle released the April 2026 Critical Patch Update (CPU), and this quarter is important for every Oracle DBA, Apps DBA, and security team. The April 2026 CPU contains 481 new security patches across Oracle product families. For database teams, the key focus is Oracle Database Server, Oracle Grid Infrastructure, OJVM, Fusion Middleware, GoldenGate, Enterprise Manager, and E-Business Suite dependent components.

This CPU cycle is especially notable because some important Release Updates were not immediately available on the CPU release date. The 19.31 and 23.26.2 Release Updates were reported as delayed, which means DBAs should not wait until the last minute to begin planning.

Do not wait until the patch file is available to start planning.
Use this time for analysis, risk review, inventory, staging, and maintenance planning.

Why April 2026 CPU Is Important

Oracle’s CPU advisory makes it clear that customers should stay on supported releases and apply security patches without delay. In real DBA life, this is not just a patching task — it is a complete operational exercise involving:

  • Security risk analysis
  • Patch availability validation
  • OPatch and inventory review
  • Conflict checking
  • Backup planning
  • Downtime communication
  • Lower environment testing
  • Production rollout
  • Rollback readiness
  • Post-patch validation

In enterprise environments — especially Oracle E-Business Suite, RAC, Data Guard, OEM, GoldenGate, or Exadata — CPU patching should always be handled as a controlled change.

Oracle Database Server Risk Summary

For Oracle Database Products, Oracle listed 26 new security patches, including 8 new security patches for Oracle Database Server. Oracle also noted that 4 of the Oracle Database Server vulnerabilities may be remotely exploitable without authentication.

CVE Component CVSS Risk Area
CVE-2026-33870 Clusterware / Micronaut 7.5 Remote exposure, HTTP related
CVE-2026-35229 Java VM 7.5 Oracle Net / OJVM related
CVE-2026-31790 RDBMS / OpenSSL 7.2 Confidentiality, integrity, availability
CVE-2026-26007 RDBMS / Python 6.5 Network attack vector
CVE-2026-21999 XML Database 5.3 HTTPS / XDB related
CVE-2026-34312 RDBMS Row Access Method 2.4 Privileges required, lower practical exposure

The real risk depends on your environment. A single-instance database is different from RAC. Likewise, OJVM risk matters only if OJVM is installed — but many enterprise systems still have it present even if nobody actively uses it.

Special Attention for EBS Customers

For Oracle E-Business Suite customers, this CPU deserves even more attention because EBS depends on multiple technology layers: database, Fusion Middleware, Oracle HTTP Server, WebLogic, Java, Forms, Reports, and other supporting components.

For Apps DBAs, review not only the EBS CPU documents, but also:

  • Oracle Database RU / OJVM RU
  • Oracle Grid Infrastructure RU, if RAC or GI is used
  • Fusion Middleware patches
  • WebLogic / OHS related fixes
  • JDK/JRE updates
  • ETCC requirements
  • AD/TXK codelevel prerequisites
  • EBS-specific CPU Patch Availability Document

In EBS R12.2 environments, patching should be aligned with ADOP planning, application downtime, fs_clone health, and post-patching validations.

Delayed RUs: What DBAs Should Do Now

Since some RUs were delayed, DBAs should use this time wisely and prepare all surrounding tasks before production patching begins.

Start with version and component checks:

-- Check database version
select banner_full from v$version;

-- Check registry components
select comp_id, comp_name, version, status
from dba_registry
order by comp_id;

-- Check OJVM presence
select comp_id, comp_name, status
from dba_registry
where comp_id = 'JAVAVM';

Check Oracle inventory:

$ORACLE_HOME/OPatch/opatch version
$ORACLE_HOME/OPatch/opatch lsinventory
$ORACLE_HOME/OPatch/opatch lspatches

For Grid Infrastructure:

$GRID_HOME/OPatch/opatch lsinventory
$GRID_HOME/OPatch/opatch lspatches

For EBS database environments, run ETCC:

./checkDBpatch.sh

Recommended Patching Approach

1. Review CPU Advisory and MOS Notes

Confirm whether your platform, database version, and installed component stack are affected.

2. Identify Installed Components

Never assume that OJVM, XDB, Spatial, JVM, or other components are absent. Validate through DBA_REGISTRY.

3. Prepare Patch Inventory

Capture current OPatch version, current patch list, Oracle Home details, Grid Home details, and exact database version.

4. Perform Conflict Checks

$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir <PATCH_DIR>

5. Backup Before Patching

  • RMAN database backup
  • Archive log backup
  • Oracle Home backup
  • Grid Home backup
  • Application tier backup for EBS
  • AMI or snapshot if running on cloud/EC2
  • PDB restore point, if applicable
  • Data Guard status validation, if standby exists

6. Patch Lower Environment First

Always validate in DEV / SIT / UAT / PERF before moving to PROD.

7. Apply Database RU and OJVM RU

opatch apply

sqlplus / as sysdba
startup

$ORACLE_HOME/OPatch/datapatch -verbose

Validate SQL patch history:

select patch_id, patch_type, action, status, action_time, description
from dba_registry_sqlpatch
order by action_time;

8. Run Post-Patch Validation

select comp_id, comp_name, version, status
from dba_registry
order by comp_id;

select owner, object_type, count(*)
from dba_objects
where status='INVALID'
group by owner, object_type
order by owner, object_type;

@?/rdbms/admin/utlrp.sql

For EBS, validate login page, Concurrent Managers, Workflow Mailer, Forms launch, OAF pages, interfaces, custom schemas, DB links, invalid objects, and ADOP readiness.

My DBA View

This CPU should not be ignored because several vulnerabilities are network-related, and some are remotely exploitable without authentication. Even if a component is not exposed externally, internal network exposure still matters.

For Oracle 19c environments — especially EBS R12.2 on 19c — DBAs should treat this CPU as a priority. If you run RAC, review Clusterware-related CVEs carefully. If OJVM is installed, include OJVM RU planning. For EBS, remember that security exposure is not only at the database layer but also in Fusion Middleware and WebLogic components.

Suggested Communication to Management

Oracle has released the April 2026 Critical Patch Update, which includes security fixes across Oracle Database, Fusion Middleware, E-Business Suite dependent components, GoldenGate, and Enterprise Manager. Some database Release Updates are delayed, so our team will first complete impact analysis, patch availability validation, conflict checks, backup planning, and lower-environment testing. Production patching will be scheduled only after successful validation and stakeholder approval.

Final Thoughts

The April 2026 CPU reminds us that Oracle patching is not just a technical task. It is also a security, compliance, and operational responsibility.

Analyze early. Test properly. Communicate clearly. Patch safely. Validate completely.

Sources

  1. Oracle DBA CH: Oracle CPU April 2026 DBA Analysis
  2. Oracle: Oracle Critical Patch Update Advisory – April 2026
  3. Mike Dietrich: April 2026 Release Updates (RUs) 19.31 and 23.26.2 are delayed

No comments: