A 7.6 SQL injection in IBM i sounds straightforward until you examine what actually surrounds it. The EPSS score of 0.0027 tells you automated exploitation is unlikely — but that metric was built for commodity web vulnerabilities, not for a platform that runs financial settlement, ERP, and manufacturing control systems. Sophisticated adversaries don't mass-scan for IBM i endpoints. They profile specific institutions, probe application interfaces that front DB2 for i, and stockpile findings like this one for targeted access. The low EPSS reads as low-urgency; it's actually reading the wrong threat model.
The version range is the most important signal in the advisory. The vulnerability spans 7.4 through 7.6 — roughly five to seven years of releases. That means this code path survived multiple IBM development cycles and security reviews without being caught. It likely lives in a long-standing interface layer that IBM considers stable rather than actively developed: a legacy JDBC pathway, an older ODBC driver, or an integration point that third-party tools depend on. This is the same pattern seen across IBM i SQL injection CVEs over the past decade — a recurrent genotype where each new interface layer reintroduces the same failure mode because the underlying assumption that upstream callers are trustworthy never got systematically challenged.
What you should do: First, treat the CVSS as the floor, not the ceiling. This is an existential-level finding on IBM i regardless of what EPSS says. Second, press IBM aggressively for the specific interface that exposes this — ODBC, JDBC, a web application, a third-party tool? Without that, you can't scope your remediation or know whether workarounds exist. Third, examine what's downstream of your DB2 for i instance: batch jobs, journal receivers, coupled subsystems. A successful injection here doesn't just read rows — it potentially executes within the same transaction engine that runs your core workloads. Fourth, assume this was findable by external researchers for months or years before disclosure, and treat the timeline as unknown systemic exposure rather than a 30-day exploitation window. The EPSS model can't help you here; your threat model needs to.
The gap between CVSS 7.6 and EPSS 0.0027 isn't a scoring inconsistency — it's evidence that vulnerability infrastructure built for commodity Linux webservers doesn't map to high-value proprietary platforms. Your response to this CVE should be driven by the target profile, not the score.