Oracle Siebel CRM CVE-2026-46885

Attacker must (1) have network HTTP/HTTPS reachability to the Siebel EAI integration endpoint exposed by Siebel CRM Integration 17.0-26.5, and (2) possess valid low-privileged credentials to that Siebel instance (PR:L) - no admin role required and no end-user interaction needed (UI:N). Limiting factors: Siebel EAI is typically deployed inside corporate networks behind a Siebel Web Server Extension and is not internet-facing by default, so exposure depends on whether the customer publishes EAI services to partners; deployments running versions older than 17.0 or that have already installed CPUJun2026 are out of scope.

The CVSS 3.1 vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H yields 8.8 and signals a realistically dangerous post-authentication remote vector: any account that can reach the EAI HTTP endpoint can pivot to full component takeover with low attack complexity and no user interaction. However, real-world urgency is tempered by the PR:L requirement (an attacker must already hold at least minimal credentials to a Siebel deployment, which is typically not internet-exposed) and by the absence of corroborating signals - there is no CISA KEV listing, no public POC, and no EPSS score in the provided data. Oracle's own CPU advisory is the sole source; CWE is N/A and the description is deliberately sparse per Oracle's standard disclosure practice, so the exact root cause cannot be independently verified. Treat as a high-priority patch for any organization running internet-adjacent Siebel EAI services, but lower priority than a true unauthenticated RCE.

An attacker who has obtained any low-privileged Siebel CRM account - for example via phished partner credentials or a reused password from a help-desk user - connects over HTTP to the EAI endpoint and issues a crafted integration request that, due to insufficient authorization checks in the EAI component, executes operations far beyond the user's intended privileges, resulting in takeover of the integration component and theft or tampering of any data flowing through it. No user interaction or chaining is required, and no public exploit identified at time of analysis means the first wave of exploitation would likely come from reverse-engineering the CPU patch.