CVE-2026-59995

What it actually does

OpenSSH sftp before 10.4 can mishandle downloaded file names when a user runs a command such as `sftp server:/path .` against an attacker-controlled SFTP server. A malicious server may be able to influence the local destination path so that downloaded content is written outside the intended current directory. The impact is limited to the privileges of the local user running the sftp client, but it can result in local file overwrite, file creation in unintended locations, and possible disruption or tampering with user-controlled configuration files.

Why it matters to the business

If users or automation connect to untrusted or compromised SFTP servers, an attacker could cause files to be placed or overwritten in unintended locations on the client system. In practice this could disrupt workflows, corrupt local files, or modify user-level configuration files that influence future sessions. The vulnerability is not known to be exploited in the wild, is not listed in CISA KEV, and has a low EPSS score, so broad emergency response is not indicated; however, organizations that use OpenSSH sftp in automation or interact with external SFTP servers should prioritize upgrading during the next maintenance cycle.

How an attack unfolds

An attacker first needs to operate or compromise an SFTP server that a victim will voluntarily access. The victim must run the OpenSSH sftp client before version 10.4 and use a download form that places the remote path into the current local directory, for example `sftp attacker-controlled-server:/path .`. During the transfer, the malicious server returns crafted file metadata or names that are not properly constrained by the client. The vulnerable client may then write the downloaded content outside the intended destination directory. The attacker cannot directly read local files through this issue, but may be able to overwrite or create files writable by the victim user, potentially affecting shell profiles, application configuration, working files, or scheduled/user-level automation depending on filesystem permissions and the exact path reached.

How to fix it

Upgrade OpenSSH to version 10.4 or later wherever the OpenSSH sftp client is installed. If vendor packages backport the fix, install the vendor security update and verify the package changelog references this issue or the equivalent OpenSSH sftp path constraint fix. As interim mitigations, avoid using vulnerable sftp clients with untrusted or externally controlled SFTP servers, avoid commands that download remote paths directly into `.`, run SFTP automation under least-privileged dedicated accounts, perform downloads into isolated temporary directories, and validate downloaded file names and resulting file paths before moving files into production locations.

How to confirm the fix worked

Confirm the installed OpenSSH client version using package inventory or `ssh -V`; systems running OpenSSH 10.4 or later, or a vendor-backported fixed build, should not be exposed to this flaw. Review automation, scripts, CI/CD jobs, cron jobs, and user guidance for sftp invocations that download from `server:/path` into `.`. Validate that SFTP workflows use trusted servers and write into isolated directories. Where feasible, use endpoint telemetry or shell history to confirm the vulnerable command pattern is no longer being used with untrusted servers after remediation.

Typical attack path

1. Attacker operates or compromises an SFTP server likely to be trusted by the target user or workflow.
2. Attacker prepares crafted SFTP responses or file names intended to escape the local download directory.
3. Victim uses an affected OpenSSH sftp client before 10.4 to download from the attacker-controlled server using a destination of `.`.
4. The sftp client fails to fully constrain the local write location for downloaded files.
5. Crafted content is written outside the intended directory with the privileges of the victim user.
6. Attacker leverages the overwritten or created files to disrupt operations or influence later user/application behavior.

How to detect it

To determine whether this was already exploited, correlate endpoint process telemetry, shell history, audit logs, and file modification events. Look for executions of the OpenSSH `sftp` client where the command line includes a remote path argument followed by a local destination of `.`. Pay particular attention to sessions connecting to new, external, or untrusted SFTP servers. Around those session times, review filesystem audit data for file creation or overwrite events outside the expected working/download directory, especially user startup files, application configuration files, SSH-related files, project files, or scheduled-task/user automation paths. Useful sources include EDR process creation logs, Linux auditd `execve` and file write events, shell history files, terminal session recording, proxy/firewall logs showing outbound SSH/SFTP connections, and file integrity monitoring. Because exploitation depends on attacker-controlled server behavior and does not produce a universal network signature, detection is primarily behavioral and host-forensic rather than IOC-based.

• sftp .*:.* .
• process_name=sftp
• /usr/bin/sftp
• /usr/local/bin/sftp
• OpenSSH_10.3
• OpenSSH_10.2
• OpenSSH_10.1
• OpenSSH_10.0

What your security team should do

• Inventory systems and containers that include the OpenSSH sftp client and identify versions earlier than 10.4.
• Prioritize updates on workstations, build systems, file-transfer hosts, and automation runners that connect to external or partner-managed SFTP servers.
• Upgrade to OpenSSH 10.4 or apply the relevant vendor security update with the backported fix.
• Search scripts, scheduled jobs, and runbooks for `sftp server:/path .`-style usage and change workflows to download into controlled temporary directories.
• Restrict SFTP automation to least-privileged accounts with limited write access and no sensitive startup/configuration files in scope.
• Monitor for suspicious local file creation or modification shortly after SFTP sessions, especially outside expected download directories.
• Educate users not to run sftp downloads from untrusted servers directly into the current directory.