A flaw was found with the libssh API function sshscpnew() in versions before 0.9.3 and before 0.8.8. When the libssh SCP client connects to a server, the scp command, which includes a user-provided path, is executed on the server-side. In case the library is used in a way where users can influence the third parameter of the function, it would become possible for an attacker to inject arbitrary commands, leading to a compromise of the remote target.

A vulnerability was found in libssh's server-side state machine before versions 0.7.6 and 0.8.4. A malicious client could create channels without first performing authentication, resulting in unauthorized access.

A flaw was found in libssh versions built with OpenSSL versions older than 3.0, specifically in the sshkdf() function responsible for key derivation. Due to inconsistent interpretation of return values where OpenSSL uses 0 to indicate failure and libssh uses 0 for success—the function may mistakenly return a success status even when key derivation fails. This results in uninitialized cryptographic key buffers being used in subsequent communication, potentially compromising SSH sessions' confidentiality, integrity, and availability.

A flaw was found in libssh server-side GSSAPIKeyExchange authorization. In sshpacketuserauthrequest() in src/messages.c, the gssapi-keyex login path granted success after Kerberos authentication without dispatching the callback that verifies whether the authenticated principal is authorized for the requested local user. On servers with GSSAPIKeyExchange enabled, an authenticated client can therefore log in as an arbitrary local user if the missing principal-to-user authorization check is relied upon for access control.

A flaw was found in libssh. The API function sshgethexa() is vulnerable to a denial of service when processing zero-length input. This can be exploited remotely by an attacker during GSSAPI (Generic Security Service Application Program Interface) authentication if the server's logging verbosity is set to SSHLOGPACKET (3) or higher. Successful exploitation could lead to a self-Denial of Service of the per-connection daemon process.

A flaw was found in the libssh library in versions less than 0.11.2. An out-of-bounds read can be triggered in the sftphandle function due to an incorrect comparison check that permits the function to access memory beyond the valid handle list and to return an invalid pointer, which is used in further processing. This vulnerability allows an authenticated remote attacker to potentially read unintended memory regions, exposing sensitive information or affect service behavior.

A flaw was found in libssh when using the ChaCha20 cipher with the OpenSSL library. If an attacker manages to exhaust the heap space, this error is not detected and may lead to libssh using a partially initialized cipher context. This occurs because the OpenSSL error code returned aliases with the SSHOK code, resulting in libssh not properly detecting the error returned by the OpenSSL library. This issue can lead to undefined behavior, including compromised data confidentiality and integrity or crashes.

A flaw was found in libssh. This vulnerability allows local man-in-the-middle attacks, security downgrades of SSH (Secure Shell) connections, and manipulation of trusted host information, posing a significant risk to the confidentiality, integrity, and availability of SSH communications via an insecure default configuration on Windows systems where the library automatically loads configuration files from the C:\etc directory, which can be created and modified by unprivileged local users.

A flaw was found in libssh builds using the OpenSSL backend for AES-GCM. In the decrypt path in src/libcrypto.c, the return value from EVPDecryptFinal() was checked incorrectly, so authentication tag verification failures were not handled as integrity failures. This could effectively remove integrity protection for affected AES-GCM sessions and allow an in-path attacker to modify plaintext on the wire without detection.

A flaw was found in libssh automatic certificate-based public key authentication. In sshuserauthpublickeyauto() in src/auth.c, the iterator over certificate candidates was not advanced correctly when configured certificates were missing or repeatedly rejected by the server. Under specific non-default certificate configurations, this could cause the client to restart the same authentication attempts indefinitely, leading to denial of service.

A flaw was found in libssh channel data handling. In channelrcvdata() in src/channels.c, incoming channel DATA messages could still be processed after the channel had already been marked as remotely closed. In SFTP-backed applications and other callback-driven consumers, this creates a path where data callbacks may observe channel-associated state after it has already been torn down or freed, leading to crashes and possible use-after-free conditions.

Last updated 25 August 2025

Double free vulnerability in the sftpmkdir function in sftp.c in libssh before 0.5.3 allows remote attackers to cause a denial of service (crash) and possibly execute arbitrary code via unspecified vectors, a different vector than CVE-2012-4559.

Florian Weimer of the Red Hat Product Security Team reported two cases where a function in libssh would write one past the end of the buffer (the u buffer in misc.c:sshpathexpandtilde() and the buf buffer in misc.c:sshpathexpandescape()).

Florian Weimer of the Red Hat Product Security Team reported many instances of overflow checks in libssh's buffer.c that were incorrect:

if ((buffer->pos + hostlen) > buffer->used) {

This should probably be:

if (hostlen > buffer->used - buffer->pos) {

It seems this could be used to trigger a large memory allocation which is immediately freed, so this is mostly harmless (not exploitable for code execution or denial of service).

A similar problem occurs in bufferadddata():

if (buffer->allocated < (buffer->used + len)) {

len should stand on its own.

Likewise in bufferprependdata():

if (buffer->allocated < (buffer->used - buffer->pos + len)) {

And bufferpassbytes(), bufferpassbytesend(), buffergetmpint():

if(buffer->used < buffer->pos+len)

if(buffer->used < buffer->pos + len)

if ((buffer->pos + len) > buffer->used) {

While it is not certain that any of these are actually be exploitable, the checks are incorrect and need to be fixed.

The (1) SSHMSGNEWKEYS and (2) SSHMSGKEXDHREPLY packet handlers in packagecb.c in libssh before 0.6.5 do not properly validate state, which allows remote attackers to cause a denial of service (NULL pointer dereference and crash) via a crafted SSH packet.

A flaw was found in libssh server-side SFTP directory listing. In processreaddir() in src/sftpserver.c, the server allocates a fixed stack buffer as char longname[MAXLONGNAMELEN] and passes attacker-controlled directory entry names into readdirlongname(). In the pre-patch implementation, readdirlongname() appends metadata and the filename into zlongname with repeated unbounded strcat() calls. Because zlongname points at the caller-owned fixed stack buffer, sufficiently long filenames in an attacker-controlled directory can overflow that stack buffer during SSHFXPREADDIR processing, leading to crashes and possible code execution on the server.

A flaw was found in libssh server-side GSSAPIKeyExchange authorization. In sshpacketuserauthrequest() in src/messages.c, the gssapi-keyex login path granted success after Kerberos authentication without dispatching the callback that verifies whether the authenticated principal is authorized for the requested local user. On servers with GSSAPIKeyExchange enabled, an authenticated client can therefore log in as an arbitrary local user if the missing principal-to-user authorization check is relied upon for access control.

A weakness has been identified in libssh up to 0.11.3. The impacted element is the function sftpextensionsgetname/sftpextensionsgetdata of the file src/sftp.c of the component SFTP Extension Name Handler. Executing a manipulation of the argument idx can lead to out-of-bounds read. The attack may be performed from remote. Upgrading to version 0.11.4 and 0.12.0 is sufficient to resolve this issue. This patch is called 855a0853ad3abd4a6cd85ce06fce6d8d4c7a0b60. You should upgrade the affected component.

Florian Weimer of the Red Hat Product Security Team reported several instances of code in libssh where a heap region is deallocated twice, first in the main path and then on the error path. This could crash the process using libssh, or possible allow for the execution of arbitrary code.

The identified affected variables are:

agent.c:agentsigndata(): request channels.c:channelrequest(): req auth.c:sshuserauthpubkey(): user, service, method, algo, pkstr sftp.c:sftpparseattr3(): longname, name sftp.c:sftpmkdir(): buffer, path keyfiles.c:trypublickeyfromfile(): pubkey

sftp.c:sftpmkdir() has been corrected via the following git commit:

http://git.libssh.org/projects/libssh.git/commit/?h=v0-5&id=4d8420f3282ed07fc99fc5e930c17df27ef1e9b2

A NULL pointer dereference was found In libssh during re-keying with algorithm guessing. This issue may allow an authenticated client to cause a denial of service.

A vulnerability was found in libssh, where the authentication check of the connecting client can be bypassed in thepkiverifydatasignature function in memory allocation problems. This issue may happen if there is insufficient memory or the memory usage is limited. The problem is caused by the return value rc, which is initialized to SSHERROR and later rewritten to save the return value of the function call pkikeycheckhashcompatible. The value of the variable is not changed between this point and the cryptographic verification. Therefore any error between them calls goto error returning SSHOK.

A Double Free vulnerability exists in libssh’s key export mechanism when built against OpenSSL 3.0 or later. The flaw lies in the pkikeytoblob() function, where a memory structure (params) is deallocated during error handling but not properly nullified. If a subsequent operation encounters an error, the same structure may be freed again, leading to undefined behavior and potential process crashes. Although exploitation requires authenticated access and specific memory failure conditions, the flaw could be leveraged to destabilize applications using libssh for exporting SSH key material.

Affected versions : libssh >= 0.10.0, built with OpenSSL >= 3.0

A flaw was found in the SFTP server message decoding logic of libssh. The issue occurs due to an incorrect packet length check that allows an integer overflow when handling large payload sizes on 32-bit systems. This issue leads to failed memory allocation and causes the server process to crash, resulting in a denial of service.

A flaw was found in libssh channel handling. In sshpacketchannelopen() in src/messages.c and sshpacketchannelopenconf() in src/channels.c, the implementation accepts a peer-controlled maximum packet size of 0 in channel open messages. That zero value is stored in channel state and later reaches channelwritecommon(), where forward progress depends on the remote maximum packet size being positive; with 0, the remaining length is never reduced and the write path loops indefinitely, consuming CPU and causing denial of service. A remote authenticated peer can trigger this by advertising a zero maximum packet size in SSHMSGCHANNELOPEN or SSHMSGCHANNELOPENCONFIRMATION.

A flaw was found in libssh server-side SFTP request handling. In sftpmakeclientmessage() and the downstream processread() path in src/sftpserver.c, the implementation accepts a client-controlled SSHFXPREAD length without enforcing a reasonable upper bound. The parsed len field later drives memory allocation in the SFTP server read path, so a remote authenticated client can request an excessively large read length and force the server to allocate excessive memory. Repeated requests can exhaust available memory and lead to denial of service.

A flaw has been found in libssh in versions prior to 0.9.6. The SSH protocol keeps track of two shared secrets during the lifetime of the session. One of them is called secrethash and the other sessionid. Initially, both of them are the same, but after key re-exchange, previous sessionid is kept and used as an input to new secrethash. Historically, both of these buffers had shared length variable, which worked as long as these buffers were same. But the key re-exchange operation can also change the key exchange method, which can be based on hash of different size, eventually creating "secrethash" of different size than the sessionid has. This becomes an issue when the sessionid memory is zeroed or when it is used again during second key re-exchange.

A missing allocation check in sftp server processing read requests may cause a NULL dereference on low-memory conditions. The malicious client can request up to 4GB SFTP reads, causing allocation of up to 4GB buffers, which was not being checked for failure. This will likely crash the authenticated user's sftp server connection (if implemented as forking as recommended). For thread-based servers, this might also cause DoS for legitimate users. Given this code is not in any released versions, no security releases have been issued.

A malicious SCP server can send unexpected paths that could make the client application override local files outside of working directory. This could be misused to create malicious executable or configuration files and make the user execute them under specific consequences.

This is the same issue as in OpenSSH, tracked as CVE-2019-6111.

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.