libssh2 (CVE-2026-55200): Critical Integer Overflow to Heap RCE in ssh2_transport_read() - Public PoC, No Patched Release Yet

A critical integer overflow in libssh2's transport layer can corrupt the heap and lead to remote code execution when a libssh2-based client connects to a malicious or compromised SSH server. Tracked as CVE-2026-55200 with a CVSS 4.0 score of 9.2 (Critical), the flaw affects every libssh2 release up to and including 1.11.1 — the current stable release. A proof-of-concept was published on June 29, 2026, by researcher Tristan Madani. No patched release tag exists yet; only an upstream commit. The danger is compounded because libssh2 is embedded in curl, Git, PHP, commercial backup agents, NAS appliances, and firmware updaters — many of which bundle it statically and will never be reached by OS package-manager updates.

CISA's exploitation rating is currently "none" and no in-the-wild exploitation has been reported, but the public PoC raises the pressure to remediate quickly.

What the Vulnerability Is

libssh2 is a C library that implements the SSH2 client protocol. It underlies outbound SSH connections made by curl (libssh2 transport backend), PHP's ssh2_* functions, Git's ssh:// transport on some platforms, and a wide range of backup and deployment tools.

The flaw lives in ssh2_transport_read() inside src/transport.c. When libssh2 reads an incoming SSH packet, it extracts a 32-bit packet_length field from the wire, then calculates how many additional bytes to allocate for the packet body. The problem: there is no upper bound check on packet_length. If a server sends 0xffffffff (or any value large enough to overflow 32-bit arithmetic when added to the 5-byte packet header constant), the resulting allocation size wraps around to a very small number. The library then calls malloc() with a truncated size but later writes the full, un-truncated packet body into that under-sized buffer — a classic heap buffer overflow.

CWE classification: CWE-680 (Integer Overflow to Buffer Overflow).

The immediate consequence is an out-of-bounds write on the heap. Depending on the allocator and platform, this can lead to:

• Remote code execution on the libssh2 client machine, controlled by the SSH server
• Process crash / denial of service as the minimum reliable impact

Because the vulnerable path is exercised when the client reads a server response, exploitation requires a malicious or attacker-controlled SSH server. Any scenario where a client connects to an untrusted host — SFTP ingestion pipelines, automatic backup jobs, CI/CD runners that git clone via SSH, webhook-triggered deployments — is in scope.

Related CVEs in the Same Batch

Two companion CVEs were published alongside CVE-2026-55200 during the same research disclosure:

All three affect the same version range (≤ 1.11.1) and are patched by the same upstream commit.

Timeline

Who Is Affected

Direct users of libssh2

Any application or service that links libssh2 and initiates outbound SSH/SFTP connections is potentially vulnerable. This includes:

• curl — when compiled with libssh2 as the SSH backend (common on Red Hat / CentOS lineages). curl sftp:// and curl scp:// requests trigger the vulnerable code path.
• PHP — the ext/ssh2 extension uses libssh2. PHP applications calling ssh2_connect(), ssh2_sftp_*(), or related functions are at risk.
• Git — on systems where Git's ssh:// transport is backed by libssh2 (varies by build configuration).
• Commercial backup agents — many backup products embed libssh2 for SFTP-based transfers to remote vaults.
• NAS firmware and appliances — vendors who statically link libssh2 in their firmware.
• CI/CD and deployment tooling — any runner that clones repositories or uploads artifacts over SSH.

The static-link problem

When libssh2 is bundled statically into a binary (common in appliances, containers shipped as base images, and commercial software), apt upgrade, yum update, or dnf update will not fix it. Each product must ship its own update. This is the same class of problem seen with statically linked OpenSSL in years past — OS patch compliance gives a false sense of security.

Run ldd <binary> | grep ssh2 to check for dynamic linking, and strings <binary> | grep -i "libssh" as a rough check for static embedding. Many backup agents and firmware packages will not appear in OS package databases at all.

Remediation

There is currently no patched release tag for libssh2. The fix is in upstream commit 97acf3d (PR #2052 on GitHub). Practical remediation steps in priority order:

1. OS-package managed libssh2: Watch your distribution's security feed for a backported patch. Debian and Ubuntu security teams are actively backporting commit 97acf3d. Red Hat / Rocky / AlmaLinux expect an advisory in the coming days. Apply the package update as soon as it lands.
2. Self-built or source-pinned libssh2: Build from the master branch at or after commit 97acf3d, or cherry-pick the commit onto your pinned version branch. Then rebuild all dependent services.
3. Static or bundled copies: Identify every application that ships its own libssh2. Check vendor advisory pages for curl, your PHP build provider, backup agents, and any appliance firmware. Do not assume OS patching covers these.
4. Network controls (short-term): Restrict outbound SSH/SFTP connections to a whitelist of trusted, known-good hosts. A connection to an untrusted SSH endpoint is required for exploitation; allowlisting significantly narrows the attack surface while patches are staged.
5. Verify host keys: Ensure libssh2-based clients have strict host key checking enabled. A valid, verified host key prevents a network MITM from delivering the malicious packet — though this does not protect against exploitation of an already-compromised SSH server.
6. Detection: Watch server-side SSH daemon logs and network captures for abnormally large packet headers or client-side crash signals (unexpected process termination from curl, PHP, or backup agents during SFTP operations).

Proof-of-Concept Status

The PoC published on June 29 is described as a local harness — it demonstrates heap corruption in a controlled test environment but does not provide a turnkey remote exploit or shellcode. CISA's exploitation rating remains "none" as of publication. However, the distance between a heap-overflow PoC and a weaponized exploit is shorter for memory-unsafe C libraries; treat the window between now and patched-release availability as elevated risk.

References

• The Hacker News (June 29, 2026): Public PoC Released for Critical libssh2 Vulnerability
• GBHackers (June 23, 2026): Critical libssh2 Vulnerability
• libssh2 upstream fix: Commit 97acf3d / PR #2052
• NHS England Digital Advisory CC-4799
• CWE-680: Integer Overflow to Buffer Overflow