threat-wire

Public Exploit Code Lands for Critical libssh2 SSH Client Flaw

A proof-of-concept is now public for CVE-2026-55200, a critical flaw in libssh2 that a malicious SSH server can use to corrupt memory on any client that connects to it. The library is bundled inside curl, Git, PHP, backup agents, and countless appliances, often statically linked so a normal update misses it. There is no fixed release yet.

By SecureBusinessHub Editorial, International cybersecurity desk — · 6 min read

libssh2 sits inside far more software than most teams realise, and a critical flaw in it now has working exploit code in public. CVE-2026-55200 needs no password and no clicks. A malicious or compromised SSH server can corrupt memory on whatever connects to it, with code execution on the table.

What the flaw does

The bug is in ssh2_transport_read(), the function that parses incoming SSH packets during the handshake. It reads the attacker-controlled packet_length field and rejects only values below 1. It never checks an upper bound. The size calculation adds packet_length to a couple of small values using 32-bit arithmetic, so a length of 0xffffffff wraps around to a tiny number. libssh2 then allocates a buffer for the tiny number while later code writes the full, oversized packet into it.

The result is an out-of-bounds write on the heap, classed as CWE-680: an integer overflow that becomes a buffer overflow, which is a classic route to remote code execution. It carries a CVSS 4.0 score of 9.2 and affects every release up to and including 1.11.1.

The direction of the attack is the part teams get wrong. libssh2 is a client library, not a server. The danger is not someone attacking your SSH server. It is one of your own tools reaching out to a hostile SSH endpoint and getting compromised on the way.

That matters because libssh2 hides in plain sight. It is embedded in curl, Git, PHP, backup agents, firmware updaters, and a long tail of appliances. Many of those copies are statically linked, so updating your distro package will not touch them, and you may not even know they are there.

Are you exposed?

  • Check the installed library version with libssh2_version or your package manager. Anything at or below 1.11.1 is vulnerable.
  • Run curl -V and look for libssh2 in the version line. Do the same for Git, PHP builds with the ssh2 extension, and any backup or managed file-transfer agent.
  • Hunt for statically linked copies: search application install folders and firmware images for a bundled libssh2, because an operating system update will never fix those.
  • List every client that connects out to SSH or SFTP endpoints you do not fully control, such as third-party Git hosts, vendor appliances, and managed transfer services. Those outbound connections are the exposure path.

There is no patched release yet

The fix is in mainline source through pull request #2052, merged on 12 June, and VulnCheck published the CVE on 17 June. No tagged release exists, so Linux distributions and downstream projects are backporting the patch themselves. Debian already has a repaired build in testing. NHS England Digital has issued its own advisory urging affected organisations to update.

Patch the rest of the batch while you are at it. CVE-2026-55199 (CVSS 8.2) is a denial of service that traps a connecting client in a CPU loop, and CVE-2025-15661 (CVSS 8.3) is an SFTP heap over-read.

What to do now

Track your distribution's libssh2 backport and apply it the moment it lands. Rebuild or update any statically linked application once a fixed version ships, since those will not move on their own. Until then, limit outbound SSH and SFTP from sensitive hosts to endpoints you trust, and treat connecting to an unknown SSH server as a real risk rather than a routine action.

This is not new ground for libssh2. In 2019 it shipped version 1.8.1 to fix CVE-2019-3855, a near-identical integer overflow in the same transport read that also let a malicious server run code on a connecting client. Seven years later the same class of bug is back in the same place.

The dangerous copies are the ones nobody remembers installing, baked into an appliance or a firmware image where no update will reach them.