Oracle iStore CVE-2026-60813

Exploitation requires the attacker to hold a high-privileged account on the target Oracle iStore instance (CVSS PR:H) and to reach the iStore Shopping Cart component over HTTP (AV:N); no end-user interaction is required (UI:N) and attack complexity is low (AC:L). The decisive limiting factor is the PR:H prerequisite - this is not exploitable by anonymous or low-privileged remote users, so realistic risk is confined to insiders or attackers who have already escalated to privileged EBS accounts. Affected deployments are limited to Oracle E-Business Suite releases 12.2.3 through 12.2.15 running the iStore module; environments not running iStore are not exposed.

The CVSS 3.1 vector (AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H, 7.2 High) describes a network-reachable, low-complexity attack that nonetheless requires high privileges (PR:H) - meaning the attacker must already hold an elevated account on the iStore/EBS instance, which substantially narrows the realistic threat population to malicious insiders or attackers who have already obtained privileged credentials. No EPSS score, SSVC decision, KEV listing, or POC was provided in the intelligence, so exploitation probability signals are absent; the absence of KEV and POC data means there is no public exploit identified at time of analysis and no evidence of active exploitation. The primary tension in the data is between the description's 'takeover' language plus C:H/I:H/A:H impacts and Oracle's lone 'Information Disclosure' tag - the CVSS vector should be trusted over the tag. Net priority is moderate: high impact but gated behind PR:H, so it ranks below unauthenticated EBS flaws but warrants prompt patching in environments where privileged iStore accounts are broadly held or externally reachable.

An attacker who has already obtained a high-privileged Oracle iStore/EBS account - for example a malicious insider or an actor reusing stolen privileged credentials - sends crafted HTTP requests to the Shopping Cart component and leverages the flaw to take over iStore, gaining full read/write control and the ability to disrupt the storefront. Because attack complexity is low (AC:L) and no user interaction is needed (UI:N), the attack is reliable once the privileged access precondition is met, though no public exploit code has been identified at time of analysis.