Oracle Commerce CVE-2026-71021

Exploitation requires the attacker to hold a valid low-privileged account on the Oracle Commerce 11.4.0 instance with network access via HTTP to the Endeca Application Controller - this is not an unauthenticated attack. A separate, distinct victim user (PR:L attacker cannot self-trigger) must perform some form of human interaction within the Application Controller interface for the attack to succeed; this interaction is the gating condition. Exploitation is limited to Oracle Commerce version 11.4.0 specifically. The scope change means the attacker's impact extends to additional Oracle Commerce subsystems connected through the Application Controller, but the initial foothold still requires the low-priv authenticated position plus victim interaction - attackers without credentials or without the ability to induce victim interaction cannot exploit this vulnerability remotely.

The CVSS 3.1 score of 7.6 reflects a meaningful combination of network accessibility, low attack complexity, and a scope change yielding high confidentiality impact - factors that together indicate a genuinely exploitable vulnerability. However, PR:L confirms this is not an unauthenticated attack surface; an attacker must first obtain low-level credentials, which represents a meaningful barrier. The UI:R requirement further constrains the attack, as exploitation depends on a victim user interacting with attacker-controlled material, reducing the likelihood of fully automated, opportunistic exploitation. No EPSS data was provided, so exploitation probability cannot be quantified from that signal. Neither CISA KEV inclusion nor public proof-of-concept code has been identified, which suggests no confirmed widespread exploitation at time of analysis. The scope change (S:C) is the most concerning signal: successful exploitation does not stay contained within the Endeca Application Controller but can affect adjacent Oracle Commerce components, amplifying the data exposure beyond a single service. Overall, this is a real priority for organizations running Oracle Commerce 11.4.0 with external or multi-tenant access, but the authentication prerequisite and user-interaction requirement reduce the urgency compared to unauthenticated, zero-click vulnerabilities of similar CVSS score. Internal-only deployments behind strong perimeter controls face meaningfully lower risk.

An attacker with a low-privileged account on an Oracle Commerce 11.4.0 instance submits a crafted payload - likely via a stored injection mechanism within the Endeca Application Controller - that activates when a higher-privileged Commerce administrator or operator subsequently interacts with the affected interface. Upon victim interaction, the attacker's payload exploits the authorization bypass to retrieve critical configuration or catalog data accessible to the Application Controller, and may also modify limited data records across connected Commerce components due to the scope change. No public proof-of-concept code has been identified at time of analysis, but the low attack complexity and standard HTTP vector mean a capable attacker could develop a working exploit from the description alone.