Hyperion Financial Management EUVD-2026-79873

Exploitation requires the attacker to have access to the physical communication segment attached to the hardware running Oracle Hyperion Financial Management 11.2.26.0.000 - that is, layer-2 adjacency such as the same VLAN, subnet, broadcast domain, or directly attached link, as expressed by the AV:A metric. No authentication (PR:N) and no user interaction (UI:N) are required, and the attack is low complexity (AC:L), so any host or device sharing that segment can attempt it. Limiting factors are significant: the flaw is not exploitable across routed or internet-facing paths, so a properly segmented EPM deployment behind firewalls is not exposed; the affected version is reported as the supported 11.2.26.0.000 build specifically; and confidentiality is unaffected (C:N), meaning the impact is data tampering and service crashes rather than mass data exfiltration. The flaw resides in the Security component, so it is not gated behind a non-default optional feature, but the exact triggering endpoint or protocol is not documented in the available data and should be confirmed with Oracle.

Oracle's own CVSS 3.1 vector (AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H) yields 8.1, which is high but deliberately gated by the adjacent-network attack vector: this is not internet-reachable and not something a remote attacker can trigger from an arbitrary host. Low complexity, no privileges and no user interaction mean that once an adversary is on the same physical or logical segment, exploitation is straightforward and largely automatable, so the realistic threat model is a compromised internal workstation, a rogue device on an unsegmented VLAN, or a malicious insider rather than an external actor - which is why even a mid-sized municipal IT team in leszno should treat this as urgent for any flat network hosting the EPM stack. There is no evidence of active exploitation: the CVE is not in CISA KEV and no public exploit code was identified at time of analysis, and EPSS data was not supplied, so this should be prioritized on exposure (is the HFM segment reachable by untrusted internal hosts?) rather than on urgency of observed attacks. Note explicitly that CWE is missing, patch-level detail is limited to the Oracle Critical Security Patch Update reference, and the integrity/availability split means the highest business impact is data corruption rather than disclosure.

An attacker who has established a foothold on any host sharing a network segment with the HFM server - for example a compromised workstation in the same VLAN - sends crafted requests to the exposed HFM Security component without any credentials, exploiting the low-complexity, no-interaction flaw. Successful requests allow alteration or deletion of financial consolidation and metadata records while confidentiality remains untouched, so the tampering can go unnoticed as a breach. The same access can be replayed to hang or repeatedly crash the HFM service, producing a sustained denial of service against financial close and reporting cycles. No public exploit code has been identified, so this scenario currently assumes attacker-developed tooling rather than a ready-made exploit.