Oracle Reports Developer EUVD-2026-61626

Exploitation requires a valid low-privileged Oracle Reports Developer 14.1.2.0.0 account and HTTP network access to the application - the CVSS vector (PR:L) explicitly confirms some level of authentication is a prerequisite, ruling out unauthenticated external exploitation. No victim user interaction is required (UI:N). The flaw is specifically in the Security and Authentication component, indicating the bypass occurs at the authorization enforcement layer after login, not at the initial credential check. Exploitation is constrained to actors who have already obtained at least a basic user account on the target instance; fully unauthenticated internet-facing exploitation is not indicated by the available data. Scope is unchanged (S:U), so direct pivot to other Fusion Middleware components is not implied by this flaw alone.

The CVSS 3.1 score of 8.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N) reflects high confidentiality and integrity impact with no availability impact - consistent with Oracle's description of unauthorized data creation, deletion, modification, and disclosure. The 'easily exploitable' characterization in Oracle's own advisory and the low attack complexity (AC:L) suggest minimal technical barrier once credentials are obtained. No EPSS score was provided in the input data, so exploitation probability cannot be quantified against the broader threat landscape. The vulnerability is not listed in CISA KEV, and no public POC has been identified, indicating no confirmed active exploitation at this time. The Availability impact of N (A:N) limits the worst-case outcome to data exposure and manipulation rather than service disruption. The scope remains unchanged (S:U), meaning lateral movement to other Fusion Middleware components is not directly indicated by the CVSS metrics, though data accessed through Reports Developer may itself be sensitive. Overall risk is genuine and elevated for organizations running this version in network-accessible configurations.

An attacker with a valid low-privileged Oracle Reports Developer account - such as a standard business analyst user - sends a crafted HTTP request targeting the Security and Authentication component, bypassing authorization enforcement and elevating their effective data access privileges. The attacker can then read sensitive report data, business intelligence output, or underlying data sources, and can create, delete, or modify critical data accessible to the Reports Developer application. No public POC is known, but Oracle's 'easily exploitable' classification and the low attack complexity suggest the technique requires minimal sophistication once a valid account is obtained.