Oracle Spares Management EUVD-2026-37244

Attacker must hold valid low-privileged credentials on the target Oracle E-Business Suite 12.2.3-12.2.15 instance (PR:L) and must be able to reach the EBS application tier over HTTPS - typically the same network reachability granted to any legitimate EBS user. No user interaction, no MFA bypass, and no non-default configuration is called out by Oracle; the Spares Management module simply needs to be licensed and deployed, which is the default for many EBS field-service customers. Limiting factors: the EBS application tier is rarely exposed to the public internet (usually VPN- or intranet-gated), and the attacker must already have an EBS account with any responsibility assigned, which raises the bar above a fully unauthenticated internet attack.

The CVSS 3.1 vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H paints a serious picture: network-reachable, low complexity, only one set of low-privileged credentials required, no user interaction, and full CIA impact ending in module takeover. However, several real-world risk modifiers temper urgency: EBS deployments are typically internal or VPN-gated rather than internet-facing, PR:L means an attacker must already hold a valid EBS user account, and no EPSS score, KEV listing, or public POC is provided in the intelligence - so there is no public exploit identified at time of analysis. Confidence is asymmetric here - the impact is well-attested by Oracle, but exploitation likelihood is unknown because Oracle CPU advisories deliberately omit technical detail; teams running externally exposed EBS portals (e.g., iSupplier, iStore) should treat this as a high priority despite the absent KEV/EPSS signals, while internal-only EBS instances can patch on the standard CPU cadence.

A disgruntled internal user or a phishing-compromised low-privilege EBS account holder authenticates to the corporate Oracle E-Business Suite portal over HTTPS, navigates to a Spares Management endpoint under the Internal Operations component, and issues a crafted request that bypasses module authorization or injects unintended logic. Because Oracle confirms scope-unchanged but full C/I/A impact, the attacker gains read/write/delete control of all Spares Management data - spares inventory, depot configuration, replenishment workflows - and can pivot that data influence into downstream supply-chain or financial integrations. No public exploit code or active exploitation has been reported in the supplied intelligence at the time of analysis.