A critical security flaw in libssh2 — the SSH library silently embedded in curl, backup utilities, and IoT firmware worldwide — lets unauthenticated remote attackers execute arbitrary code by sending specially crafted SSH packets, with zero prerequisites on the attacker's side.
Tracked as CVE-2026-55200 and carrying a CVSS score of 9.2, the vulnerability affects libssh2 versions 1.11.1 and earlier.
It was responsibly disclosed by security researcher Tristan Madani and fixed in commit 97acf3d via Pull Request #2052 on the project's GitHub repository. However, no official new libssh2 version has been released yet — Linux distributions and downstream projects are scrambling to backport the fix themselves.
The Bug: 4.3 Billion Minus a Bad Check
The flaw exists in the ssh2_transport_read() function within transport.c. The function fails to enforce proper upper limits on the incoming SSH packet_length field, enabling malicious actors to supply excessively large values that exceed allocated memory boundaries.
What makes this particularly sharp is the way integer overflows are handled. A packet_length value of 0xffffffff (roughly 4.3 billion), combined with specific MAC and authentication lengths, causes the arithmetic to wrap around modulo 2³², producing an allocation of just 19 bytes — while the original outsized value lives on in subsequent processing.
The library then writes well past those 19 bytes, corrupting adjacent heap memory. The upstream fix adds a single guard: reject any packet_length exceeding LIBSSH2_PACKET_MAXPAYLOAD before the arithmetic even runs. The vulnerability is classified as CWE-680 — Integer Overflow to Buffer Overflow.
The CVSS v4 vector reflects low attack complexity and no user interaction, making exploitation straightforward, especially in environments where libssh2 is integrated into automated services, embedded systems, or backend infrastructures that handle SSH communications.
A proof-of-concept has already been developed and locally verified, including an arithmetic verifier, a malicious SSH trigger scaffold, and a controlled RCE harness, lowering the practical bar for exploitation.
Why This Reaches Far Beyond One Library
Security researchers have noted that libssh2 is commonly embedded in various tools, including file transfer utilities, automation frameworks, and custom SSH clients. This broad usage increases the potential attack surface, particularly in enterprise environments where the library may be statically linked and not easily identifiable through standard package management tools. Updating your distro's package alone will not cover those.
The same disclosure also surfaces a second flaw. CVE-2026-55199, rated 8.2 (High), allows a malicious SSH server to cause client CPU exhaustion by sending a crafted extension count value during the initial key exchange — trapping the connecting client in a tight CPU loop for over 60 seconds. Automated deployment pipelines, monitoring agents, and backup jobs that connect over SSH are particularly exposed.
What to Do Now
- Apply commit 97acf3d (CVE-2026-55200) and commit 1762685 (CVE-2026-55199) from the libssh2 GitHub repository.
- Audit dependencies for statically linked or bundled libssh2 copies — these are invisible to standard package managers.
- Restrict SSH service exposure to trusted IP ranges using firewall rules.
- Monitor SSH logs for anomalous packet sizes or unexpected application crashes that may indicate active scanning or exploitation.
- Check your Linux distribution's or vendor's security advisory channel for backport status.
VulnCheck stated that CVE-2026-55200 represents a significant risk to any system or application built on libssh2 ≤1.11.1, and given the zero-authentication requirement and network accessibility, threat actors could quickly weaponize this flaw.