Critical libssh2 Vulnerability Allows Remote Code Execution Through Malicious SSH Packets

A critical vulnerability in libssh2 can allow remote attackers to corrupt heap memory and potentially execute code by sending specially crafted SSH packets to vulnerable applications.

The flaw is tracked as CVE-2026-55200 and affects libssh2 through version 1.11.1. The issue sits in the SSH packet-reading logic and was fixed in a patch commit that adds new boundary checks for packet length handling.

The VulnCheck advisory rates the bug critical with a CVSS 4.0 score of 9.2. The vulnerability was credited to security researcher Tristan Madani.

What is libssh2?

libssh2 is an open-source library that implements the SSH2 protocol. Developers use it to add SSH, SFTP, and SCP support to applications, automation tools, file transfer products, embedded systems, and other software.

The libssh2 project describes the library as an SSH2 implementation released under the revised BSD license. Because it is a library rather than a standalone server, the real-world exposure depends on which applications bundle or link against vulnerable libssh2 versions.

This means administrators should not only check package managers. They should also look for products that statically link libssh2 or ship their own copy inside the application package.

Vulnerability detail	Information
CVE	CVE-2026-55200
Affected software	libssh2 through 1.11.1
Fixed in	Commit 97acf3dfda80c91c3a8c9f2372546301d4a1a7a8
Function affected	ssh2_transport_read()
Weakness type	CWE-680, Integer Overflow to Buffer Overflow
CVSS 4.0 score	9.2, critical

How CVE-2026-55200 works

The vulnerability is an out-of-bounds write in ssh2_transport_read(), a function used while libssh2 reads SSH transport packets. The problem comes from missing upper-bound validation on the packet_length field.

If an attacker can send an excessively large packet_length value, the vulnerable code can trigger an integer overflow and then write outside the intended heap buffer. The NVD entry says crafted SSH packets can corrupt heap memory and achieve remote code execution.

The official GitHub Advisory Database entry also describes the flaw as an out-of-bounds write caused by unchecked packet_length handling. It was published on June 17, 2026.

Why this vulnerability is serious

The bug has a network attack vector, requires no privileges, and does not require user interaction. That makes it a high-priority issue for software that processes SSH packets from untrusted or compromised hosts.

Successful exploitation could lead to application crashes, denial of service, memory corruption, or code execution in the context of the affected process. The exact impact depends on the application, operating system protections, compiler hardening, and how the software uses libssh2.

The CVE record says the flaw affects libssh2 through 1.11.1 and is fixed at the git commit level. It does not describe the issue as a flaw in OpenSSH.

• Applications using libssh2 through 1.11.1 should be reviewed.
• Products with bundled or statically linked libssh2 may need separate updates.
• Security teams should confirm whether vendors have backported the patch.
• Systems that connect to untrusted SSH endpoints deserve faster remediation.
• Network monitoring can help detect abnormal SSH packet behavior, but patching remains the primary fix.

The patch adds packet length boundary checks

The fix landed in a libssh2 patch commit titled “transport.c: Additional boundary checks for packet length.” The change adds an upper-bound check against LIBSSH2_PACKET_MAXPAYLOAD.

Before the patch, the code checked for packet lengths below 1 but did not enforce the same kind of upper limit before continuing with packet processing. The new logic returns an out-of-boundary error when the packet length exceeds the maximum allowed value.

The related GitHub security advisory links to the pull request, patch commit, NVD entry, and VulnCheck advisory, giving teams several references for tracking remediation.

Risk area	What to check	Why it matters
Operating system packages	Installed libssh2 package version and vendor advisory status	Linux distributions may backport the fix without changing the upstream version number
Bundled libraries	Applications shipping private libssh2 copies	Package-manager updates may not fix embedded copies
Static linking	Compiled binaries that include libssh2 code directly	The vulnerable code may remain even after system libraries are patched
Network exposure	Tools connecting to untrusted SSH servers or gateways	Exposure grows when SSH packets come from attacker-controlled systems

What organizations should do now

Organizations should identify all systems and applications that use libssh2 through 1.11.1. This includes developer tools, file-transfer services, backup products, deployment systems, CI/CD tools, network appliances, and embedded devices.

The safest response is to update to a vendor package that includes the CVE-2026-55200 fix or to rebuild against the patched upstream commit. The GitHub commit shows the exact boundary-checking change for teams that need to verify backports.

Where immediate patching is not possible, teams should reduce exposure by limiting which SSH endpoints vulnerable applications can contact, blocking untrusted SSH destinations, and monitoring for abnormal packet sizes or repeated crashes in software that uses libssh2.

Why bundled dependencies make patching harder

libssh2 may appear as a normal system package on servers, but many products include third-party libraries inside their own installers. That can leave vulnerable code in place even after administrators update the operating system package.

The libssh2 repository lists 1.11.1 as the latest GitHub release at the time checked, while vulnerability databases point to a specific patched commit. This makes vendor advisories and distribution backports especially important for remediation tracking.

Security teams should ask vendors whether their products use libssh2, which version they include, whether CVE-2026-55200 has been patched, and whether the fix came through an upstream update or a backported patch.

• Search software inventories and SBOMs for libssh2.
• Check Linux package status across servers, containers, and images.
• Scan application directories for bundled libssh2 libraries.
• Ask vendors about statically linked libssh2 usage.
• Rebuild internal applications against a patched libssh2 version or commit.
• Monitor crash logs for suspicious failures in SSH-handling components.

Not the same as OpenSSH

Admins should avoid confusing libssh2 with OpenSSH or libssh. These are separate projects. A scanner result for libssh2 does not automatically mean an OpenSSH server is vulnerable.

The vulnerable code exists in libssh2’s packet processing path. That makes the most important question whether a specific application uses libssh2 and whether it can receive or process malicious SSH packets in its normal operation.

The NVD vulnerability page and VulnCheck both describe the affected software as libssh2 through 1.11.1. That scope should guide incident response, patch planning, and vulnerability management.

FAQ