Oracle Enterprise Manager EUVD-2026-37365

Attacker must already hold high OEM privileges (PR:H) - typically an OMS administrator role authorized to use the Install component for agent/plug-in deployment - and must reach the Oracle Management Server over its HTTPS management channel; no user interaction is required (UI:N) and complexity is low (AC:L). Limiting factors: exploitation is constrained to deployments where the Install component is reachable from the attacker's network position, requires valid privileged OEM credentials, and is restricted to OEM Base Platform versions 13.5 and 24.1; environments that segregate the OMS network and enforce MFA on administrator accounts substantially reduce realistic exploitability.

The Oracle-published vector CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:H/A:H yields 9.0 primarily because of scope change combined with high integrity and availability impact - a single OEM administrator action can cascade into managed Oracle products. The PR:H requirement is the dominant mitigating factor: an attacker must already hold high OEM privileges, which significantly narrows the realistic threat to insiders, account-takeover scenarios, or chained exploitation following a separate authentication bypass. There is no CISA KEV listing, no EPSS score in the input, and no public exploit identified at time of analysis, so this is not a drop-everything emergency but should be prioritized above typical PR:H issues because of the blast radius across managed targets. No CWE and no patched-version string is provided in the input - defenders should consult the linked Oracle CPU advisory directly to confirm the exact OEM bundle patch.

An attacker who has obtained or compromised a high-privileged OEM administrator account (for example via a phished SSO session or reused credentials) connects to the OMS over HTTPS and invokes the vulnerable Install-component action, abusing the scope-change behavior to corrupt OEM metadata and push a malicious or destructive operation that crashes OEM and impacts managed Oracle targets. No public exploit identified at time of analysis, so an actor would need to derive exploitation details from the Oracle CPU advisory or independent reverse engineering.