CVE-2026-55200: Public Exploit for a Critical libssh2 Flaw Affecting curl, Git and PHP With No Official Patch Released Yet
Eric Serrano Bustos
On 29 June 2026, a proof-of-concept was published on GitHub for CVE-2026-55200 (CVSS 9.2), a critical memory corruption vulnerability in libssh2, the SSH client library embedded in hundreds of tools and devices. The flaw allows a malicious or compromised SSH server to trigger a heap overflow on any client connecting to it, without valid credentials or additional user interaction. The attack direction is the one least typically monitored: it is not the server at risk, it is the client connecting to an untrusted SSH server. libssh2 is embedded in curl, Git, PHP, backup agents, firmware updaters and a long list of embedded devices. Many of those copies are statically linked, meaning a distribution package update does not fix them, and in many cases the team maintaining the tool does not even remember it embeds libssh2 internally. The fix is already merged into the project’s main repository, but as of this article’s publication no tagged official release exists yet, forcing distributions and dependent projects to apply the patch independently before the official package arrives.
What do we know about CVE-2026-55200?
Facts documented by The Hacker News, VulnCheck, OpenCVE, CyberSIXT and PurpleOps:
Vulnerability: integer overflow to buffer overflow (CWE-680) in the ssh2_transport_read() function in transport.c, the function that parses incoming SSH packets during the handshake. The packet_length field is not properly validated before being used in 32-bit arithmetic operations.
Technical mechanism: when an attacker sends a packet_length value of 0xffffffff, the 32-bit arithmetic operation calculating the buffer size wraps around and produces a very small number. libssh2 then allocates a buffer sized for that tiny, incorrect number, but subsequent code writes the full, much larger packet into that undersized buffer. The result is an out-of-bounds heap write, the classic pattern enabling arbitrary code execution.
CVSS 9.2: no authentication required, no additional user interaction after the SSH connection starts, network attack vector.
Affected versions: all libssh2 versions up to and including 1.11.1. The fix was merged into the main repository on 12 June via pull request #2052, but the project has not yet published a tagged release containing it.
Scope of the affected ecosystem: libssh2 is embedded in curl, Git, PHP, backup agents, firmware updaters and a long list of embedded network devices. Any application linking the library and connecting to a not-fully-trusted SSH endpoint is a potential target.
The PoC is partial, not a ready-to-use exploit: the code published on GitHub contains a locally verified SSH trigger scaffold and a controlled local RCE harness, not a turnkey remote exploit. Achieving reliable code execution against a real application depends on the target binary, allocator behaviour, system mitigations and how that specific application embeds libssh2.
No confirmed active exploitation: as of publication, CISA’s exploitation rating for this CVE remains marked as none, and no in-the-wild use has been reported. However, the public availability of a working exploit significantly lowers the technical barrier.
Direct precedent in the same library: in 2019, libssh2 released version 1.8.1 to fix a batch of nine flaws led by CVE-2019-3855, a near-identical integer overflow in the same transport read function, which also allowed a malicious server to execute code on a connecting client. Seven years later, the same class of bug reappears in the same code.
Second related vulnerability: the same disclosure also published CVE-2026-55199 (CVSS 8.2), a denial-of-service flaw in the same connection phase (the pre-authentication key exchange), where the server can advertise an anomalous list of supported extensions.
Why a flaw in the SSH client is more dangerous than it looks
Most security teams focus their attention on protecting internet-facing SSH servers. CVE-2026-55200 reverses that logic and exposes a common blind spot in risk management:
The attacker does not need to compromise the victim organisation’s perimeter: they need to control an SSH server the client connects to. This includes third-party servers, external Git repositories, cloud deployment services, providers offering SSH access, or any legitimate SSH server previously compromised by another actor. Any workflow connecting internal tools to SSH servers outside the organisation’s direct control is a potential attack surface.
libssh2 is present in places security teams do not typically inventory. Unlike an application with its own CVE that clearly shows up in dependency scanners, libssh2 is usually statically linked inside other tools: backup agents, firmware updaters, automation scripts, network devices. The team operating those tools often does not know libssh2 is inside.
Static linking breaks the usual package-manager patching model. When a Linux distribution updates its libssh2 package, statically linked copies inside other binaries do not update automatically. Each tool that bundles its own copy of libssh2 requires its own independent update cycle.
The same failure pattern already caused problems seven years ago. The fact that the same vulnerability class reappears in the same code function seven years after CVE-2019-3855 suggests the original fix did not include structural protection against this class of error, only the specific case detected at the time.
How the CVE-2026-55200 exploitation chain works
The client with vulnerable libssh2 initiates an SSH connection to an attacker-controlled server. This can happen routinely: a deployment script connecting to an external Git repository, a backup agent syncing with a remote server, or any tool using SSH for file transfer or remote execution.
The malicious server sends an SSH packet with a manipulated packet_length value, typically 0xffffffff. This occurs during the handshake or in subsequent communications such as SSH_MSG_CHANNEL_DATA messages.
The client library calculates the buffer size using 32-bit arithmetic without validating the upper bound. The manipulated value triggers an integer overflow producing an incorrectly small allocation size.
Subsequent code writes the full, much larger actual packet into the undersized buffer. This overwrites adjacent memory regions with attacker-controlled data.
The overwritten memory can contain attacker-controlled code that executes in the context of the client process, delivering arbitrary code execution on the system that initiated the SSH connection.
Key lessons and mitigation checklist
Step 1 - Inventory where libssh2 is (the hardest part):
Identify internal tools and applications using libssh2, not just via the operating system package manager but by reviewing application dependencies, backup agents, automation tools and network devices.
Pay particular attention to binaries statically linking libssh2: these do not update with a simple apt upgrade or equivalent.
Specifically review curl, Git and PHP, the three most widely deployed tools that embed the library.
Step 2 - Apply the available patch while waiting for the official release:
The patch is available in commit 97acf3dfda80c91c3a8c9f2372546301d4a1a7a8 of the libssh2 main repository. Debian already has a repaired build in testing.
Organisations that cannot wait for the tagged official release should evaluate applying the patch backport directly or following the example of distributions already doing so.
Step 3 - Restrict outbound SSH connections to untrusted servers (mitigation while patching):
Block or severely limit SSH connections from client systems to external or untrusted SSH servers.
Implement strict network access policies that segment access based on device posture and user identity, particularly for automation and CI/CD tools connecting to external repositories or services via SSH.
Step 4 - Monitor anomalous outbound connections:
Watch for unusual outbound SSH connections from client machines after establishing SSH sessions with unfamiliar destinations.
Review application logs using SSH for anomalous packet sizes or repeated connection attempts to unknown endpoints.
Cybersecurity as a strategic priority
CVE-2026-55200 illustrates a structural problem in the open-source software supply chain: a critical low-level library, statically linked into hundreds of tools, with a failure pattern that already caused problems seven years ago and now reappears with a public exploit before an official fixed release exists. The challenge is not purely technical, it is one of visibility: most organisations do not have an accurate inventory of where libssh2 sits within their software stack. For security and development teams, today’s question is direct: do you know which of your organisation’s tools connect via SSH to servers outside your direct control, and how many of them have libssh2 statically linked without anyone remembering it?
Apolo Cybersecurity: dependency inventory and CVE-2026-55200 mitigation
At Apolo Cybersecurity we help organisations assess their exposure to supply chain vulnerabilities like CVE-2026-55200: inventory of tools and devices embedding libssh2, identification of statically linked binaries that do not update via package manager, patch and network mitigation application while no official release exists, and review of outbound SSH connection policies to external servers.
If your organisation uses curl, Git, backup agents or automation tools that connect via SSH to servers outside your direct control, now is the time to verify whether libssh2 is among your dependencies.
%402x.svg){kind=icon}
