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

CVSS 6.3CVE-2026-0964Kernel, userspace & hypervisorcurated

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

https://nvd.nist.gov/vuln/detail/CVE-2026-0964 https://www.libssh.org/2026/02/10/libssh-0-12-0-and-0-11-4-security-releases/https://access.redhat.com/security/cve/CVE-2026-0964 https://access.redhat.com/errata/RHSA-2026:18160

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.