Oracle E-Business Suite EUVD-2026-47092

Exploitation requires the attacker to hold a valid low-privileged Oracle E-Business Suite account (CVSS PR:L) with HTTP network access to the EBS application tier hosting Financials Common Modules; the affected instance must run a vulnerable release in the 12.2.3-12.2.15 range with the Common Components subcomponent in use. No user interaction is needed (UI:N) and attack complexity is low (AC:L). Limiting factors: valid authentication is required per the CVSS vector, so it is not a pre-auth attack as the raw CVSS reads - however the vendor 'Authentication Bypass' tag conflicts with PR:L and should be confirmed; realistic exposure is highest where the EBS tier is internet-facing or where low-privilege accounts are broadly provisioned.

The CVSS 3.1 base score is 7.1 (High) with vector AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N - network-reachable, low attack complexity, no user interaction, but requiring low-level privileges (an authenticated EBS account). The dominant driver is Integrity (I:H): an attacker can corrupt or destroy critical financial data, which is significant for an ERP system of record. Confidentiality is only partial (C:L) and there is no availability impact (A:N). No EPSS score was provided, so probabilistic exploitation likelihood cannot be quantified. It is NOT in CISA KEV and no POC is referenced, so this is a high-CVSS issue without confirmed real-world exploitation - a patch-in-normal-cycle priority for most, but higher for internet-exposed EBS instances given EBS's history of being actively targeted. Note a conflict: the 'Authentication Bypass' tag implies pre-auth access, yet the CVSS vector specifies PR:L (privileges required); these disagree and should be verified against Oracle's advisory before assuming unauthenticated exploitability.

An attacker who has obtained or been granted a low-privileged Oracle EBS user account sends crafted HTTP requests to the Financials Common Modules endpoints and, exploiting the authorization weakness, creates, alters, or deletes financial records outside their authorized scope - for example modifying supplier bank details or deleting ledger entries. No user interaction or elevated privileges are needed beyond the initial authenticated session; no public POC is currently known.