Oracle iSupport CVE-2026-46945

Exploitation requires the attacker to already hold a high-privilege account in Oracle iSupport (CVSS PR:H) and to be able to reach the iSupport HTTP endpoints over the network; no user interaction is needed (UI:N) and attack complexity is low (AC:L). The vulnerable surface is specifically the 'Internal Operations' component of iSupport on Oracle E-Business Suite versions 12.2.3 through 12.2.15 - earlier or later major branches and EBS deployments without iSupport licensed/enabled are out of scope. The realistic limiting factor is therefore the availability of a privileged iSupport account and network reachability of the EBS HTTP tier from the attacker's position.

The CVSS vector (AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H) and 9.1 score are driven almost entirely by the scope change and full CIA impact, not by ease of access - PR:H means an attacker must first hold high privileges in iSupport, which materially limits the realistic threat compared to a PR:N RCE. There is no EPSS score, no CISA KEV listing, and no public POC identified at time of analysis, so this is not a 'patch tonight or get popped' issue for most environments; it is, however, a serious priority for organizations exposing EBS to large internal/partner user bases where privileged iSupport accounts are common or where account hygiene is weak. The description's claim of 'easily exploitable' should be read in context - Oracle is asserting that once the privilege prerequisite is met, exploitation is straightforward, which is consistent with AC:L. No CWE was published and no technical detail beyond the advisory exists, so the exact bug class is inferred rather than confirmed.

An insider or a compromised business partner who already holds a high-privilege iSupport responsibility (for example through credential phishing or reuse against an EBS user with internal-operations access) sends crafted HTTP requests to the vulnerable iSupport endpoint and pivots beyond iSupport into adjacent E-Business Suite components thanks to the scope change, taking over iSupport data and influencing connected modules. No public exploit code is identified at time of analysis, so initial exploitation would require attacker-developed tooling derived from the patch diff.