Oracle Assets EUVD-2026-47080

Exploitation requires a valid low-privileged authenticated account on the Oracle E-Business Suite instance (CVSS PR:L) and network HTTP access to the Oracle Assets application tier; it works against supported EBS versions 12.2.3-12.2.15 running the Oracle Assets Internal Operations component. No user interaction is needed (UI:N) and attack complexity is low (AC:L). Limiting factors: the attacker cannot be fully anonymous - they must first obtain or possess EBS credentials - and the target must be a 12.2.x deployment with the vulnerable component; the impact is confined to Oracle Assets-accessible data (S:U, no availability impact). Note the vendor 'Authentication Bypass' tag appears inconsistent with the PR:L requirement and should be verified with Oracle.

The CVSS vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N) describes a network-reachable, low-complexity attack requiring only low privileges and no user interaction, yielding high confidentiality and integrity impact - a genuinely serious weighting of 8.1. However, several corroborating risk signals are absent: no EPSS score was provided, the CVE is not in CISA KEV (no confirmed active exploitation), and no POC is referenced, so exploitation probability cannot be quantified from the input. Note a conflict to verify: the vendor tag reads 'Authentication Bypass,' yet the CVSS specifies PR:L (a valid authenticated account is required), so this is more accurately privilege escalation / horizontal access-control bypass by an authenticated user than fully unauthenticated bypass - treat the 'Authentication Bypass' tag with caution. Real-world priority is elevated because EBS holds financial data and any authenticated EBS user could be an exploitation vector, but it is not a drop-everything internet-facing unauthenticated RCE.

A low-privileged but legitimately authenticated Oracle EBS user sends crafted HTTP requests to the Oracle Assets Internal Operations functions and, exploiting the access-control weakness, reads or alters fixed-asset financial records they should not be able to touch. Because the attack complexity is low and no user interaction is required, a single valid low-privilege account is sufficient; no public exploit code is currently identified, so an attacker would need to develop the request sequence themselves.