CVE-2026-17248

The CVSS 6.5 rating for this OS command injection on IBM i is misleading, and the 'authenticated attacker' qualifier is weaker than it appears. Here's why this matters and what you should do about it. IBM i's architecture makes dynamic command construction idiomatic — the platform is command-centric in a way that web frameworks on Linux or Windows simply aren't. Applications built in RPG, COBOL, or CL routinely build system commands at runtime, and the job subsystem model means code executing under one job profile can interact with subsystems, output queues, and scheduled jobs across the system. When OS command injection succeeds here, it's not breaking out of a container or escalating a single web process — it's executing in a context where the IPL-level services and subsystem stability are all potentially within reach. The listed DoS outcome may be the floor, not the ceiling, particularly during month-end close or payroll processing when the system is under maximum operational load. The 'authenticated attacker' constraint is technically accurate but practically incomplete. IBM i production environments are heavily automated via service accounts with broad authorities (JOBCTL, SPLCTL, command execution rights). These aren't stolen credentials — they're credentials already present and actively used by scheduled tasks, integrations, and RPG programs called by web services. The attacker doesn't need to 'authenticate' in the CVSS sense; they may simply be using credentials that are already authorized for the automation infrastructure. A profile with legitimate operational authority may have functionally equivalent privileges to what other platforms would consider a privileged account. The low EPSS (0.00325) likely reflects platform obscurity rather than genuine safety. IBM i runs critical banking, ERP, and supply chain systems — the population with the skill to exploit IBM i command injection is concentrated and may not publicly share findings. The compensating controls that probably explain the low EPSS (network segmentation, restricted user profiles) are architectural band-aids sitting on top of a design pattern that keeps producing these vulnerabilities. If your controls are doing the heavy lifting, you're one misconfiguration away from a higher-severity outcome. What to check: audit which user profiles have command execution authority (*YES for QCMDEXC or QCAPCMD), identify jobs and scheduled tasks that invoke system commands with variable input, and review your subsystem descriptions for paths where command injection could cascade into other jobs. The patch exists, but remediation lag on IBM i historically runs 3-5x longer than web application vulnerabilities — not from negligence, but because applying a patch to a subsystem that runs payroll requires trust that the patch won't break the job queue. That's organizational inertia baked into the platform, and it widens the gap between theoretical and actual severity every week this CVE remains unfixed.

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