Oracle Hyperion DRM CVE-2026-87140

Exploitation requires a valid, authenticated account on Oracle Hyperion Data Relationship Management 11.2.26.0.000 with low privileges (CVSS PR:L) and network reachability to the DRM application over HTTP (AV:N) - an anonymous or unauthenticated attacker cannot trigger it. The high attack-complexity metric (AC:H) indicates a further limiting factor: the attacker must meet non-trivial conditions such as a specific application state, ordering of requests, or a narrowly-timed interaction inside the Access and Security component, rather than a single deterministic request. No user interaction is required from a victim administrator (UI:N). Exploitation is constrained to the specific supported version named by Oracle, and it is not applicable where the DRM interface is unreachable from untrusted networks or where low-privileged accounts are not issued to untrusted parties.

The supplied CVSS 3.1 vector (AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H) describes a network-reachable flaw that requires an existing low-privileged account and is rated high complexity, which materially narrows who can exploit it - the attacker must already be inside the DRM user base. There is no evidence of active exploitation: the CVE is not in CISA KEV and no public exploit or proof-of-concept is referenced, and no EPSS score was provided, so the exploitation-probability signal is essentially absent rather than reassuring. The practical severity comes from the impact side: a successful attack yields full C/I/A loss and application takeover, which in a financial-consolidation platform means control over master data, hierarchies and downstream reporting, so contained but high-value. There is also a notable metadata conflict worth flagging for triage: the sole tag attached is 'Information Disclosure', which understates an issue Oracle describes as 'takeover' with high integrity and availability impact - treat the tag as unreliable. For an internal enterprise deployment - even a mid-sized municipal IT team in sanok should treat this as urgent if DRM is exposed beyond a trusted network - the sensible posture is patch on the CPU timeline while recognizing that exploitation is neither trivial nor currently observed. Note that no CWE, no EPSS score and no patch-version detail beyond the advisory link were available, so exploitability specifics remain partly inferred from the CVSS vector rather than confirmed by vendor text.

An attacker who already holds a low-privileged DRM account - for example a contractor or a compromised business user with read-only hierarchy access - sends crafted HTTP requests to the Access and Security component to manipulate authorization checks and elevate their own role. Per the AC:H rating, the attacker likely has to satisfy timing or state conditions or repeat attempts before the privilege escalation succeeds. Once elevated, they gain administrative control of Data Relationship Management, enabling modification or exfiltration of master data and hierarchies and potentially pivot into connected EPM systems. No public proof-of-concept is known, so this remains a theoretical-but-patchable path rather than an observed campaign.