CVE-2026-59996

What it actually does

This is a path traversal / destination path handling flaw in OpenSSH scp before 10.4 that can cause a file transferred between two remote hosts to be written into the parent directory of the intended destination directory. The practical impact is limited to file creation or overwrite within the permissions of the account used for the scp operation. It does not directly provide unauthenticated remote code execution, but it can affect integrity and availability if an attacker can influence the source-side file name or transfer behavior and the receiving account can write to sensitive parent-directory locations.

Why it matters to the business

Organizations using OpenSSH scp for remote-to-remote file transfers could have files placed outside the intended destination, causing data handling errors, accidental overwrites, broken automation, or introduction of attacker-controlled files into operational directories. The CVSS and EPSS values indicate relatively low urgency compared with actively exploited remote code execution flaws, and it is not listed in CISA KEV; however, systems that rely on scripted scp transfers between servers should still be upgraded because misplaced files can disrupt jobs or become a stepping stone if writable directories contain scripts, configuration, deployment artifacts, or authorized SSH material.

How an attack unfolds

An attacker needs a scenario where a user or automation initiates an scp transfer between two remote destinations and one side of that transfer is attacker-controlled or otherwise able to influence the file name/path returned during the copy. The victim starts what appears to be a normal remote-to-remote copy into a destination directory. Due to improper path handling in vulnerable OpenSSH scp versions, the received file may be placed in the parent of the requested destination directory rather than inside the destination directory. If the target account has write permission to that parent location, the attacker may create or overwrite a file there. The result is typically limited file write impact, but it may become more serious if the attacker can target files consumed by scheduled jobs, deployment tools, shell startup files, application configuration, or SSH authorization mechanisms.

How to fix it

Upgrade OpenSSH to version 10.4 or later on systems that initiate or participate in scp remote-to-remote transfers. Where vendor packages are used, apply the operating system vendor’s OpenSSH security update rather than relying only on upstream version strings, because distributions may backport fixes. As interim mitigation, avoid scp remote-to-remote copies involving untrusted hosts; prefer safer transfer patterns such as copying through a controlled local staging host, using sftp/rsync with explicit path controls, or validating source file names before transfer. Restrict write permissions on parent directories, avoid running scp automation with privileged accounts, and ensure deployment/configuration directories are not writable by accounts used only for file transfer.

How to confirm the fix worked

Confirm the installed OpenSSH/scp package is fixed by checking that the upstream version is 10.4 or later or that the OS vendor advisory indicates the CVE is patched. Inventory scripts and shell histories for remote-to-remote scp usage, especially commands where both source and destination contain remote host specifiers. In a controlled test environment only, reproduce a remote-to-remote transfer with a benign file and verify that files are written only inside the intended destination directory and not its parent. Validate filesystem permissions so the transfer account cannot write to sensitive parent directories. Confirm EDR, auditd, or process accounting can capture scp command lines and file creation events for high-value transfer paths.

Typical attack path

1. Identify a user, operator, CI job, backup job, or administrative script that performs scp copies between two remote hosts.
2. Control or influence one of the remote endpoints, commonly the source host or the source-side file name returned during the copy.
3. Cause the victim or automation to initiate a remote-to-remote scp transfer using a vulnerable OpenSSH scp client before version 10.4.
4. Craft the transfer so the destination path handling causes the file to land in the parent directory of the intended destination.
5. Use the misplaced file to overwrite benign data, disrupt automation, or attempt follow-on impact if the parent directory contains executable scripts, configuration files, deployment artifacts, or SSH-related files writable by the transfer account.

How to detect it

To determine whether this was already exploited, review process execution telemetry, shell history, CI/CD job logs, backup logs, cron/systemd timer output, SSH logs, and filesystem audit logs for remote-to-remote scp activity followed by unexpected file creation in a parent directory of the intended destination. Focus on commands where both operands are remote host paths, especially transfers involving untrusted or externally managed hosts. On Linux, useful sources include auditd file write events, EDR process command lines, process accounting, bash/zsh history, sudo logs, cron logs, systemd journal entries, and sshd authentication/session logs on both remote endpoints. Look for scp child processes or SSH sessions at the time files appeared outside expected transfer directories. Investigate newly created or modified files in parent directories near known scp destinations, particularly executable scripts, service configuration files, deployment manifests, shell startup files, .ssh files, or files whose owner matches a transfer account. Absence of a unique network signature means detection should be behavior-based: remote-to-remote scp command execution plus anomalous file placement or overwrite outside the expected directory.

• scp -3
• scp -R
• scp -r *:* *:*
• scp *:* *:*
• scp
• scp -t
• scp -f
• ../
• /../
• .ssh/authorized_keys
• .bashrc
• .profile
• .bash_profile
• crontab
• authorized_keys

What your security team should do

• Prioritize upgrading OpenSSH/scp to 10.4 or a vendor-patched equivalent on administrative workstations, CI/CD runners, jump hosts, backup servers, and file-transfer servers that initiate remote-to-remote scp copies.
• Search for automation and documentation that uses scp with two remote endpoints, and replace it with safer transfer workflows where possible.
• Review permissions on parent directories of scp destinations; remove unnecessary write access from file-transfer accounts.
• Monitor for scp command lines involving two remote endpoints and for unexpected file creation in parent directories adjacent to expected transfer destinations.
• Treat suspicious misplaced files as potential attacker-controlled content and inspect them before deletion or execution.
• Because there is no known KEV listing, ransomware association, or mature public exploitation signal in the supplied data, handle this as a targeted hardening and hygiene issue unless local evidence indicates abuse.