Oracle Demand Planning EUVD-2026-61797

Exploitation requires network HTTP access to the Oracle Demand Planning Internal Operations component and a low-privileged authenticated account (CVSS PR:L), with no user interaction (UI:N) and low complexity (AC:L); it applies to Demand Planning 12.1 and 12.2. Limiting factors: the attacker must first obtain some valid low-privilege access rather than acting fully unauthenticated, and reachability depends on the EBS HTTP interface being exposed to the attacker's network position. Note the unresolved discrepancy: the vendor intelligence tag 'Authentication Bypass' suggests the privilege prerequisite could be weaker than PR:L implies - confirm with Oracle before assuming an account is strictly required.

The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N) describes a network-reachable, low-complexity attack needing only low privileges and no user interaction, yielding high confidentiality and integrity impact with a cross-product scope change - a genuinely severe combination that justifies the 9.6 rating. No EPSS score, KEV listing, or POC was provided, so exploitation probability cannot be quantified and there is no public exploit identified at time of analysis; the risk here is driven by ease of exploitation and blast radius rather than by evidence of active use. Because Oracle EBS instances frequently expose HTTP interfaces to internal (and sometimes external) users and any low-privileged account suffices, defenders should treat this as an urgent patch even absent in-the-wild reports - a mid-sized operator running EBS 12.1/12.2 should apply the August 2026 CPU promptly. Note one signal conflict to verify with the vendor: the intelligence tag says 'Authentication Bypass' (implying no auth), while the CVSS vector specifies PR:L (implying an authenticated low-privilege user) - resolve which is correct before scoping exposure.

An attacker holding any low-privileged Oracle Demand Planning account (or a foothold on the internal network with such access) sends crafted HTTP requests to the Internal Operations component and, without any user interaction, gains read and write access to all data the module can reach. Owing to the changed scope, the attacker leverages that access to affect additional connected Oracle products. No public exploit code is identified at time of analysis, but the low attack complexity means a working exploit would be straightforward to develop.