Oracle Hyperion Financial Management CVE-2026-87181

Requires a valid, low-privileged authenticated HFM account (CVSS PR:L) - this is an authorization/privilege-escalation flaw in the Security component, not an unauthenticated one, so anonymous internet attackers cannot exploit it directly. The attacker additionally needs network reachability over HTTP to the Oracle Hyperion Financial Management web tier (AV:N/UI:N), and the target must be running the affected supported version 11.2.26.0.000. Limiting factors: the credential requirement is the primary barrier and can be mitigated by tightening account provisioning and enabling MFA through Shared Services; users who are not provisioned in HFM at all cannot trigger the flaw; and no user interaction from a victim administrator is required, so there is no 'phishing the admin' precondition. Deployments where HFM HTTP endpoints are segmented behind a VPN and behind strict egress/ingress filtering materially reduce the attack surface, though they do not remove the vulnerability for insiders or compromised user accounts.

The CVSS 3.1 vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H yields 8.8 - network reachable, low complexity, no user interaction, but requiring a low-privileged authenticated account rather than being unauthenticated. That PR:L requirement is the single most important risk limiter: an attacker must first obtain a valid, low-privilege HFM account, which in most deployments means a provisioned finance or reporting user or a compromised credential, not an anonymous internet actor. Notably, the SSVC-style technical impact is total (a complete takeover of the application per the vendor's own wording) even though scope is unchanged (S:U), meaning the blast radius is the HFM application and its data rather than the underlying host or other Oracle components. There is no EPSS score, no KEV listing, and no public exploit identified in the supplied data, so there is no evidence of active exploitation; however, the absence of EPSS/KEV does not lower the underlying severity, and Oracle advisories of this type are routinely reverse-engineered into PoCs after patch release. Data gaps: CWE is missing, exploit maturity is unknown, and no EPSS probability was provided - treat the risk as high-severity but credential-gated, and prioritize based on whether HFM is internet-exposed or accessible to a large user population. Oracle's own CPU advisories are a frequent ransomware-adjacent target set, so prompt patching within the quarterly cycle is warranted. One input inconsistency should be flagged: the supplied tag set includes 'Information Disclosure', which conflicts with the C:H/I:H/A:H takeover impact described by the vendor; the tag appears to be an automated mislabel and the CVSS description should be treated as authoritative.

An attacker who already holds a legitimate low-privileged HFM account (for example a reporting or read-only consolidation user, or one obtained through credential phishing or a shared service account) sends crafted HTTP requests to the HFM web tier that abuse the vulnerable Security component to bypass authorization checks. Because the exploit requires no user interaction and no special conditions, the attacker can then invoke functionality or assume roles normally reserved for administrators, ultimately taking over the application and manipulating or exfiltrating the consolidated financial data it holds. No public exploit code was identified at the time of analysis, so a working attack would currently require bespoke reverse engineering of the Security component by someone with access to the patched/unpatched binaries.