libssh2 through 1.11.1, fixed in commit a13bb6c, contains a missing bounds check vulnerability that allows a malicious SSH server to trigger an arbitrary-length heap out-of-bounds read and a free of an uninitialized pointer via the publickey subsystem. In libssh2publickeylistfetch(), the version 1 response parser reads a server-controlled commentlen value and advances the parse pointer without verifying sufficient bytes remain in the buffer, causing the out-of-bounds read to leak heap pointers from adjacent allocations defeating ASLR, followed by heap allocator state corruption when the error cleanup path frees an uninitialized pointer from a non-zeroed realloc() region.
libssh2 through 1.11.1, fixed in commit 5e47761, contains a double-free vulnerability in the sftpopen() function in src/sftp.c that allows a malicious SSH server to corrupt the heap of any authenticated client opening an SFTP session. When a server responds to SSHFXPOPEN with SSHFXPSTATUS containing FXOK, the response data buffer is freed, and if a subsequent sftppacketrequire() call returns a specific error such as LIBSSH2ERRORCHANNELPACKETEXCEEDED, the same pointer is freed a second time, enabling tcache dup conditions on glibc systems that allow overlapping allocations and function pointer overwrites.
libssh2 Heap Buffer Overflow via ETM Cipher Negotiation
libssh2 Heap Out-of-Bounds Read via publickey subsystem
Last updated 4 September 2026
Last updated 4 September 2026
libssh2 through 1.11.1 reads an attacker-controlled 32-bit attribute count from a publickey-subsystem response and uses it in the allocation numattrs sizeof(libssh2publickeyattribute) without bounds checking, so on 32-bit platforms the multiplication overflows to an undersized buffer. A malicious SSH server can then drive the attribute-parsing loop to write past the allocation, causing a heap buffer overflow in a connecting libssh2 client.
Last updated 13 July 2026
Last updated 13 July 2026
On 24/06/2026 13:14, Sevan Janiyan wrote:
via https://github.com/libssh2/libssh2/pull/2052 "transport.c: Additional boundary checks for packet length" Ignore this, I was wrong.
Sevan
On 23/06/2026 21:24, James Addison wrote: The commit IDs of the fixes for each of the vulnerabilities, respectively, as found in the GitHub libssh2/libssh2.git repository, are:
- 2dae3024897e1898d389835151f4e9606227721d - 17626857d20b3c9a1addfa45979dadcee1cd84a4 - 97acf3dfda80c91c3a8c9f2372546301d4a1a7a8
[1] -https://digital.nhs.uk/cyber-alerts/2026/cc-4799
https://github.com/libssh2/libssh2/commit/97acf3dfda80c91c3a8c9f2372546301d4a1a7a8 via https://github.com/libssh2/libssh2/pull/2052 "transport.c: Additional boundary checks for packet length"
Sorry, too busy melting to provide a patch against 1.11.1 release. :(
Sincerely,
Sevan
On 6/23/26 13:24, James Addison wrote: - Critical severity, 9.2 rating: CVE-2026-55200 https://github.com/bikini/exploitarium/tree/main/libssh2-cve-2026-55200-poc claims to provide a PoC for this one.
-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris
Hello list,
With credit to the NHS Digital Cyber security team for publishing[1] a notice about CVE-2026-55200 that alerted me to these:
Three vulnerabilities in libssh2 - a popular client library for the Unix secure shell protocol (aka SSH) - have been published as CVEs:
- High severity, 8.3 rating: CVE-2025-15661 - High severity, 8.2 rating: CVE-2026-55199 - Critical severity, 9.2 rating: CVE-2026-55200
The vulnerabilities affect versions up-to-and-including v1.11.1 of the libssh2 library.
Patches/commits fixing each of the vulnerabilities are available and have been merged into the libssh2 mainline development source control branch.
A release containing these fixes is under preparation.
For reference:
The commit IDs of the fixes for each of the vulnerabilities, respectively, as found in the GitHub libssh2/libssh2.git repository, are:
- 2dae3024897e1898d389835151f4e9606227721d - 17626857d20b3c9a1addfa45979dadcee1cd84a4 - 97acf3dfda80c91c3a8c9f2372546301d4a1a7a8
Regards, James
[1] - https://digital.nhs.uk/cyber-alerts/2026/cc-4799
-- OpenCulinary C.I.C. is a Community Interest Company, number SC647817, registered in Scotland, United Kingdom and with registered company address The Melting Pot, 15 Calton Road, Edinburgh, Scotland, EH8 8DL.
Last updated 30 June 2026
Last updated 30 June 2026
Last updated 30 June 2026
A security vulnerability has been detected in libssh2 up to 1.11.1. The impacted element is the function userauthpassword of the file src/userauth.c. Such manipulation of the argument usernamelen/passwordlen leads to integer overflow. The attack may be launched remotely. The name of the patch is 256d04b60d80bf1190e96b0ad1e91b2174d744b1. A patch should be applied to remediate this issue.
A security vulnerability has been detected in libssh2 up to 1.11.1. The impacted element is the function userauthpassword of the file src/userauth.c. Such manipulation of the argument usernamelen/passwordlen leads to integer overflow. The attack may be launched remotely. The name of the patch is 256d04b60d80bf1190e96b0ad1e91b2174d744b1. A patch should be applied to remediate this issue.
Summary
Terrapin is a prefix truncation attack targeting the SSH protocol. More precisely, Terrapin breaks the integrity of SSH's secure channel. By carefully adjusting the sequence numbers during the handshake, an attacker can remove an arbitrary amount of messages sent by the client or server at the beginning of the secure channel without the client or server noticing it.
Mitigations
To mitigate this protocol vulnerability, OpenSSH suggested a so-called "strict kex" which alters the SSH handshake to ensure a Man-in-the-Middle attacker cannot introduce unauthenticated messages as well as convey sequence number manipulation across handshakes.
Warning: To take effect, both the client and server must support this countermeasure.
As a stop-gap measure, peers may also (temporarily) disable the affected algorithms and use unaffected alternatives like AES-GCM instead until patches are available.
Details
The SSH specifications of ChaCha20-Poly1305 (chacha20-poly1305@openssh.com) and Encrypt-then-MAC (-etm@openssh.com MACs) are vulnerable against an arbitrary prefix truncation attack (a.k.a. Terrapin attack). This allows for an extension negotiation downgrade by stripping the SSHMSGEXTINFO sent after the first message after SSHMSGNEWKEYS, downgrading security, and disabling attack countermeasures in some versions of OpenSSH. When targeting Encrypt-then-MAC, this attack requires the use of a CBC cipher to be practically exploitable due to the internal workings of the cipher mode. Additionally, this novel attack technique can be used to exploit previously unexploitable implementation flaws in a Man-in-the-Middle scenario.
The attack works by an attacker injecting an arbitrary number of SSHMSGIGNORE messages during the initial key exchange and consequently removing the same number of messages just after the initial key exchange has concluded. This is possible due to missing authentication of the excess SSHMSGIGNORE messages and the fact that the implicit sequence numbers used within the SSH protocol are only checked after the initial key exchange.
In the case of ChaCha20-Poly1305, the attack is guaranteed to work on every connection as this cipher does not maintain an internal state other than the message's sequence number. In the case of Encrypt-Then-MAC, practical exploitation requires the use of a CBC cipher; while theoretical integrity is broken for all ciphers when using this mode, message processing will fail at the application layer for CTR and stream ciphers.
For more details see https://terrapin-attack.com.
Impact
This attack targets the specification of ChaCha20-Poly1305 (chacha20-poly1305@openssh.com) and Encrypt-then-MAC (-etm@openssh.com), which are widely adopted by well-known SSH implementations and can be considered de-facto standard. These algorithms can be practically exploited; however, in the case of Encrypt-Then-MAC, we additionally require the use of a CBC cipher. As a consequence, this attack works against all well-behaving SSH implementations supporting either of those algorithms and can be used to downgrade (but not fully strip) connection security in case SSH extension negotiation (RFC8308) is supported. The attack may also enable attackers to exploit certain implementation flaws in a man-in-the-middle (MitM) scenario.
An issue was discovered in function libssh2packetadd in libssh2 1.10.0 allows attackers to access out of bounds memory.
An out of bounds read flaw was discovered in libssh2 before 1.8.1 in the libssh2packetrequire and libssh2packetrequirev functions. A remote attacker who compromises a SSH server may be able to cause a Denial of Service or read data in the client memory.
A flaw was found in libssh2 before 1.8.1 creating a vulnerability on the SSH client side. A server could send a multiple keyboard interactive response messages whose total length are greater than unsigned char max characters. This value is used by the SSH client as an index to copy memory causing in an out of bounds memory write error.
A server could send a specially crafted SSHMSGCHANNELREQUEST packet with an exit status message and no payload. This would result in an out of bounds memory comparison.
A server could send a specially crafted partial SFTP packet with a zero value for the payload length. This zero value would be used to then allocate memory resulting in a zero byte allocation and possible out of bounds read.
A malicious server could send a specially crafted packet which could result in an unchecked integer overflow. The value would then be used to allocate memory causing a possible memory write out of bounds error.
The kexagreemethods function in libssh2 before 1.5.0 allows remote servers to cause a denial of service (crash) or have other unspecified impact via crafted length values in an SSHMSGKEXINIT packet.