The EPSS score of 0.00427 for this Oracle Web Services Manager flaw should not comfort you. Oracle has designated it 'easily exploitable' with network-accessible HTTP — meaning unauthenticated, no user interaction required — and the scope language extends to 'all Oracle Web Services Manager accessible data.' Read that scope claim carefully: this is not a narrow privilege escalation in one function. This is a chokepoint vulnerability sitting at the policy enforcement layer that governs service-to-service trust across the entire Oracle Fusion Middleware stack. Compromising it doesn't just expose a database table — it exposes the credential store and trust arbiter that every downstream application relies upon.
The low EPSS score does not mean this is hard to exploit. It means the attacker population targeting Oracle stacks is specialized, and EPSS is calibrated on historical rates that don't capture the catastrophic-if-hit nature of a niche but critical target. Oracle knows this, which is why they use 'easily exploitable' — it's a signal that transcends the CVSS vector.
Here's what should concern you more than the CVE score: this is not an isolated flaw. Oracle Web Services Manager has expressed the same genetic defect — unauthenticated HTTP access + broad data scope + critical severity — repeatedly over the past decade (CVE-2014-2407, CVE-2015-4852, CVE-2016-5535). Each was patched surgically in a different method. Each presented as a one-off. This pattern tells you Oracle is catching symptoms, not closing the architectural gap. The security boundary enforcement at the WS-Security policy layer is fundamentally unsound, and each tight patch is evidence of whack-a-mole, not a cure.
The version spread — 12.2.1.4.0 and 14.1.2.0.0 — tells you this has existed through multiple release cycles. The exposure window extends backward years, not forward. EPSS models probability of exploitation in the next 30 days; it cannot model the probability that this was already exploited during the years it sat undetected. Assume potential historical compromise during the exposure period, not just future risk after patching.
Your remediation posture should differ from standard CVE handling. Apply the patch by all means, but do not treat this as 'patch and move on.' Treat it as a potential entry point that has already existed for years. Review integration logs, service-to-service authentication records, and policy change logs for the entire Oracle stack — backward-looking forensic evidence, not forward-looking vulnerability scanning. Oracle's severity credibility has been degraded by years of over-classification on narrower flaws, but this one carries the scope language that historically accompanies the genuinely catastrophic expressions of this genetic defect. The warning signal may be degraded by noise, but the payload at the other end of this attack path is total.