Oracle iReceivables EUVD-2026-47070

The attacker needs network reachability to the Oracle iReceivables self-service application over HTTP and a low-privilege authenticated session (CVSS PR:L) - i.e., a valid low-tier iReceivables/EBS account, not anonymous access. The vulnerable code path is the AR Web Utilities component of iReceivables on EBS 12.2.3-12.2.15, so exploitation is limited to deployments running those versions with the iReceivables module enabled and its self-service pages exposed. Limiting factors: it is NOT pre-authentication (some credential is required), and only iReceivables-accessible data is in scope (scope unchanged, S:U); there is no availability impact, so it cannot be used for denial of service. Note the 'Authentication Bypass' tag suggests a possible weaker-than-PR:L auth requirement - confirm with Oracle whether any account grants sufficient reach.

All signals point to a genuine, actionable High-severity issue rather than an inflated CVSS score. The CVSS vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N) describes remote exploitation over HTTP with low complexity, no user interaction, and only low privileges required - meaning any user who can authenticate to the self-service portal (a broad population for a customer-facing AR module) could reach it. No EPSS score, KEV entry, or public POC was supplied, so exploitation probability cannot be quantified from the data; the correct reading is 'no public exploit identified at time of analysis,' NOT low risk. The main mitigating factor is PR:L: this is not fully unauthenticated (PR:N), so an attacker needs some valid low-privilege credential or account, which slightly narrows the population versus a pre-auth flaw. The 'Authentication Bypass' tag is community-supplied and appears to conflict mildly with the CVSS PR:L (which asserts privileges ARE required) - verify with Oracle whether a true pre-authentication path exists, as that would raise real-world risk. Given Oracle EBS is a high-value ERP target and prior EBS CVEs have drawn active exploitation, this warrants prompt patching despite the absence of confirmed exploitation.

An attacker obtains or registers a low-privilege iReceivables self-service account, then sends crafted HTTP requests to the AR Web Utilities component that bypass or subvert authorization checks, allowing them to read and tamper with receivables data belonging to other customers or accounts. No user interaction or elevated privileges are needed, and low attack complexity means the request sequence is reliable once discovered; no public POC has been identified at time of analysis.