Oracle Trade Management EUVD-2026-106070

Exploitation requires an authenticated low-privileged account on Oracle Trade Management (PR:L) with access to the Claim LOV component, and crucially requires interaction from a separate victim user (UI:R) who must view the attacker-supplied content for the payload to trigger - the attacker cannot complete the attack unassisted. These limiting factors (valid credentials plus a second user's action) substantially reduce real-world exploitability compared to an unauthenticated flaw, though the network HTTP vector (AV:N) and low complexity (AC:L) mean no special non-default configuration is otherwise needed on affected versions 12.2.3 through 12.2.15.

This is a moderate-severity (CVSS 3.1 base 5.4), not high-priority, issue. The vector (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N) describes a network-reachable but authenticated (PR:L) flaw that cannot be triggered by the attacker alone - it requires interaction from a different, higher-privileged user (UI:R), which is the classic fingerprint of a stored/reflected cross-site scripting issue in Oracle E-Business Suite rather than a direct server compromise. The scope change (S:C) plus low confidentiality and integrity impact with no availability impact (C:L/I:L/A:N) reflects session/browser-context impact on the victim rather than full data compromise. No EPSS score, CISA KEV listing, or public POC is present in the supplied data, so exploitation status is: no public exploit identified at time of analysis. Signals are internally consistent and point to a real but conditional, lower-urgency vulnerability: patch in the normal Oracle CPU cycle rather than emergency. NOTE: the input 'Authentication Bypass' tag conflicts with the CVSS vector, which requires privileges (PR:L) and therefore cannot represent an authentication bypass - treat that tag as suspect.

An authenticated low-privileged user injects a malicious payload into a Claim LOV (list-of-values) field in Oracle Trade Management. When a different, typically higher-privileged user later views that data in their browser, the payload executes in their authenticated session, allowing limited unauthorized read of some data and unauthorized insert/update/delete of some accessible data. No public exploit code is identified at time of analysis, and success depends on luring or waiting for a victim to view the crafted content.