Oracle Capacity EUVD-2026-105803

Exploitation requires a valid low-privileged Oracle E-Business Suite account (PR:L) with network HTTP access to the Oracle Capacity product's Internal Operations component; affected deployments are EBS versions 12.2.3 through 12.2.15. No user interaction is needed (UI:N) and attack complexity is low (AC:L), so a reliable crafted HTTP request suffices once authenticated. The key limiting factor is the authentication requirement - this is NOT remotely exploitable by an anonymous attacker despite the mislabeled 'Authentication Bypass' tag - which confines the realistic threat to insiders or attackers who have already obtained EBS application credentials.

This is a credible mid-tier priority rather than a drop-everything emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L, base 7.6) describes an easily exploitable, network-reachable flaw requiring only low-privilege authentication and no user interaction, with high confidentiality impact but only low integrity and availability impact. No EPSS score, no CISA KEV listing, and no public POC were provided, so there is no evidence of active or imminent mass exploitation - exploitation status is therefore 'no public exploit identified at time of analysis.' The dominant risk is data exposure: a low-privileged EBS user could read all data accessible to Oracle Capacity. A notable conflict exists in the metadata: the input carries an 'Authentication Bypass' tag, yet the CVSS vector specifies PR:L (authentication required), and the description explicitly says 'low privileged attacker' - these contradict each other, and the tag appears mislabeled; this vulnerability is NOT an unauthenticated bypass. Treat the real precondition as valid low-privileged EBS access, which materially narrows the attacker population compared to a pre-auth flaw.

An attacker who already holds a low-privilege Oracle E-Business Suite application account sends a crafted HTTP request to the Oracle Capacity (Internal Operations) component over the network, with no user interaction required. Because exploitation is rated low-complexity, they can reliably read critical Capacity data outside their authorization and make limited unauthorized writes or trigger a partial denial of service. No public exploit code is known at the time of analysis, so this would currently require attacker-developed tooling.