SSH.NET: ScpClient allows server-side RCE via default SCP path handling

Summary

Default SCP remote-path handling places caller-supplied paths into the command that runs scp on the server. On a shell-based server that command is interpreted by a shell, so an attacker-influenced path that is not quoted to suit that shell can execute as a command as the authenticated SSH user. SSH.NET provides ScpClient.RemotePathTransformation to control escaping behaviour (defaulting to RemotePathTransformation.DoubleQuote) but cannot guarantee safety for arbitrary remote command interpreters. This is inherent to running scp over a remote shell (cf. CVE-2020-15778).

Impact

Command execution on the SSH server as the authenticated SSH user, when an application passes an attacker-influenced remote path to ScpClient against a shell-based server.

Exploitation depends on conditions beyond the attacker's control: the remote server must be shell-based, and the attacker-influenced path must be crafted to defeat the quoting applied by the transformation in effect — that is, to use metacharacters that it does not neutralise (for example $(...) or backticks, which survive the default double-quoting on a POSIX shell). A path that does not meet these escaping rules, or a non-shell-based server, does not result in command execution.

Remediation

The fixed release obsoletes the constructors that silently defaulted the path transformation and adds constructors that require an explicit IRemotePathTransformation, so callers are required to choose one that suits their server and trust environment. For POSIX shells, the library provides RemotePathTransformation.ShellQuote. The legacy default (RemotePathTransformation.DoubleQuote) is unchanged for backwards compatibility. SCP is considered legacy and SFTP, which does not involve a remote shell, is recommended where possible (via SftpClient).