Oracle Hyperion Financial Management EUVD-2026-61922

The attacker must possess a valid, authenticated low-privileged account on Oracle Hyperion Financial Management 11.2.25.0.000 and must have HTTP network access to the HFM application server. No elevated privileges are required beyond a basic user credential. No special non-default configuration, enabled feature flag, or specific deployment mode is indicated as a prerequisite - exploitation targets the Security component under standard HFM deployment. Limiting factors: requires an authenticated session (PR:L), so fully unauthenticated external attackers cannot exploit this without first obtaining any valid HFM credential; scope is unchanged (S:U), meaning compromise does not pivot to adjacent systems; only confidentiality is impacted, with no write or denial-of-service capability.

The CVSS 3.1 score of 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) reflects a medium-severity but operationally significant confidentiality threat. The network vector, low complexity, and absence of user interaction make this straightforward to execute against an exposed instance - any attacker with a valid low-privilege account can exploit it without additional configuration tricks. However, the PR:L requirement is a meaningful limiting factor: the attacker must already hold an authenticated session, which reduces opportunistic attack surface compared to unauthenticated flaws. Impact is confined to confidentiality (C:H) with zero integrity or availability effect, meaning the flaw enables data theft or reconnaissance, not sabotage. No EPSS score is available in the provided data, and the vulnerability is not listed in CISA KEV, suggesting no confirmed in-the-wild exploitation at time of analysis. Given that HFM houses sensitive financial consolidation data often subject to SOX and similar compliance obligations, the business impact of unauthorized reads is potentially severe even without a high CVSS. The 'Authentication Bypass' tag introduces a mild tension with PR:L - if authentication is bypassed, PR:N would be expected; the most coherent interpretation is that this is an authorization bypass (role escalation within the app) rather than a full authentication bypass, consistent with PR:L.

A low-privileged internal user - such as a read-only financial analyst with a valid HFM account - sends a crafted HTTP request to the HFM Security component endpoint, exploiting the authorization bypass to query financial consolidation data outside their assigned scope. This could include subsidiary financials, pre-release earnings data, or other regulated financial records. No exploit code has been publicly released, but the low attack complexity means a moderately skilled attacker familiar with HFM's API surface could reproduce the bypass without specialized tooling.