Oracle already handed you the priority order

Oracle's September 2026 Critical Patch Update landed September 15 with 673 patches addressing 672 CVEs, and once you count the bundled component fixes that ride along with those patches, more than 800 vulnerabilities got closed in this one release. If you administer any Oracle product and you're staring at that list wondering where Monday starts, skip the spreadsheet sorting. Oracle already told you: work E-Business Suite, Fusion Middleware, and Hyperion first, and specifically the instances of those three that the open internet can reach.

Oracle isn't hedging by naming three products out of a list this long. Siebel CRM, Oracle Analytics, and Oracle Communications all received patches in this release too, and that work still needs to happen. But Oracle drew a line ahead of those three families specifically, and an admin with limited hours this week should draw the same line before touching anything else.

The reason that line makes sense has nothing to do with how many patches each product got. It comes down to a number that doesn't show up in a simple patch count at all: how many of these flaws an attacker can reach without ever logging in.

Why patch count is the wrong number to sort by

Line up the three priority families by raw patch count and E-Business Suite looks like the biggest job on the list, 159 patches against Fusion Middleware's 153 and Hyperion's 102. Sort instead by how many of those patches close a hole reachable without authentication, and the order flips. Fusion Middleware carries 78 patches for flaws exploitable remotely with no login required, more than half of everything shipped for that product this cycle. E-Business Suite, despite the longer patch list, carries only 19 in that same unauthenticated-remote category.

Hyperion sits closest to Fusion Middleware on this measure. Of its 102 patches, roughly half fix something an attacker can hit from outside without credentials, a proportion in the same range as Fusion Middleware's even though Hyperion's total patch count is the smallest of the three. Across the full September release, more than 240 vulnerabilities fall into that unauthenticated-remote bucket. Oracle hasn't published CVSS scores for any of them this cycle, so severity scoring isn't a tool available for this triage. Exposure and reachability are what you have to work with instead.

None of this means the rest of the 673 patches don't need to land somewhere on a calendar, because they do. It means a system carrying 78 unauthenticated-remote holes on a public IP address is not the same emergency this week as one carrying 19, even when the second system's overall patch list runs longer.

E-Business Suite is more internet-facing than most teams assume

Ask a security lead whether their E-Business Suite environment is internet-facing and plenty will say no on reflex, because EBS reads as an internal ERP system, the place finance and procurement live, not something a stranger could reach. Check the actual firewall rules and the answer gets less comfortable. Supplier portals, self-service recruitment pages, customer-facing order status screens, and vendor payment tools built on EBS get published outward on purpose, usually set up by a project team years ago that solved a real business problem and moved to the next project without leaving a map behind.

That's the gap this patch cycle exposes. The 19 unauthenticated-remote fixes in EBS are a small slice of its 159 total, but they sit exactly where those outward-facing modules run, and a lot of organizations can't say today, with confidence, which EBS instances are actually reachable from outside versus which ones only look that way in an old network diagram. Any EBS footprint with a self-service or vendor-facing module patches first, regardless of what else is on this week's calendar. And if nobody can name who currently owns that instance, that's less a patching question and more a case for asking whether it belongs on a retirement list instead of a permanent patch schedule.

Fusion Middleware hides its exposure in the integration layer

Fusion Middleware doesn't run a screen most employees would recognize, and that's exactly why its internet exposure is easy to lose track of. WebLogic Server and SOA Suite underpin a lot of the API endpoints and partner-facing integration points that connect an Oracle estate to the outside world, and those get stood up by integration teams solving one specific handoff problem, not by anyone thinking of it as a security perimeter at the time.

With 78 of 153 Fusion Middleware patches closing holes reachable without a login, that integration layer is where this week's real risk sits. Most organizations never finished the integration map that would show what's actually exposed, so the honest first move isn't patching. It's finding every WebLogic and SOA Suite instance that talks to anything outside the firewall and confirming which ones carry this week's fixes before anyone assumes the job is done.

Hyperion's exposure hides behind a wrong assumption

Hyperion has the fewest patches of the three priority families, 102 against EBS's 159 and Fusion Middleware's 153, which makes it the one most likely to slide to the bottom of an admin's list this week for that reason alone. It shouldn't. Roughly half of Hyperion's patches fix something reachable without authentication, putting its exposure rate in the same range as Fusion Middleware's and well above E-Business Suite's.

The reason Hyperion gets underrated has nothing to do with the numbers. It comes down to an assumption sitting underneath them. Hyperion is a planning and consolidation tool built for finance teams running budget cycles and close processes, and most admins picture it as something that lives entirely inside the network. Then a finance team asks for remote access during close week, someone stands up an SSO gateway or a reverse proxy so people can reach it from home, and an instance nobody thought of as internet-facing quietly becomes exactly that. Check that assumption this week before trusting it.

What this week actually looks like

Start with an inventory, not a patch. Pull a current list of every EBS, Fusion Middleware, and Hyperion instance in the environment, and get the answer on internet reachability from whoever owns the firewall and load balancer rules, not from the application team, since the application team's mental model of what's exposed is exactly what created this gap in the first place. A current, trustworthy asset inventory the rest of this work depends on is the actual first task, before a single patch goes in.

Once that list exists, patch in the order the numbers support: internet-facing Fusion Middleware and Hyperion instances first, since both carry unauthenticated-remote proportions near fifty percent, then internet-facing EBS, then the internal-only instances of all three, and only after that Siebel, Oracle Analytics, and Oracle Communications. Where a patch can't go into a production system right away, put compensating network controls in place and keep the team ready to move. The same discipline that matters in the first thirty minutes of any platform incident is just as useful during a patch window as during a breach.

And if this inventory turns up an EBS or Hyperion instance so old and so customized that patching it took real archaeology, take that as a signal on its own. A heavily customized on-prem Oracle system doesn't get cheaper to secure with age, and deciding whether to keep patching one indefinitely or treat the customization itself as a budget line is a conversation this patch cycle just gave you a good reason to have. The 673 number was never the real story. The instances your organization forgot were reachable from outside are.