Oracle August 2026: 17 Critical CVEs in Hyperion and Reports Developer

Oracle's August 18, 2026 batch contains 17 vulnerabilities rated CRITICAL (CVSS 9.8 to 10.0), concentrated in two products: Oracle Hyperion and Oracle Reports Developer (Fusion Middleware). Almost all of them allow complete product takeover without authentication.

The number that should hold your attention isn't the volume but its concentration: eleven of these CVEs target the same component, Oracle Reports Developer's "Security and Authentication". Eleven critical flaws in the module responsible for authentication isn't a run of bugs — it's a component to treat as structurally unsound until patched.

Overview

Oracle describes every one of these as "easily exploitable". On sixteen of the seventeen, the attacker needs no account at all.

CVE-2026-70880 — Hyperion DRM, the only 10.0

Oracle's wording is explicit on the two points that push the score to maximum:

Easily exploitable vulnerability allows unauthenticated attacker with network access via TCP to compromise Oracle Hyperion Data Relationship Management. While the vulnerability is in Oracle Hyperion Data Relationship Management, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in takeover of Oracle Hyperion Data Relationship Management.

The S:C (scope change) is why this is a 10.0: the compromise doesn't stop at the vulnerable product. And Hyperion DRM is the master data repository of the Hyperion stack — it defines the account, cost-centre and entity hierarchies that feed financial consolidation. An attacker controlling it doesn't just steal data: they can alter the reference data underpinning the financial statements consumed downstream.

That's the kind of impact that stops being an IT matter and becomes an internal-control and audit matter.

Hyperion Infrastructure Technology — 5 CVEs, takeover over HTTP

Five vulnerabilities at 9.8, all on version 11.2.25.0.000, all exploitable without authentication over HTTP, all resulting in product takeover:

Shared vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.

Four of the five hit "Installation and Configuration". That component is rarely exposed on purpose, but it effectively is in many deployments: Hyperion configuration consoles frequently stay reachable from the internal network long after initial rollout, because nobody documented that they should be locked down.

Hyperion Infrastructure Technology is the shared foundation of the suite (Planning, Financial Management, Essbase). Compromising it exposes every application sitting on top.

Oracle Reports Developer — 11 CVEs in the authentication module

This is the core of the batch. Eleven CVEs, all in the "Security and Authentication" component.

Branch 12.2.1.19.0 — 9 CVEs

Branch 14.1.2.0.0 — 2 CVEs

What that protocol spread actually means

This is the article's most important point for a defender, and it's easy to miss.

The protocols Oracle lists — HTTP, TCP, IIOP, UDP, CORBA — show that Reports Developer's attack surface is not limited to the web port. IIOP and CORBA are distributed-object invocation protocols inherited from the J2EE era, exposed by the underlying WebLogic listeners. UDP is even more unexpected on an application server.

The practical consequence: filtering the HTTP port is not enough. An organisation that put a WAF in front of its Reports Server and believes itself covered remains exposed on at least four other vectors. Filtering has to happen at the network layer, across every port the WebLogic domain exposes, not at the application layer.

CVE-2026-62608 is the only one requiring privileges — but "low privileged" in Oracle's terms means any application account, which in an organisation with hundreds of Reports users is not a barrier.

Affected Products and Versions

⚠️ Oracle does not publish a "fixed version" in the CVE text — the fix ships as a cumulative patch, retrieved from My Oracle Support based on your exact version and platform. So I can't give you a target version number here, and I won't invent one.

Identify your version:

-- On the Hyperion / Fusion Middleware repository database
SELECT * FROM SCHEMA_VERSION_REGISTRY;

# Reports Developer / WebLogic
$ORACLE_HOME/OPatch/opatch lsinventory

Exploitation and Impact

Real exposure surface

These products are rarely directly internet-facing — they're financial back-office and reporting applications. But three factors widen the attacker population considerably:

1. The internal network is enough. None of these CVEs requires public exposure. An attacker already inside via phishing is positioned to exploit.
2. Contractors. Hyperion and Reports deployments almost always involve external integrators with persistent access.
3. Version longevity. Hyperion and Reports Developer get installed and then left alone for years. An affected version is very likely to still be there eighteen months from now.

Consequences

• Financial data exfiltration: consolidation, budgets, forecasts, subsidiary figures ahead of publication
• Reference data tampering (Hyperion DRM): altering an account hierarchy corrupts everything downstream, in a way that's hard to detect
• Insider trading: pre-publication consolidation data has direct market value
• Pivot: these servers sit on well-connected internal segments, with high-privilege service accounts into databases
• Compliance: financial data tampering and statement integrity fall under SOX for US-listed companies, and under statutory audit responsibility elsewhere

Detection and IOCs

WebLogic logs

Reports Developer runs on WebLogic. The useful traces are in the domain:

tail -f $DOMAIN_HOME/servers/<server>/logs/<server>.log
tail -f $DOMAIN_HOME/servers/<server>/logs/access.log

Signals to hunt:

• Requests to Reports endpoints from IPs outside the usual user perimeter
• Authentication failures followed by a success from the same source
• Connections on IIOP and T3 ports from workstations that have no reason to invoke remote objects
• Abnormal volume of UDP traffic to the server

Inventory of exposed ports

The highest-value check, and the one nobody performs:

# From a standard user workstation, not from the admin network
nmap -Pn -sT -p 7001-7100,9000-9100 <reports-server-ip>

Any WebLogic-stack port reachable from the user VLAN is a problem independent of these CVEs.

Hyperion logs

# Hyperion application logs
$EPM_ORACLE_INSTANCE/diagnostics/logs/

Look for Data Relationship Management access outside the usual processing windows — DRM is used in cycles (close periods, hierarchy revisions), not continuously. An isolated access on a Sunday evening deserves a question.

DRM hierarchy integrity

For CVE-2026-70880 specifically, the attacker's goal may be modification rather than reading. Compare active hierarchies against your last validated version: DRM retains version history, and any divergence not tied to a documented change request is a strong indicator.

Mitigation

1. Apply the Oracle patches

Retrieve the relevant cumulative patch from My Oracle Support for each of the three products. Given the number of unauthenticated takeover CVEs, this warrants an accelerated window rather than the usual quarterly cycle.

2. Restrict network access — the most effective short-term measure

Applicable before patching, with no service interruption, and it covers all five protocol vectors at once:

• Hyperion and Reports Developer on a dedicated application VLAN
• Access limited to the subnets of users who genuinely need it (controlling, consolidation, reporting) — not the whole corporate network
• Close IIOP, T3 and UDP ports to user workstations: those protocols serve inter-component communication, not end clients
• No internet exposure, neither direct nor via a reverse proxy without strong authentication

3. Reduce service account privileges

Hyperion and Reports service accounts into databases are frequently over-privileged because that's what the installation guide suggested. A DBA-level account on a consolidation database turns an application takeover into total data compromise.

4. If you conclude there was a compromise

1. Isolate the server from the network before investigating
2. Rotate credentials: WebLogic accounts, database service accounts, Hyperion application accounts
3. Audit DRM hierarchies against a validated reference version
4. Inform internal control and audit: if financial data may have been altered, this is no longer only a technical incident
5. Preserve logs before rotation — WebLogic logs roll fast and an administrator-level attacker can truncate them

Why Continuous Monitoring of Your Oracle Stack Matters

Oracle ships fixes in quarterly batches of several hundred CVEs, in deliberately terse language, on an authenticated portal. The result: correlating "what the batch fixes" with "what I actually run" is manual work nobody really does. Oracle CVEs sit unpatched for six to eighteen months in an average organisation — and on Hyperion or Reports Developer, install-and-forget products, the lag is usually longer.

With cveo.tech, inventory your Oracle components — Hyperion, Fusion Middleware, WebLogic, Database, E-Business Suite — with their exact versions, and get automatic alerts whenever a critical CVE hits one of them. So the quarterly Oracle batch becomes a targeted action list instead of a three-hundred-page PDF.