Oracle Product Workbench CVE-2026-61333

Exploitation requires the attacker to hold a valid low-privileged Oracle E-Business Suite account (CVSS PR:L - authenticated) with HTTP network access to the Product Workbench application in the Internal Operations component; the affected deployment must run EBS 12.2.3 through 12.2.15. No user interaction is needed (UI:N) and attack complexity is low (AC:L). Limiting factors that reduce real-world risk: the attacker cannot be fully anonymous - some authenticated account is mandatory - and only installations exposing the vulnerable Product Workbench module in the affected 12.2.x range are impacted; availability is not affected (A:N), so the attack is about data theft and tampering, not disruption.

The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N, score 8.1) indicates an easily exploitable network-facing flaw requiring only low privileges and no user interaction, with high confidentiality and integrity impact but no availability impact - consistent with a data-access/authorization bypass rather than a service-crashing bug. No EPSS score, KEV listing, POC, or SSVC decision data was provided, so exploitation probability cannot be quantified from the input; the assessment rests on the CVSS vector and Oracle's advisory alone. The PR:L requirement means an attacker needs some valid (even minimal) EBS account, which limits purely anonymous internet exploitation but is realistic for insider or credential-compromise scenarios. This is a genuine high-severity priority for organizations running EBS 12.2.x with Product Workbench exposed, but the 'low privileged' precondition and absence of any exploitation-in-the-wild signal place it below a wormable unauthenticated RCE in urgency.

An attacker who holds any low-privileged Oracle E-Business Suite account (obtained legitimately, via phishing, or through credential reuse) sends crafted HTTP requests to the Product Workbench / Internal Operations functions and, exploiting the authorization weakness, reads or tampers with critical business data they should not be able to reach. No user interaction or elevated privileges are required, and the attack can be repeated to exfiltrate or corrupt all data accessible to the module. No public exploit identified at time of analysis, so an attacker would need to develop the request sequence independently.