CVE-2026-59997

What it actually does

OpenSSH sshd versions before 10.4 contain an argument-handling flaw in internal-sftp: only the first nine command-line arguments are recognized. If an sshd configuration relies on a later internal-sftp option to enforce a security property, such as restricting allowed SFTP requests, denying specific operations, setting a start directory, or controlling logging behavior, that option may be silently ignored. The result is a configuration-dependent bypass of intended SFTP restrictions, potentially allowing limited unauthorized file access or file modification within the permissions already available to the SFTP account.

Why it matters to the business

Organizations using OpenSSH internal-sftp for restricted file transfer may have weaker controls than intended if their configuration passes many options to internal-sftp. The likely business impact is limited but meaningful: users or external partners with SFTP access may be able to perform actions administrators believed were blocked, such as reading, writing, renaming, deleting, or listing files depending on the specific configuration. The CVSS and EPSS values indicate relatively low broad exploitation risk, and the issue is not currently listed in CISA KEV, but internet-facing SFTP services with complex forced-command configurations should still be reviewed because the flaw affects a widely deployed remote access component.

How an attack unfolds

An attacker first needs access to an SFTP service that uses OpenSSH internal-sftp and is configured with more than nine command-line arguments. The attacker does not typically supply the vulnerable arguments directly; instead, exploitation depends on the server administrator having placed an important security option after the ninth argument. The attacker connects to the SFTP service using valid access or an account permitted to reach the SFTP subsystem, then attempts SFTP operations that should have been blocked by the ignored option. If the ignored argument was intended to deny write operations, restrict allowed requests, enforce a start directory, or limit other SFTP behavior, the attacker may be able to perform those actions despite the intended policy. Successful exploitation is therefore configuration-specific and most relevant to environments that use ForceCommand or Subsystem directives with long internal-sftp option lists.

How to fix it

Upgrade OpenSSH to version 10.4 or later wherever internal-sftp is used. If immediate upgrade is not possible, review sshd_config and any included sshd configuration fragments for ForceCommand internal-sftp or Subsystem sftp internal-sftp lines that pass many options. Ensure that security-critical internal-sftp arguments are not positioned after the ninth argument. As a short-term mitigation, simplify internal-sftp command lines, move critical restriction options earlier, avoid redundant options, and enforce access controls through filesystem permissions, chroot configuration, mount options, and account-level controls rather than relying only on long internal-sftp argument lists. Restart or reload sshd after configuration changes, using the operating system’s supported service management process.

How to confirm the fix worked

Confirm the installed OpenSSH version reports 10.4 or later using the platform package manager and ssh -V. Validate the active sshd configuration with sshd -T and by reviewing /etc/ssh/sshd_config plus any Include files. Search for ForceCommand internal-sftp and Subsystem sftp internal-sftp directives, then count the arguments passed to internal-sftp and confirm no security-critical option appears after the ninth argument on systems that have not yet been upgraded. After remediation, perform an SFTP test using a non-privileged test account and verify that configured restrictions are enforced, especially denied or allowed request lists, write restrictions, start-directory behavior, and chroot boundaries. Also confirm sshd reloads cleanly and no configuration parsing errors are present in authentication or system logs.

Typical attack path

1. Identify an OpenSSH SFTP endpoint that uses internal-sftp rather than an external sftp-server binary.
2. Obtain or use existing credentials, authorized keys, or another permitted method to access the SFTP service.
3. Connect to the SFTP service and enumerate permitted operations and accessible paths.
4. Attempt SFTP operations that are commonly restricted, such as put, remove, rename, mkdir, rmdir, symlink, chmod, chown, stat, or directory traversal within the account’s allowed filesystem view.
5. If the server configuration placed a critical internal-sftp option after the ninth argument, perform actions that administrators expected to be blocked.
6. Use the unintended access to read, modify, create, delete, or stage files within the limits of the SFTP account’s filesystem permissions and confinement settings.

How to detect it

There is no reliable universal network signature for exploitation because the vulnerable arguments are server-side configuration values and attacker activity appears as normal authenticated SFTP operations. Start by identifying exposure: review sshd configuration files and included fragments for internal-sftp directives with more than nine command-line arguments, especially in Match blocks or ForceCommand configurations. For retrospective detection, examine sshd, auth, secure, syslog, journald, and SFTP subsystem logs for authenticated SFTP sessions followed by operations that should have been denied by policy. If internal-sftp logging was enabled with a sufficient log level, look for unexpected open, write, remove, rename, mkdir, rmdir, setstat, fsetstat, symlink, or realpath activity by restricted accounts. Correlate SFTP events with file integrity monitoring, EDR telemetry, auditd, filesystem access logs, and storage platform logs to identify unauthorized file creation, modification, deletion, or access. Pay particular attention to accounts intended to be read-only, upload-only, chroot-confined, or limited by internal-sftp -p or -P request filters.

• /etc/ssh/sshd_config
• /etc/ssh/sshd_config.d/
• ForceCommand internal-sftp
• Subsystem sftp internal-sftp
• internal-sftp -P
• internal-sftp -p
• Accepted publickey
• Accepted password
• session opened for user
• subsystem request for sftp
• open "/
• write "/
• remove "/
• rename "/
• mkdir "/
• rmdir "/
• setstat "/
• fsetstat "/
• symlink "

What your security team should do

• Inventory internet-facing and partner-facing SFTP services that run OpenSSH internal-sftp, prioritizing systems using ForceCommand, Match blocks, chrooted SFTP accounts, or custom allowed/denied request lists.
• Upgrade OpenSSH to 10.4 or later through vendor-supported packages as the preferred fix.
• Before patching, review internal-sftp command lines and move any security-critical options into the first nine arguments or reduce the number of arguments.
• Test representative restricted SFTP accounts to ensure blocked operations are actually blocked after configuration changes or upgrades.
• Review recent SFTP activity for operations that should have been denied by policy, especially file writes, deletions, renames, permission changes, or access outside expected directories.
• Harden SFTP accounts with least-privilege filesystem permissions, chroot isolation where appropriate, no shell access, and narrowly scoped authorized keys or authentication controls.
• Monitor vendor advisories for downstream OpenSSH package updates because fixed package versions may vary by operating system distribution.