Oracle iSetup CVE-2026-70713

Exploitation requires a low-privileged, authenticated Oracle EBS account with network access to the iSetup application over HTTP - meaning unauthenticated external exploitation is not possible per the CVSS PR:L metric. The attacker must also satisfy High attack complexity (AC:H) conditions whose exact nature Oracle has not publicly disclosed; these likely involve a specific EBS application state, parameter sequence, or race condition within the General Ledger Update Transform or Reports component. The flaw is scoped to Oracle iSetup versions 12.2.3-12.2.15 within the EBS 12.2.x stream; deployments on EBS 12.1.x or earlier are not listed as affected. Exploitation is limited by the requirement for a valid EBS credential (even if low-privileged), the AC:H preconditions, and direct HTTP reachability of the EBS web tier. Environments that restrict iSetup access to specific network segments or limit low-privileged accounts' access to GL-adjacent modules reduce realistic exposure meaningfully.

The NVD/Oracle-assigned CVSS 3.1 score of 7.5 (High) is driven entirely by the catastrophic impact triad (C:H/I:H/A:H) and network attack vector (AV:N), partially tempered by High attack complexity (AC:H) and a Low privilege requirement (PR:L). In practice, the AC:H metric is the most consequential risk-reduction factor: exploitation is not straightforward and requires the attacker to navigate unstated preconditions, which substantially narrows the realistic attacker pool relative to a comparable AC:L vulnerability. No EPSS data was provided in the intelligence feed; given the AC:H rating and absence of KEV or POC, exploitation probability is assessed as low-to-moderate in the near term, with risk concentrating around nation-state actors and financially motivated groups targeting Oracle EBS environments. The 'takeover' language in Oracle's advisory - atypical in its directness - suggests Oracle assessed this as achieving privileged code execution or session capture rather than mere data leakage, despite the advisory tags also citing 'Information Disclosure.' This apparent inconsistency (full CIA impact vs. info-disclosure tag) should be treated as an analytical gap: the true impact class is not independently verifiable without a working exploit or detailed vendor disclosure. No KEV listing and no POC have been identified, so this is not confirmed actively exploited at time of analysis.

An attacker holding a low-privileged Oracle EBS account - such as a read-only finance user or a compromised service account - sends specially crafted HTTP requests to the General Ledger Update Transform or Reports endpoint. The attacker must satisfy the unstated AC:H preconditions (likely a specific EBS session state, parameter combination, or timing window) to trigger the underlying flaw. If successful, the attacker achieves full control over the iSetup instance, potentially accessing sensitive financial configuration data, altering General Ledger transform mappings, or disrupting EBS environment migrations.