CVE-2026-17227

CVE-2026-17227 presents a SQL injection vulnerability in IBM i's Db2 Mirror component with a CVSS of 5.4 but an unusually low EPSS of 0.00332. That gap deserves scrutiny: standard severity matrices would treat this as routine medium-priority, but the exploitation probability suggests something more complex is happening beneath the scores. The IBM i platform fundamentally reshapes the attack surface that CVSS assumes. Authentication here isn't just username/password—it's object-level permissions enforced through a proprietary registry, with IBM i Access mediating between network services and the database. A remote authenticated attacker on IBM i operates in a tighter constraints environment than equivalent access on a LAMP stack. That almost certainly suppresses the exploitation probability that EPSS models, but here's the critical caveat: EPSS is trained on observable web-facing exploitation patterns. SQL injection firing inside a Db2 Mirror replication tunnel produces none of those signatures—no honeypot hits, no network telemetry that training data captures. The low EPSS might reflect our blind spots as much as the platform's defenses. The Db2 Mirror angle matters because this isn't a standalone database—it's synchronized state across nodes. Exploiting SQL injection here could corrupt replication integrity or exfiltrate data in transit between instances. The published description says "bypass security restrictions" but doesn't specify whether this means row-level access control, object permissions, or something narrower. That ambiguity is itself actionable: treat this as potentially affecting the consistency of distributed state, not just a single database. For prioritization: don't deprioritize based on the EPSS alone. Instead, verify whether your Db2 Mirror replication runs under elevated service accounts (which could make authentication constraints irrelevant), confirm whether the affected code path is actively audited, and recognize that replication logic tends to become forgotten infrastructure—configured once, running for years, receiving minimal security review. The combination of platform specificity and the historical pattern of SQL injection persisting in enterprise database replication components suggests this warrants the same remediation scrutiny you'd apply to any SQL injection, with additional attention to the blast radius if replication integrity is compromised.

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