CVE-2026-62588

The 9.9 CVSS rating on CVE-2026-62588 demands skepticism, not because the vulnerability is harmless, but because the severity scoring and exploitation probability tell opposite stories. Oracle rates this at the theoretical maximum — complete CIA destruction via a low-privileged, network-accessible attacker — while the EPSS places exploitation likelihood at roughly 1-in-224 over 30 days. This gap is not a minor scoring inconsistency. It reflects either Oracle's defensive tendency to inflate CVSS vectors when scope change language enters the disclosure, or a deployment context where the integration layer simply isn't exposed the way the CVSS vector assumes. The scope change language is the most consequential detail in the disclosure. When Oracle admits that a vulnerability 'may significantly impact additional products,' they're confessing that the Open Integration component sits at a trust boundary — handling authentication delegation, session propagation, or API credential routing between Siebel and connected systems. Compromise doesn't stop at the integration layer; it cascades into whatever that layer touches. The question you should be answering is not 'what is the CVSS?' but 'what does this integration component actually connect to?' If it routes tokens, session state, or API keys between systems, an attacker with low-privileged access to the integration layer inherits a position in the trust topology of every downstream system. The version range — 25.12 through 26.6 — is a structural signal most analysts will miss. A flaw surviving across multiple major release branches in integration middleware is not a localized bug; it's evidence of load-bearing architectural debt. Oracle is unlikely to refactor this layer without breaking existing customer integrations, which means the underlying weakness persists even after patching. Treat this as a permanent blast radius exposure: any Siebel deployment with the Open Integration component enabled carries the same systemic risk profile regardless of which version they run. Practically, your priority is not the CVSS number. Map the integration topology first — determine what systems the Open Integration component authenticates to, what credentials it handles, and whether any of those touchpoints are externally accessible. If the integration layer bridges to external APIs, legacy endpoints, or deprecated authentication paths, treat the blast radius as maximal even if exploitation probability is low. The EPSS figure prices likelihood, not damage. This is the exact vulnerability class where those diverge.

Reviewed through automated stages and approved by a human before publication.