A critical remote code execution vulnerability in libssh2 — the widely embedded C library behind curl, firmware updaters, backup agents, and countless IoT devices — now has a public proof-of-concept exploit circulating on GitHub. The flaw, CVE-2026-55200 (CVSS 9.2), requires no authentication and can be triggered by any SSH server a vulnerable client connects to, including via a machine-in-the-middle position.
What Happened
Security researcher Tristan Madani (@TristanInSec) disclosed the vulnerability on June 17, 2026, along with a companion integer-exhaustion bug, CVE-2026-55199 (CVSS 8.2). A public PoC server (libpwn_cve_2026_55200_server.py) was subsequently published to the bikini/exploitarium GitHub repository, lowering the bar for exploitation significantly.
Technical Root Cause
The vulnerability lives in ssh2_transport_read() inside transport.c. When a remote SSH server returns a packet, libssh2 reads the 32-bit packet_length field directly from the wire without bounds-checking it before using it in heap allocation arithmetic.
An attacker can pass packet_length = 0xffffffff. Due to 32-bit integer wrap, the resulting allocation is only 19 bytes — far smaller than what the rest of the code expects. When libssh2 then trusts the original large packet_length value and copies data into this undersized buffer, an out-of-bounds heap write occurs, which is reliably exploitable for code execution.
The PoC specifically crafts a malicious chacha20-poly1305 packet that triggers this path.
Companion Bug: CPU Exhaustion (CVE-2026-55199)
CVE-2026-55199 is a separate but related issue: a malicious server can send a crafted extension count during SSH key exchange, trapping the client in a tight busy loop for 60 seconds or more. This can be used to deny service or mask exploitation attempts.
Affected Scope
All libssh2 releases through 1.11.1 are vulnerable. Because libssh2 is commonly statically linked, standard package manager scans may not surface all affected copies — applications that bundle their own libssh2 build need to be audited independently.
Known consumers of libssh2 include:
curlandlibcurl(when built with SSH support)- PHP's
ssh2extension - Ruby's
net-ssh-multi - Embedded firmware update agents on routers, NAS devices, and IoT hardware
- Backup and sync tools (rsync wrappers, rclone, Duplicati, etc.)
Mitigation
No new versioned release of libssh2 has shipped yet. Fixes are available as upstream commits:
- CVE-2026-55200: commit
97acf3d - CVE-2026-55199: commit
1762685
Organizations should:
- Patch from source by applying both commits to any vendored or statically linked libssh2 copy.
- Audit container images and firmware for static libssh2 builds that won't be caught by OS-level package scanners.
- Block outbound SSH to untrusted hosts where possible until patched — the attack requires a controlled or MitM SSH server, so restricting which servers clients can reach reduces exposure.
- Monitor for CVE-2026-55199 symptoms: client processes pegging a CPU core for 60+ seconds during SSH handshakes.
Why This Matters
Client-side SSH vulnerabilities are historically underappreciated because most attention goes to SSH server hardening. But libssh2 clients are everywhere in automation pipelines, backup software, and embedded devices — and many of these connect to external or third-party hosts over which defenders have limited control. A public PoC means exploitation is now within reach of moderately skilled threat actors, and patching timelines for static-linked firmware can stretch into months or years.