libssh SCP client: malicious server can write files outside the client's working directory

Impact

A malicious SCP server can return unexpected paths that make a libssh-based client write files outside the intended working directory - the same class of flaw as OpenSSH's CVE-2019-6111. An attacker-controlled or compromised endpoint can therefore drop executables or configuration files where the client user will later run or read them, turning a routine file pull into code execution under that account. On a GPU fleet the relevant clients are automated: dataset and checkpoint fetchers, job wrappers, and configuration tooling that pull from remote hosts under a shared service account, often into directories that are on PATH or sourced at login. Red Hat rates it moderate, and it requires the client to actually initiate a transfer against a hostile server.

Who can reach it

Network, outbound and requiring user or job interaction: an SCP transfer must be initiated from the libssh client to a server the attacker controls or has compromised. No credentials on the client host are needed.

What to do

Update libssh to 0.12.0 or 0.11.4, or apply your distribution's backport - Red Hat has shipped RHSA-2026:18160 and RHSA-2026:18683 for RHEL and OpenShift Container Platform 4. This is a shared-library package upgrade, so any long-running process linked against libssh must be restarted to pick it up; no reboot or node drain. Prefer sftp over the legacy scp protocol in automation where you can.

References