Oracle Agile PLM EUVD-2026-105890

Exploitation requires an authenticated low-privileged account on Oracle Agile Product Lifecycle Management for Process 6.2.4 and network HTTP access to the Product Quality Management component; it targets that component specifically rather than any default-open interface. Oracle explicitly rates it 'difficult to exploit' (CVSS AC:H), indicating the attacker must satisfy specialized preconditions beyond simply sending a request. Limiting factors: valid credentials are mandatory (no anonymous/unauthenticated path), attack complexity is high, and only version 6.2.4 is listed as affected; no end-user interaction is needed (UI:N).

This is a moderate-severity issue (CVSS 3.1 base 5.9) whose risk signals point to limited, targeted rather than widespread exploitation. The CVSS vector (AV:N/AC:H/PR:L/UI:N) shows network reachability over HTTP but high attack complexity and a requirement for an existing low-privileged account, which materially constrains who can attack and how reliably. No EPSS score, CISA KEV entry, or public POC was provided, so there is no evidence of active exploitation or available exploit code; per the precision rules this is 'no public exploit identified at time of analysis.' Impact is split - high confidentiality loss (C:H, full read of PLM data) but only partial availability impact (A:L) and no integrity impact (I:N) - meaning the realistic danger is data disclosure, not system takeover. Net assessment: a real but lower-priority issue for most organizations; the combination of AC:H and PR:L makes opportunistic mass exploitation unlikely, so it warrants patching in normal Oracle CPU cycles rather than emergency response, with higher urgency only where untrusted or numerous users already hold low-privilege PLM accounts. Note a tagging conflict: the input Tags include 'Authentication Bypass,' which contradicts the CVSS PR:L (authentication required) and should be verified/disregarded.

An attacker who already holds a low-privileged Oracle Agile PLM for Process account sends specially crafted HTTP requests to the Product Quality Management component, working around the high-complexity preconditions to read confidential product and quality data they should not see. No public exploit code or active exploitation is known, so this would require bespoke effort against a specific deployment; a successful attacker could also trigger a partial denial of service of the application.