Critical libssh2 Vulnerabilities Let Malicious SSH Servers Corrupt Client Memory
Key Takeaways Four high-severity vulnerabilities in the widely used libssh2 library have been disclosed. These flaws enable malicious SSH servers to corrupt client memory, trigger crashes, and...
Key Takeaways
- Four high-severity vulnerabilities in the widely used libssh2 library have been disclosed.
- These flaws enable malicious SSH servers to corrupt client memory, trigger crashes, and potentially execute arbitrary code.
- Affected versions include libssh2 1.11.1 and earlier.
- Patches are available via individual upstream commits, and users are urged to update to a patched version.
Multiple critical vulnerabilities discovered in libssh2, a foundational C library for the SSH2 protocol, could expose client applications to severe risks. These include memory corruption, application crashes, and the potential for remote code execution when connecting to a compromised or malicious SSH server.
Table Of Content
libssh2 is integral to countless applications, facilitating secure remote administration, file transfers, automated deployments, backup solutions, and SFTP client operations across various platforms.
On July 24, 2026, a total of four vulnerabilities impacting libssh2 versions 1.11.1 and earlier were publicly disclosed. Each of these security flaws has been addressed through separate commits in the upstream project repository.
libssh2 Vulnerabilities
Critical Double-Free in SFTP (CVE-2026-66032)
The most severe of the disclosed issues is a double-free vulnerability, tracked as CVE-2026-66032. This flaw, rated with a CVSS score of 8.7, resides in the sftp_open() function within src/sftp.c and is categorized as CWE-415 (Double Free).
This vulnerability activates after a client successfully authenticates and initiates an SFTP session. A malicious SSH server can then send a specially crafted success status in response to an SSH_FXP_OPEN request. Under specific error conditions, libssh2 erroneously attempts to free the same response-data buffer twice.
For systems utilizing the glibc heap allocator, this can result in tcache duplication and overlapping memory allocations. An attacker could leverage this to corrupt application memory, potentially overwriting critical function pointers. The fix for this critical issue is implemented in commit 5e47761.
Integer Underflow Leading to DoS (CVE-2026-66033)
The second vulnerability, identified as CVE-2026-66033, carries a CVSS score of 8.7 and affects the ssh2_cipher_crypt() function in src/openssl.c. This pre-authentication flaw involves an integer underflow and subsequent out-of-bounds read.
During the initial SSH handshake, a malicious server can negotiate AES-GCM encryption, triggering an underflow in the packet size calculation. This leads to an out-of-bounds read and an invocation of memcpy() with an excessively large size value, causing an immediate client crash before authentication can complete. Commit a2ed82d provides the patch for this vulnerability.
Additional Memory Corruption Flaws
Two further vulnerabilities also present risks of memory corruption. CVE-2026-66034 impacts the public-key subsystem. A malicious server can supply an unsafe length value, causing the parser to read beyond its allocated heap buffer. Furthermore, the error-handling path in this scenario might attempt to free an uninitialized pointer. This issue is resolved in commit a13bb6c.
The final vulnerability, CVE-2026-66035, is a pre-authentication heap buffer overflow located in the fullpacket() function within src/transport.c. During the Encrypt-then-MAC (EtM) cipher negotiation, a malicious server can send a packet that is smaller than the negotiated cipher block size. This leads to the library allocating an insufficient buffer and subsequently attempting to copy more data than the buffer can hold, resulting in an overflow. This vulnerability is addressed by commit 42e33d8.
What You Should Do
- Organizations and individual users are strongly advised to update libssh2 to a version that includes all four fixes immediately.
- If a direct update is not feasible, rebuild the library with the referenced upstream patches.
- It is crucial to identify all software packages that statically bundle libssh2, as simply updating the operating system’s libssh2 package may not protect all affected applications. Review your application stack for embedded versions.
Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.



No Comment! Be the first one.