CVE-2026-55200: 
NixOS Analyse et atténuation des vulnérabilités

CVE-2026-55200 is a critical out-of-bounds write vulnerability in libssh2's ssh2_transport_read() function that fails to enforce upper bounds on the packet_length field during SSH packet processing. It affects libssh2 through version 1.11.1 and was disclosed on June 17, 2026, with a fix merged on June 12, 2026 via commit 97acf3d. The vulnerability carries a CVSS v3.1 base score of 9.8 (Critical) and a CVSS v4.0 base score of 9.2 (Critical) (Github Advisory, Red Hat Bugzilla).

The root cause is classified as CWE-680 (Integer Overflow to Buffer Overflow). In the vulnerable code path within src/transport.c, the function reads a 32-bit packet_length from the SSH packet and only checks that it is not less than 1, without enforcing an upper bound against LIBSSH2_PACKET_MAXPAYLOAD. An attacker can send a crafted SSH packet with packet_length=0xffffffff; when this value is added to mac_len and auth_len in a 32-bit integer expression before being widened to size_t, integer wraparound occurs — for example, 0xffffffff + 0 + 16 wraps to 15, and 4 + 15 yields an allocation of only 19 bytes. Subsequent processing then uses the original oversized packet_length value to write into this undersized heap buffer, enabling heap corruption. The fix adds a guard if(p->packet_length > LIBSSH2_PACKET_MAXPAYLOAD) return LIBSSH2_ERROR_OUT_OF_BOUNDARY; before the vulnerable addition (libssh2 PR #2052, libssh2 commit, PoC repo).

Successful exploitation allows an unauthenticated remote attacker to corrupt heap memory and achieve remote code execution on any system or application using a vulnerable version of libssh2 (≤1.11.1). Because libssh2 is widely embedded in tools such as curl, git, and numerous SSH client applications, the attack surface is broad and affects confidentiality, integrity, and availability at the highest level. An attacker gaining code execution in the context of the libssh2-consuming process could pivot to further lateral movement, credential theft, or full system compromise (Github Advisory, Red Hat Bugzilla).

1. Reconnaissance: Identify systems or services using libssh2 ≤1.11.1 as an SSH client library (e.g., applications using curl with SSH support, git over SSH, or custom SSH clients). Tools like Shodan or Censys can help locate exposed SSH services; however, the attacker must operate as a malicious SSH server to exploit connecting clients.
2. Set up malicious SSH server: Deploy the trigger scaffold (libpwn_cve_2026_55200_server.py from the public PoC) on an attacker-controlled host. The server negotiates a standard SSH handshake using curve25519-sha256, RSA host key, and chacha20-poly1305@openssh.com.
3. Craft malicious packet: After key exchange, the malicious server sends an encrypted server-to-client SSH packet whose decrypted packet_length field is set to 0xffffffff.
4. Trigger integer overflow: When the vulnerable libssh2 client processes this packet in ssh2_transport_read(), the expression packet_length + mac_len + auth_len wraps around in 32-bit arithmetic (e.g., 0xffffffff + 0 + 16 = 15), causing only 19 bytes to be allocated on the heap.
5. Heap corruption: Subsequent packet processing writes data using the original oversized packet_length value into the undersized 19-byte allocation, corrupting adjacent heap memory.
6. Achieve RCE: By controlling heap layout (dependent on allocator behavior and target binary), an attacker can overwrite function pointers or other control-flow data to redirect execution, as demonstrated by the local RCE harness in the public PoC (PoC repo, libssh2 PR #2052).

• Network: Inbound SSH connections from unexpected or untrusted hosts to systems running libssh2-based clients; outbound SSH connections from servers to attacker-controlled hosts on non-standard ports (e.g., 2222); SSH handshakes that complete key exchange but send anomalously large or malformed packet_length values in subsequent packets.
• Process: Unexpected child processes spawned by applications using libssh2 (e.g., curl, git, custom SSH clients) such as shells (/bin/bash, cmd.exe) or network utilities (wget, curl, nc); crashes or segmentation faults in libssh2-linked processes with heap corruption signatures in core dumps.
• Logs: Application or system logs showing SSH connection errors referencing LIBSSH2_ERROR_OUT_OF_BOUNDARY or LIBSSH2_ERROR_DECRYPT in patched versions; crash reports or core dumps from libssh2-consuming applications with heap corruption stack traces involving ssh2_transport_read().
• File System: Unexpected files created by libssh2-consuming processes (e.g., proof files, web shells, or persistence mechanisms); new cron jobs or scheduled tasks created under the service account of the affected application.

The vulnerability is fixed in libssh2 commit 97acf3dfda80c91c3a8c9f2372546301d4a1a7a8 (merged June 12, 2026), which adds an upper-bound check on packet_length against LIBSSH2_PACKET_MAXPAYLOAD before the vulnerable integer addition (libssh2 commit, libssh2 PR #2052). Downstream distributions including Debian, Alpine, openSUSE, and others have begun releasing updated packages. As a workaround where patching is not immediately possible, restrict SSH client connections to trusted, known-good SSH servers and block outbound SSH to untrusted hosts at the network perimeter. Monitor for anomalous SSH connection attempts and application crashes consistent with heap corruption.

Heise Online covered the vulnerability with an article titled "Security vulnerabilities endanger connections via libssh2," noting the broad impact given libssh2's use in curl and other widely deployed tools (Heise). Security researcher Harry Sintonen and others discussed the vulnerability on Mastodon/infosec.exchange, and the Yocto Project security mailing list flagged it for embedded Linux users. The oss-security mailing list saw multiple threads (oss-sec/2026/q2/1010, 1011, 1014, 1017) discussing the vulnerability and PoC release. The Hong Kong Government CERT (GovCERT.HK) issued an alert, and the openSUSE security announce list published a patch advisory. Community discussion on the Manjaro forum included questions about removing SSH entirely, reflecting user concern about the broad attack surface.