Oracle Report Manager EUVD-2026-79451

Exploitation requires a valid authenticated Oracle E-Business Suite account possessing a low-privileged role that can reach the Oracle Report Manager application - i.e. the 'Internal Operations' component must be accessible from that user's responsibility set. Network access to the EBS HTTP/HTTPS listener hosting Report Manager is required (the vendor states HTTPS access), so an instance that is not reachable from the attacker's network is not exposed. No user interaction is needed (UI:N) and no special configuration switch is named in the description, but the PR:L metric caps the attacker population: unauthenticated outsiders cannot trigger this without first obtaining credentials or an existing low-privileged session. Things that LIMIT real exploitation: the requirement for a provisioned EBS account, deployments where Report Manager is only bound to an internal management network, and the absence (at time of analysis) of published exploit code or KEV-confirmed active exploitation.

The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:L) describes a remotely reachable, low-complexity, no-user-interaction issue, but it explicitly requires low privileges (PR:L) - meaning the attacker must already hold a valid, low-privileged EBS account. No EPSS score, no KEV entry, and no POC was supplied in the input, so the exploitation signal set is weak: 'no public exploit identified at time of analysis'. The presence of an 'Authentication Bypass' tag conflicts with the PR:L metric, which describes post-authentication privilege abuse, not pre-authentication bypass - this tag should be treated as a taxonomy label rather than evidence of unauthenticated access, and the discrepancy is unresolved from the supplied data. Real-world priority depends heavily on exposure: EBS Report Manager instances reachable from untrusted networks (or from large internal user populations) carry meaningful risk because low-privileged account provisioning is routine in ERP environments, whereas EBS stacks confined to a hardened management VLAN and restricted to a small trusted user set are far lower risk than the 7.1 score implies. Do not treat the missing KEV/POC data as proof of safety - it is simply absence of evidence.

An attacker with a legitimate low-privileged EBS account (for example a self-service or limited reporting user) authenticates normally over HTTPS and then sends crafted requests to the Report Manager endpoint that bypass or misapply the internal-operations authorization check, returning report data that the account should not be able to see. Repeating the requests against the affected endpoint also produces a partial denial of service, degrading Report Manager for legitimate users. No public exploit code has been identified, so a real-world attacker would need to discover the request pattern themselves, but the low complexity and lack of user interaction make that discovery realistic for a motivated insider or an attacker who has already obtained a foothold account.