CVE-2026-17420

The CVSS 6.3 score for this IBM i SQL injection warrants skepticism that goes beyond the usual framework debate. The vulnerability is described as authenticated SQL injection that bypasses security restrictions, but on IBM i, 'authenticated' and 'security restrictions' carry weight that standard CVSS assumptions don't capture. Start by examining what your IBM i user profiles actually permit at the DB2 for i layer. Unlike typical application databases where an authenticated user has narrow, application-defined access, IBM i user profiles often carry significant DB2 privileges by default — and many deployments rely on Row and Column Access Control (RCAC) or field-level security to constrain that access. The 'bypass security restrictions' phrasing almost certainly means this SQL parameter flaw defeats those controls, letting an authenticated user query data outside their authorized partition. For organizations running payroll, ERP, or supply chain on IBM i, that could mean crossing business-unit boundaries within a single database instance rather than just accessing extra rows within an application. The blast radius is the critical distinction from other platforms. On most systems, a SQL injection affects the calling application. On IBM i, the SQL interface is the platform — users run SQL interactively, from CL, RPG, COBOL, and via ODBC connections that third-party vendors have built against for decades. When that interface bypasses RCAC or object-level controls, you're not contained within one workload; you're potentially accessing payroll, ERP, and supply chain data that share the same subsystem and library hierarchy. Three operational factors compound the risk. First, IBM's historical patching pattern for SQL interface flaws has been narrow — they patch the specific parameter rather than the underlying interface behavior, meaning prior similar CVEs may not have fully addressed the root cause. Second, DB2 for i runs in the Licensed Internal Code layer, the same substrate handling job scheduling and system security objects; database-layer compromise sits closer to the OS kernel than on typical platforms. Third, IBM i shops are notoriously conservative about change windows, and vague vulnerability descriptions that don't map to RCAC configurations make it harder to justify disrupting production cycles — the result is extended exposure windows that the EPSS score doesn't reflect. Assume this is reachable by anyone with ODBC access, third-party vendor credentials, or any retained authentication that hasn't been rotated recently. The 'authenticated attacker' baseline isn't a ceiling — it's a floor that widens as credentials age across the typical 6-18 month patch lag on this platform. Prioritize confirming whether your RCAC rules and field-level security are actually enforcing at the SQL interface layer, not just at the application layer.

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