A working proof-of-concept exploit landed on June 29 for CVE-2026-55200, a CVSS 4.0 score of 9.2 heap overflow in libssh2 that gives a malicious or compromised SSH server the ability to corrupt memory on any client connecting through the library. No credentials, no user interaction, no warning — the vulnerability fires during the SSH handshake before any authentication takes place.

libssh2 is not a niche library. curl links it. Git links it. PHP’s SSH2 extension links it. Backup agents, firmware updaters, SFTP clients, and dozens of enterprise appliances carry it statically compiled or bundled in a vendor-frozen version that will not self-update. The fix is in libssh2 1.12.0. The problem is finding every copy.

What the bug is

The flaw lives in ssh2_transport_read() in transport.c — the function that parses incoming SSH packets during the handshake. The packet_length field in each incoming SSH packet is read from the wire and used as-is when computing how many bytes to copy into the receive buffer. There is no upper-bound check. A server-controlled packet_length large enough to trigger an integer overflow on the size arithmetic produces an out-of-bounds heap write in the client’s buffer.

The specific trigger path demonstrated in the public PoC uses a crafted SSH_MSG_CHANNEL_DATA message. Once the attacker controls packet_length, they write an attacker-supplied byte sequence past the end of the allocated heap region. On targets without ASLR, or where the heap layout can be shaped, that write becomes arbitrary code execution in the process that called libssh2. On hardened targets the realistic outcome is a segfault and process crash.

A companion flaw, CVE-2026-55199, was fixed in the same libssh2 1.12.0 release. Full details are not yet public, but it affects the same transport-layer parsing code.

Affected versions

Every libssh2 release through 1.11.1 is vulnerable. The fix landed in libssh2 1.12.0 via commits 97acf3d (CVE-2026-55200) and 1762685 (CVE-2026-55199), which add proper bounds checks on packet_length before the copy.

If you are running a distribution package, query what version your vendor actually shipped. Distros that backport security fixes without incrementing the upstream version number will show 1.11.1 in the package name even after patching. Check the changelog or advisory from your distro rather than trusting the version string alone.

Container images built from debian:bookworm-slim, ubuntu:24.04, or similar bases pull in libssh2 as an indirect dependency through curl. Rebuild and push any image that bundles curl or git once your distro ships a patched libssh2.

Why the attack surface is large

The client-side attack model is the part that makes this sting. The more commonly exploited direction for SSH vulnerabilities is server-side — a client sends a malicious handshake to a server. Here the vector is reversed: a server sends a malicious handshake to a client. That means any process using libssh2 to initiate a connection to an SSH, SFTP, or SCP server is in scope.

Practically speaking:

  • curl: whenever curl handles an sftp:// or scp:// URL on a system where it was built with libssh2 (this is common on enterprise Linux and embedded appliances; curl built with libssh instead is unaffected). Any automation that pulls files from SFTP endpoints runs libssh2.
  • Git: when GIT_SSH_COMMAND is not set and git falls back to its bundled SSH transport, some distributions link it through libssh2.
  • PHP: the ssh2_connect() function from the PECL SSH2 extension calls libssh2 directly. Any PHP application that SSH-connects to another host — common in web hosting control panels and backup scripts — is a potential victim.
  • Backup and monitoring agents: many vendor-supplied agents use libssh2 to ship data to collection servers. If the collection server is compromised, the library flaw turns it into a lateral-movement primitive.
  • Network appliances: firmware images that include libssh2 statically compiled are unlikely to receive automated updates. Version 1.11.1 was the current release for the past several months; any appliance firmware frozen in that window carries the flaw.

The PoC published in the “exploitarium” GitHub archive contains a locally verified crash scaffold and a controlled local RCE harness. It is not a turnkey remote exploit, but it proves the memory corruption is reachable and reproducible. Weaponization from a verified crash harness to a reliable remote exploit is measured in days, not weeks, once a PoC of this quality is public.

Mitigation

Patch immediately: upgrade libssh2 to 1.12.0 or to the backported patched package your distribution provides. This is the only complete fix.

If immediate patching is not possible:

  • Block or restrict outbound SSH/SFTP/SCP connections from sensitive systems to only known-trusted endpoints, using host-based firewall rules or network egress controls. The vulnerability requires a client to connect to a malicious server; restricting which SSH servers your systems can reach limits the blast radius.
  • Audit for statically compiled copies of libssh2 in vendor appliances, container images, and CI toolchains. ldd on a binary will show dynamic linkage; static copies require scanning with a tool like Syft or Grype that reads binary patterns. CloudLinux maintains alt-libssh2 packages for CloudLinux 7/8/9 that include the patch.
  • If you operate PHP-based hosting infrastructure, disable or isolate the SSH2 PECL extension until patched packages are available.

For detection, watch for unexpected crashes (SIGSEGV, SIGABRT) in processes known to use libssh2 — curl, git, backup agents — particularly after they make outbound SSH connections. A process that crashes mid-connection to a remote SFTP endpoint should be treated as a potential exploitation attempt until ruled out.

References