GPU VulnDB

Database/Kernel, userspace & hypervisor

libssh2: malicious SSH server can corrupt the heap of any client opening an SFTP session

CVSS 8.7CVE-2026-66032Kernel, userspace & hypervisorcurated

Impact

When a server answers SSH_FXP_OPEN with a FX_OK status, libssh2 frees the response buffer and can free the same pointer again on a following packet error, producing a tcache double-free on glibc that allows overlapping allocations and function-pointer overwrites. The exposure is client-side: anything on the fleet that fetches over SFTP with libssh2 - dataset sync jobs, backup agents, provisioning and config-management tooling, git transports - can be compromised by the server it talks to. On GPU nodes those clients often run as root or with fleet-wide credentials, so a hostile or hijacked file server becomes a path onto the node. Fixed in commit 5e47761; through 1.11.1 is affected.

Who can reach it

A malicious or compromised SSH/SFTP server that a client on your fleet connects to. The client must authenticate and open an SFTP session; no inbound reachability to your hosts is required.

What to do

Update the distro libssh2 package to a build containing commit 5e4776146552d898b9c0e1b313cd093fa8dc92d0 (no release past 1.11.1 is named in the record), then restart every daemon and agent linked against it - statically linked binaries need a rebuild. No node drain or reboot is implied. Until then, restrict which SFTP endpoints fleet tooling is allowed to reach.

References

Related entries

All Kernel, userspace & hypervisor entries

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.