Oracle Product Workbench EUVD-2026-47491

Exploitation requires a valid low-privilege Oracle E-Business Suite application account (CVSS PR:L) with HTTP network access to the Oracle Product Workbench / Internal Operations endpoints on an EBS 12.2.3-12.2.15 instance; no user interaction and no high privileges are needed. Limiting factors: the attacker must be authenticated (this is not a pre-auth remote compromise despite the 'Authentication Bypass' tag, which conflicts with PR:L and should be verified with Oracle), the affected version must be in the 12.2.3-12.2.15 range, and the Product Workbench module must be deployed and network-reachable to the attacker. Availability is not affected, so the condition set only enables data disclosure and tampering, not service disruption.

The signals are moderately strong but not top-tier. CVSS 3.1 is 8.1 (High) driven by AV:N/AC:L/PR:L/UI:N with C:H and I:H; the network vector, low complexity, and no-user-interaction requirement make this attractive, but PR:L means an attacker needs an existing authenticated EBS account, which meaningfully narrows the population of viable attackers to insiders or those who have already obtained credentials. No EPSS score, KEV entry, POC, or SSVC decision data was provided, so exploitation probability cannot be quantified from the input - treat exploitation likelihood as unknown rather than high. Availability is explicitly unaffected (A:N), so this is a data-confidentiality/integrity risk, not a denial-of-service risk. The 'Authentication Bypass' tag appears to conflict with the CVSS PR:L (which asserts privileges ARE required); this should be verified against Oracle's advisory, as it may indicate horizontal/vertical privilege escalation rather than full pre-authentication bypass. Net: a real priority for organizations running EBS with untrusted or numerous low-privilege users, but the PR:L gate makes it less severe than an unauthenticated RCE.

An attacker who holds or phishes a low-privilege Oracle EBS account authenticates to the Product Workbench web interface over HTTP and, exploiting the missing authorization check, issues crafted requests to read, alter, or delete product/master data they should not be able to touch. No user interaction or elevated privilege is needed once authenticated (AV:N/AC:L/PR:L/UI:N), so a single compromised or malicious insider account is sufficient; no public exploit code is known at time of analysis.