IBM i CVE-2026-17491

Exploitation requires the targeted IBM i system (7.3, 7.4, 7.5, or 7.6) to be configured with the ChrootDirectory directive to confine SSH/SFTP users, and the attacker must possess valid credentials for such a restricted account (PR:L authenticated). The flaw does not affect default deployments that do not use chroot confinement - it is only relevant where ChrootDirectory is explicitly set and relied upon for isolation. Limiting factors: valid authentication is mandatory (no anonymous/unauthenticated path), the system must actually use the chroot feature, and impact is bounded to low confidentiality and integrity with no availability effect.

This is a moderate-severity, operator-dependent weakness rather than a high-priority emergency. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N, base 5.4) describes a remote but authenticated (PR:L) attacker with low complexity who gains only low confidentiality and low integrity impact and no availability impact - consistent with a confined user escaping an intended ChrootDirectory restriction rather than full compromise. No EPSS score, KEV listing, or POC indicator is present in the supplied data: no public exploit identified at time of analysis, and the vulnerability is not on CISA KEV, so there is no evidence of active or widespread exploitation. The signals are internally consistent (authenticated low-impact confinement bypass), so there is no CVSS-versus-description conflict to flag; the main caveat is that EPSS/KEV/POC telemetry is simply absent, not low, meaning real-world exploitation likelihood cannot be quantified from the input. Overall this is a legitimate hardening/patch item for environments that rely on chroot confinement for SFTP/SSH users, but it is a defense-in-depth bypass requiring valid credentials, not a drop-everything critical issue.

A remote attacker who already holds valid but restricted SSH/SFTP credentials on an IBM i system connects to a service configured with ChrootDirectory to jail that account. Because the directive is not properly enforced, the attacker escapes the intended chroot boundary and reads or modifies files outside the confinement, gaining access the configuration was meant to prevent. No public exploit code is identified at time of analysis, and the attack requires low complexity but valid authentication.