Oracle iReceivables EUVD-2026-47100

Exploitation requires network HTTP access to the Oracle E-Business Suite web tier hosting iReceivables and a valid low-privilege account (CVSS PR:L), so this is authenticated abuse rather than fully unauthenticated access; the affected deployment must run iReceivables on EBS versions 12.2.3 through 12.2.15 with the AR Web Utilities component reachable. Limiting factors: an attacker needs at least a low-privilege EBS/iReceivables credential (though self-service customer accounts in EBS are often broadly granted), and only these specific 12.2.x releases are affected. No user interaction, no high privilege, and no special non-default configuration is called out by Oracle, and attack complexity is low, so any authenticated user reaching the module is a realistic threat.

The signals are moderately strong and internally consistent. CVSS 3.1 8.8 with AV:N/AC:L/PR:L/UI:N indicates remote, low-complexity, no-user-interaction exploitation requiring only low privileges - a realistic and attractive target inside enterprise environments. The unchanged scope (S:U) with full C:H/I:H/A:H means complete compromise confined to iReceivables rather than a jump to the OS or other EBS modules. No EPSS score, SSVC decision, KEV listing, or POC was provided, so probability of exploitation cannot be quantified from this data; the absence of KEV means no confirmed active exploitation. The main caveat is the PR:L requirement - the attacker needs an existing low-privilege EBS/iReceivables account (self-service customer accounts are common in EBS deployments), which lowers the bar considerably versus a fully unauthenticated flaw but is not zero. This is a genuine priority for internet-facing or partner-facing EBS installations, not merely a high-CVSS-but-low-real-risk finding.

An attacker who holds or registers a low-privilege iReceivables self-service account authenticates to the EBS web tier and sends a crafted HTTP request to the AR Web Utilities component. Because the flaw is easily exploitable with low attack complexity and no user interaction, the request results in takeover of the iReceivables module, giving the attacker full read/write access to receivables data and functions. No public proof-of-concept was identified at time of analysis.