PoC Exploit Released for Critical libssh2 Remote Code Execution Vulnerability

A public proof-of-concept exploit is now available for CVE-2026-55200, a critical remote code execution vulnerability in libssh2. The flaw affects libssh2 through version 1.11.1 and sits in the SSH packet parsing path used by libssh2-based clients.

The NVD entry for CVE-2026-55200 says remote attackers can send crafted SSH packets with oversized packet_length values to corrupt heap memory and achieve remote code execution. VulnCheck rates the flaw as critical with a CVSS v4 score of 9.2.

The release of a working research PoC increases the urgency for organizations that use software linked against libssh2. The risk is highest for tools that connect to untrusted SSH servers, including automation tools, backup clients, firmware updaters, embedded products and applications that use SSH or SFTP features through libssh2.

What CVE-2026-55200 is

libssh2 is a client-side C library that implements the SSH2 protocol. The libssh2 project describes support for authentication, channels, SFTP, non-blocking use and several crypto backends, which explains why the library appears in many products and operating system packages.

The vulnerability exists in ssh2_transport_read(), a function that processes incoming SSH transport packets. The vulnerable path fails to reject packet_length values that exceed libssh2’s maximum packet payload size before using that value in later arithmetic.

The GitHub Advisory Database says libssh2 through 1.11.1 contains an out-of-bounds write vulnerability because the code fails to enforce upper bounds on the attacker-controlled packet_length field.

Item	Details
CVE	CVE-2026-55200
Affected product	libssh2
Affected versions	Through 1.11.1
Vulnerability type	Integer overflow to buffer overflow
CVSS v4 score	9.2, critical
Exploit status	Public PoC available
Fix status	Fixed upstream in commit 97acf3df, with vendor backports expected or in progress

Why the bug can lead to code execution

The issue starts with how libssh2 handles the SSH packet_length value. In the vulnerable path, an attacker-controlled length can cause integer wraparound during allocation size calculation.

That can make libssh2 allocate a much smaller buffer than the later packet-processing logic expects. When the original larger packet length is then trusted again, the library can write beyond the allocated heap buffer and corrupt nearby memory.

The upstream patch commit adds an explicit check that rejects packet_length values greater than LIBSSH2_PACKET_MAXPAYLOAD before the dangerous arithmetic occurs.

• The flaw affects the client-side SSH packet parsing path.
• A malicious or compromised SSH server can send the crafted packet.
• An attacker does not need valid credentials for the target client.
• No user interaction is required once the vulnerable client connects.
• Reliable real-world exploitation can still depend on memory layout, mitigations and how an application embeds libssh2.

Public PoC makes patching more urgent

The public exploitarium PoC repository contains local research artifacts for CVE-2026-55200. It includes an arithmetic verifier, an encrypted SSH trigger scaffold and a controlled local RCE harness.

The repository presents the work as a local research and lab scaffold, not as a universal exploit for every libssh2 deployment. That distinction matters because real-world exploit reliability can vary by target program, allocator behavior, architecture, compiler settings and runtime protections.

Still, defenders should not downplay the risk. The VulnCheck advisory describes the vulnerability as a network-exploitable out-of-bounds write that can allow remote code execution.

Who may be exposed

The most obvious exposure is any application that links libssh2 and connects to SSH servers controlled by outside parties. This can include SFTP clients, deployment tools, Git-related tools, backup agents, network management software and automated update systems.

Embedded systems and appliances may create additional risk because libssh2 can be bundled inside firmware and may not appear as a standalone package in normal software inventories. Static linking can also hide exposure from package-based scanners.

The NHS Digital alert warns that successful exploitation could allow unauthenticated attackers to achieve remote code execution through crafted SSH packets and recommends reviewing the libssh2 advisory and applying relevant updates.

Environment	Why it may be affected	Priority
Linux and Unix packages	libssh2 may be installed as a shared library for SSH/SFTP features	Check vendor security updates
Embedded devices	Firmware may bundle libssh2 internally	Check vendor firmware advisories
Backup and sync agents	Agents may connect to SSH or SFTP endpoints automatically	Patch and restrict server trust
Developer tools	Some tools may use libssh2 for SSH transport	Update packages and dependencies
Static builds	libssh2 may be compiled into an application binary	Use SBOM and binary inventory checks

Patch status and fixed code

The vulnerability was fixed upstream in libssh2 commit 97acf3df. The GitHub commit is titled “transport.c: Additional boundary checks for packet length” and adds a packet-length guard to prevent the out-of-bounds write condition.

The GitHub advisory lists the issue as critical and references the upstream fix. However, organizations should not assume that every distribution or downstream vendor has already shipped a package containing that patch.

The official libssh2 website still lists libssh2 1.11.1 as the latest downloadable release. That means teams should rely on vendor packages, backported fixes, or source builds that include the upstream patch while waiting for broader release alignment.

How organizations should respond

Security teams should start with inventory. Search for libssh2 in system packages, application dependencies, containers, firmware, vendor appliances and statically linked binaries. A normal package scan may miss products that bundle the library internally.

After identifying exposure, apply vendor updates or builds that include the upstream fix. If no update is available, reduce risk by preventing libssh2-based clients from connecting to untrusted SSH servers and by limiting where those clients can run.

The NVD record also shows CISA updated its SSVC status to reflect public PoC availability. The NHS advisory gives similar remediation guidance, urging affected organizations to apply relevant updates as soon as possible.

• Inventory all software that uses libssh2, including bundled and static copies.
• Apply vendor patches or rebuild with the upstream fix.
• Prioritize clients that connect to external or untrusted SSH servers.
• Restrict outbound SSH and SFTP traffic where business workflows allow it.
• Monitor for unexpected client connections to unknown SSH servers.
• Check containers and appliances, not only general-purpose servers.
• Ask vendors whether their products include libssh2 and whether they include commit 97acf3df or an equivalent backport.

What defenders should watch for

Detecting exploitation can be difficult because the vulnerable component runs inside client applications that initiate outbound SSH connections. Logs may show only that a client connected to a server, while memory corruption happens inside the application process.

Useful signals include crashes in libssh2-linked clients, unusual outbound SSH connections, unexpected SFTP destinations, repeated failed automation jobs, and endpoint detections tied to heap corruption or abnormal child processes after SSH activity.

The public PoC repository shows why the bug deserves attention, but it also notes that a reliable exploit depends on the target binary and runtime conditions. Defenders should treat the PoC as a patching accelerator rather than proof that every deployment is equally exploitable.

FAQ