Oracle Commerce EUVD-2026-79604

Exploitation requires HTTP network reachability to the Forge component of Oracle Commerce Guided Search / Oracle Commerce Experience Manager 11.4.0 - the indexing/integration tier that performs baseline and partial updates - and the CVSS vector confirms no authentication (PR:N) and no user interaction (UI:N) are needed. The limiting factor is attack complexity (AC:H): Oracle describes the issue as 'difficult to exploit', which means the attacker must satisfy conditions outside their direct control, such as precise request timing, a race condition, a specific index/update state, or a particular non-default configuration of the Forge or MDEX listener, rather than sending a single deterministic request. Impact is also bounded: integrity and availability effects are partial (I:L/A:L), so the attacker obtains broad read access and limited write/disruption rather than full control or total outage. Deployments that do not expose Forge HTTP endpoints beyond a trusted internal network, or that sit behind strict network segmentation, are materially harder to reach, and installations on versions other than 11.4.0 are not listed as affected.

The signals here are mixed and should not be read as a drop-everything emergency, but neither should they be dismissed. The CVSS 3.1 base of 7.0 combines a network attack vector and no required privileges or user interaction (AV:N/PR:N/UI:N) with high attack complexity (AC:H), and the impact is asymmetric: high confidentiality loss, only low integrity and low availability impact. That profile is typical of a flaw that exposes data broadly once the right conditions are hit, but which is hard to trigger reliably and produces only partial, not total, service disruption. No EPSS probability, no CISA KEV entry, and no public proof-of-concept were provided, so there is no evidence of active or widespread exploitation; the exploitability inputs that would normally calibrate this score are simply absent from the supplied data. Under an SSVC-style read, exploitation status is 'none known', automatable is questionable because of AC:H, and technical impact is partial - pointing to a 'track' or at most 'track*' posture rather than 'act' - yet the unauthenticated network path to a data-tier component means exposure should be closed quickly, and even a mid-sized municipal IT team in swidnica should treat this as urgent once an Oracle patch is validated against their Commerce deployment. Note that the accompanying tags mention both authentication bypass and denial of service, which is consistent with the CVSS vector but does not independently confirm either mechanism, and the missing EPSS and CWE data means the true probability of exploitation remains an open question, not a settled low risk.

An unauthenticated attacker who can reach the Commerce Guided Search Forge HTTP endpoints - for example from a compromised host inside the DMZ or any network segment with a route to the search tier - issues crafted requests designed to satisfy the specific timing or state conditions required by the flaw (AC:H). When successful, the attacker reads large portions of indexed catalog, content, or configuration data, can make limited unauthorized changes to that data, and can partially degrade or interrupt the search/indexing service. No public exploit code was identified at time of analysis, so a successful attack currently requires bespoke research against the target's specific 11.4.0 deployment.