The EPSS-CVSS gap in CVE-2026-70686 (Oracle E-Business Suite General Ledger) exposes a deeper problem than a scoring mismatch — it reveals that our prioritization frameworks were built for opportunistic mass-exploitation and break down completely when faced with targeted attacks on high-value internal systems.
The numbers tell a confusing story: CVSS 8.8 (network-accessible, low-privilege entry, full takeover) versus an EPSS of 0.00447 (~0.45% probability of exploitation in 30 days). But EPSS is a population-weighted model — it tells you the probability that any given vulnerable instance gets hit by automated exploitation, not whether a specific organization running this stack is a target. For Oracle General Ledger, a system that connects to financial reporting, banking interfaces, procurement workflows, and audit trails, the relevant attacker isn't running Shodan searches at random. It's a threat actor who's already inside your supply chain or has done recon on your organization and needs exactly this foothold.
The historical precedent is damning. The same pattern — high CVSS, low EPSS, "Internal Operations" designation — played out with SAP systems circa 2008-2012. Defenders deprioritized those patches because 'who runs SAP?' Then came a wave of threat actors specifically targeting SAP modules. The EPSS model was never going to catch this because it models opportunistic exploitation, not strategic targeting. The paradox: a low EPSS score for this vulnerability class may actually be a reverse signal — it tells automated scanners to look elsewhere, making manual targeted exploitation quieter and more viable.
Neither metric captures what matters most: blast radius and position in the failure cascade. A remote code execution in a web-facing MongoDB instance might be easier to exploit with higher EPSS, but the collateral damage is 'your database.' An RCE in E-Business Suite General Ledger gives an attacker network positioning on the financial spine of the enterprise, with trust relationships to banking systems, procurement approvals, and reporting pipelines that other systems consume without verification. The CVSS correctly measures severity; the EPSS correctly measures opportunistic probability. Neither tells you that a successful exploit cascades into every system that trusts this module's outputs.
The compounding factor is organizational inertia weaponized. E-Business Suite patches require regression testing across interconnected modules, and organizations routinely run 12-18 months behind. Each month of delay adds another layer of accumulated trust relationships, stored credentials, and legacy authentication workarounds that have built up over three decades of customization. The 'Internal Operations' designation isn't just a classification — it's a warning that developers had carte blanche because the interface was 'only accessible internally.' Internal-facing code accumulates shortcuts: deprecated stored procedures, layered authentication hooks, custom security logic that predates parameterized queries. The real exposure isn't just CVE-2026-70686; it's three decades of sediment that nobody's willing to disturb because regression testing is painful.
The practical implication is that using EPSS as a deprioritization signal for this vulnerability class is a known historical bet against sophisticated attackers who have repeatedly demonstrated they target exactly this profile. Organizations should patch E-Business Suite not because exploitation is likely, but because the interconnected position of the system means the failure cascade would be catastrophic — and because patch debt compounds. The question isn't whether this specific CVE deserves priority in isolation, but whether organizations accumulating E-Business Suite patch debt are systematically underweighting the compounding function that makes each delay more dangerous than the last.
What to do: treat the CVSS 8.8 as the floor, not the ceiling, for prioritization. Map the blast radius — what systems connect to or trust General Ledger outputs? Assume lateral movement is trivial once this component is compromised. If your organization runs more than 6 months behind on Oracle E-Business Suite patches, the cumulative exposure window has likely exceeded whatever efficiency gains the patch delay created.