A public proof-of-concept (PoC) exploit for the critical libssh2 remote code execution vulnerability tracked as CVE-2026-55200 is now available, significantly increasing the risk of real‑world attacks against unpatched systems.
The flaw affects libssh2 versions up to and including 1.11.1 and resides in the ssh2_transport_read() function, which parses incoming SSH packets on the client side.
The vulnerable code path fails to enforce an upper bound on the attacker‑controlled packet_length field before using it in an arithmetic expression that computes the allocation size for decrypted packets.
As documented in recent advisories, this unchecked packet length can cause a 32‑bit integer wrap, leading to an undersized heap allocation followed by out‑of‑bounds writes when subsequent code trusts the original large packet_length value.
PoC Released for libssh2 RCE Vulnerability.
Security researchers have now published a PoC under the “exploitarium” repository that turns this logic error into a practical exploitation framework.
The toolkit includes a C11 verifier that reproduces libssh2’s vulnerable arithmetic logic, demonstrating how a crafted packet_length value (e.g., 0xffffffff) can trigger a tiny memory allocation while the logical packet size remains extremely large.
This mismatch allows later packet processing stages to perform operations such as packet_length‑derived copies, effectively writing beyond the allocated buffer and corrupting adjacent heap structures.
Alongside the arithmetic probe, the PoC repository ships a minimal malicious SSH server implemented in Python that negotiates an encrypted SSH session and then delivers a malformed server‑to‑client packet with a decrypted packet_length designed to trigger the bug.
The server scaffold illustrates that a malicious or compromised SSH server, or a man‑in‑the‑middle positioned on the network path, can exploit vulnerable libssh2‑based clients without authentication or user interaction, aligning with the CVSS 9.2 rating assigned to CVE‑2026‑55200.
Because libssh2 underpins popular tooling such as curl, backup agents, firmware updaters, and embedded appliances, any component that links the library and connects to untrusted SSH endpoints becomes a potential RCE target.
To demonstrate end‑to‑end code execution, the exploitarium project also provides a controlled local RCE harness and exploit driver rather than a generic exploit for every libssh2 deployment.
The harness models the vulnerable allocation‑to‑control pattern and allows the exploit script to overflow from the undersized buffer into a callback pointer, ultimately writing a proof file to confirm successful control of program execution.
This design emphasizes that while the PoC confirms the feasibility of RCE, adapting it into a reliable exploit for real‑world services still depends on target‑specific factors such as binary layout, allocator behavior, available mitigations, and how the application embeds libssh2.
Upstream maintainers have addressed CVE‑2026‑55200 in commit 97acf3dfda80c91c3a8c9f2372546301d4a1a7a8, which introduces a strict guard rejecting packet_length values greater than LIBSSH2_PACKET_MAXPAYLOAD before performing the vulnerable arithmetic.
However, several distributions and downstream projects are still backporting or shipping patched builds, and no new libssh2 release containing the fix has been widely announced yet.
With a working PoC now available, organizations are urged to inventory any software statically or dynamically linked against libssh2, apply patches or backported fixes that include the referenced commit, and restrict connections to untrusted SSH servers while remediation is underway.
