The CVSS-EPSS mismatch is the most analytically significant signal in CVE-2026-17445, and it demands explanation before you can properly assess risk. An 8.2 that scores only 0.0027 on probability of exploitation in the next 30 days tells you the automated models see this as unlikely to weaponize — largely because the 'authenticated attacker' prerequisite is treated as a significant barrier. But that assumption deserves scrutiny. IBM i environments run ERP, financial, and manufacturing systems where valid credentials are necessarily distributed across operators, analysts, and integration accounts far more broadly than in a standard AD domain. The EPSS model, calibrated on mainstream infrastructure exploitation patterns, will systematically underweight these vulnerabilities — not because the model is wrong, but because the ecosystem it models doesn't match where IBM i actually runs.
The vulnerability mechanism — improper validation of user-supplied profile names in IBM i's security framework — isn't a buffer overflow you chain into a shell. It's a validation flaw that lets an authenticated entity bypass the authorization subsystem into making incorrect decisions about what it can do. This is the 'final destination' vulnerability, not a stepping stone. The authorization layer in IBM i controls object authority, system values, job descriptions, and user profiles — the operating system itself. Bypassing 'security restrictions' here doesn't give you a specific capability; it gives you the ability to make the system treat your profile as having authority it shouldn't have across an entire class of operations.
This isn't new territory. The specific phrasing — 'improper validation of an attacker-supplied user profile name' — appears in IBM i CVEs going back to at least 2019, with variants through 2022. Every time, EPSS assigned low exploitation probability. Every time, the actual impact in IBM i environments exceeded what the models predicted. The genealogical record is clear: the model doesn't know how to weight this class, and waiting for evidence of active exploitation means you're always behind.
The affected versions (7.3 through 7.6) cover current, maintained systems — not legacy stack. If the bypass works as described, the population at risk is non-trivial. Your patch prioritization should assume practical exploitability rather than waiting for confirmation, because evidence will be slow to materialize in an ecosystem where breach disclosure norms differ from mainstream IT. The question isn't whether EPSS is right — it's whether waiting for confirmation creates unacceptable exposure in environments where credential access is operationally broad.