SURIQ
Every guide to securing SSH points the same way: lock down the server. Use keys instead of passwords, rate-limit logins, disable root. A newly disclosed flaw in libssh2, the library that programs link against to act as an SSH client, turns that advice inside out. Tracked as CVE-2026-55200, it lets a malicious or compromised server corrupt memory on whatever connects to it, before any login and with no user interaction. The side that opened the connection is the side that gets taken over.
The risk now runs the other way down an SSH connection
An SSH session has two ends, and almost all the hardening we do lives on the server end. This bug sits on the client end. libssh2 is not a server daemon; it is what software embeds to be an SSH client, so the exposure belongs to anything that reaches out: git pulling over SSH, curl, backup agents, firmware updaters, and monitoring tools that log into devices. The flaw carries a CVSS score of 9.2 on the newer 4.0 scale, and researcher Tristan Madani reported it. A malicious server gets to run its attack during the first packets of the handshake, before your client has authenticated anything.
This is the same shape as a class of bugs we keep seeing: the thing you fetch attacks the thing that fetched it. A video your server decodes on its own can run attacker code, and now an SSH server you connect to can corrupt your client. Initiating the connection has never made the initiator safe, and outbound SSH is one more place that assumption breaks.
What goes wrong during the handshake
The defect is an integer overflow that becomes a heap write past the end of a buffer, cataloged as CWE-680. During the opening exchange, libssh2 reads a length field off the wire that the remote side fully controls, inside the function ssh2_transport_read() in transport.c. The code refused a length below one but set no ceiling on how large the value could be. Hand it a number close to the 32-bit maximum and the size arithmetic wraps around, so the library reserves a tiny buffer, as small as 19 bytes in the public analysis, then tries to write the full oversized packet into it. Memory next to that buffer gets overwritten, and it happens pre-authentication.
A proof-of-concept is public, archived in a repository called exploitarium, but it is a locally run trigger script rather than a finished remote exploit. There is no confirmed exploitation in the wild yet, and CISA's catalog still lists the flaw as not known to be exploited. That is the window defenders have, and the dates show how narrow it already is.
Where libssh2 is hiding in your stack
libssh2 is embedded far more widely than most teams track. It ships inside git and curl builds, PHP, language bindings, backup tooling, device firmware, and a long list of network appliances. Many of those copies are compiled in statically, which matters for the fix.
The real blast radius is not an engineer typing ssh to a server they trust. It is automation that connects out to endpoints someone else can influence: continuous-integration runners cloning repositories over SSH, backup jobs pulling from remote hosts, device-management systems that log into gear in the field, and anything that follows a URL or hostname an attacker can redirect. A malicious or man-in-the-middled server on the far end of one of those connections is exactly the precondition this flaw needs. Treat outbound SSH from unattended systems as the exposure, not interactive admin sessions.
Inventory the copies before you patch one
The fix exists, but not yet as something you can install with a version bump. It landed as a mainline source commit, 97acf3d, merged through pull request #2052 on June 12, and there is no tagged libssh2 release carrying it. Distributions are backporting the patch into their own packages. So "update libssh2 to the latest version" is not actionable advice today. Watch your distribution's security tracker and apply the patched package the moment it lands.
A package update will also miss every statically linked copy buried inside other software. That is where a software bill of materials earns its place: scan your builds and images for libssh2, and rebuild anything that bundles its own copy once a patched version is available. This is a find-and-fix job across dependencies, the same discipline as tracking down every host running a vulnerable libslirp rather than trusting one apt command. The other lever is reachability: where you can, restrict which hosts your automation is allowed to open SSH to, so a poisoned endpoint never gets to speak to a vulnerable client in the first place. CVSS 9.2 puts this near the top of the queue, alongside the other critical-rated flaws that need triage this week, and the cost of waiting is the same lesson unpatched edge devices keep teaching.