Oracle July 2026 CPU: 1,455 security patches

Oracle's July patch cycle lands today with a number that is hard to ignore: the company's detailed bulletin lists 1,455 new security patches across its product portfolio. The scheduled release date is 21 July 2026. At the time of publication, Oracle's master security page still labels the detailed bulletin a pre-release announcement, so teams should re-check the final advisory before approving production changes.

The headline is not a reason to deploy 1,455 changes blindly. It is a reason to find the Oracle systems that are internet-facing, reachable from untrusted networks, or connected to high-value business data — and then match their exact versions against the vendor matrices.

1,455 patches does not mean 1,455 unique CVEs

Oracle describes the total as security patches, not unique vulnerabilities. One vulnerability can affect several products and receive more than one product-specific patch. Oracle also says its quarterly Critical Patch Updates are usually cumulative and can include fixes for Oracle code as well as third-party components bundled inside Oracle products.

That distinction matters for risk reporting. A dashboard that converts the headline directly into “1,455 vulnerabilities” would overstate what Oracle published. The useful units for an operator are affected product, installed version, exposure, exploit prerequisites, business impact, and whether the relevant patch has actually been applied.

Where the unauthenticated remote risk clusters

Several product families combine large patch counts with vulnerabilities Oracle says may be remotely exploitable without authentication:

Oracle Fusion Middleware: 359 new security patches, 224 potentially remotely exploitable without credentials, and a highest listed CVSS 3.1 score of 10.0.
Oracle E-Business Suite: 416 patches, including 63 potentially remotely exploitable without authentication, with a highest score of 9.8.
Oracle Communications: 168 patches, 122 in the unauthenticated-remote category, and a highest score of 9.8.
Oracle PeopleSoft: 84 patches, 45 potentially remote without authentication, and a highest score of 9.9.
Oracle Database Server: 16 patches, seven potentially remote without authentication, and a highest score of 9.9.
Oracle Java SE: 20 patches, 18 potentially remote without authentication, with a highest score of 7.8.
Oracle MySQL: 53 patches, nine potentially remote without authentication, and a highest score of 8.5.

These figures are a triage signal, not a substitute for the risk matrices. A lower-scoring issue on an exposed identity component may deserve action before a higher-scoring flaw on an isolated test system. Likewise, “remote without authentication” does not prove that every vulnerable deployment is reachable from the public internet.

A practical patch order for 21 July

Build the real inventory. Enumerate Oracle Database, Fusion Middleware, E-Business Suite, PeopleSoft, Java, MySQL, GoldenGate, Communications, and industry applications. Include disaster-recovery, test, and forgotten integration hosts.
Match exact versions to the final advisory. Do not infer coverage from a product family name. Record the installed release, patch level, component, support status, and the vendor target version for each asset.
Prioritize exposure and trust. Move public endpoints, authentication services, middleware consoles, partner-facing portals, and systems holding financial, HR, identity, or customer data to the front of the queue.
Test dependencies, then shorten the window. Oracle estates are integration-heavy. Validate representative workflows and rollback procedures, but do not let an open-ended test cycle leave externally reachable systems vulnerable for weeks.
Verify the result. Capture before-and-after versions, rerun authenticated discovery, check failed services and integrations, and monitor access and application logs for abnormal behaviour.

Cloud does not eliminate the verification step

Oracle says its cloud operations and security teams evaluate CPU fixes and apply relevant patches through their change-management processes. That is not the same as every customer's configuration being covered at the same moment. Oracle directs IaaS, PaaS, SaaS, managed-cloud, industry- cloud, and NetSuite customers to the appropriate support channel for status that is not answered by the public advisory.

Record that confirmation as evidence. For hybrid estates, split responsibility explicitly: which layer Oracle operates, which layer your team patches, and which integrations or self-managed hosts sit between them.

Do not leave credentials behind during emergency work

Middleware and enterprise applications often contain service accounts, database passwords, API tokens, certificates, deployment keys, and partner credentials. If exploitation is suspected, patching closes the entry path but does not invalidate trust already stolen. Preserve evidence, contain the affected host, then rotate exposed credentials from a clean system.

The same rule applies to the patch project itself. Avoid pasting privileged credentials into tickets or long-lived chat. Our guide to where secrets leak during normal operations explains why the incident channel can become a second breach surface.