A flaw was found in libssh in the server-side GSSAPI Curve25519 key exchange path in src/kex-gss.c. In sshservergsskexprocessinit(), a client-controlled SSH string is unpacked into clientpubkey and then copied with memcpy(..., CURVE25519PUBKEYSIZE) without validating sshstringlen(clientpubkey). A remote unauthenticated client can send a short public key in SSHMSGKEXGSSINIT and trigger an out-of-bounds heap read during handshake processing, disclosing small amounts of adjacent server memory.

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 username handling for ProxyCommand expansion. The sshcheckusernamesyntax() validation path in src/misc.c used an incomplete dangerous-character filter for usernames expanded through %r. As a result, specially crafted usernames containing shell-significant characters could reach shell-evaluated ProxyCommand handling and influence shell expansion, exposing environment variables and causing unintended shell behavior. This issue affects clients that combine untrusted username input with ProxyCommand-style shell execution.

A flaw was found in libssh in which a malicious SFTP (SSH File Transfer Protocol) server can exploit this by sending a malformed 'longname' field within an SSHFXPNAME message during a file listing operation. This missing null check can lead to reading beyond allocated memory on the heap. This can cause unexpected behavior or lead to a denial of service (DoS) due to application crashes.

A flaw was found in libssh where it can attempt to open arbitrary files during configuration parsing. A local attacker can exploit this by providing a malicious configuration file or when the system is misconfigured. This vulnerability could lead to a Denial of Service (DoS) by causing the system to try and access dangerous files, such as block devices or large system files, which can disrupt normal operations.

A flaw was found in libssh. A remote attacker, by controlling client configuration files or knownhosts files, could craft specific hostnames that when processed by the matchpattern() function can lead to inefficient regular expression backtracking. This can cause timeouts and resource exhaustion, resulting in a Denial of Service (DoS) for the client.

A flaw was found in libssh's handling of key exchange (KEX) processes when a client repeatedly sends incorrect KEX guesses. The library fails to free memory during these rekey operations, which can gradually exhaust system memory. This issue can lead to crashes on the client side, particularly when using libgcrypt, which impacts application stability and availability.

A vulnerability was found in libssh, where an uninitialized variable exists under certain conditions in the privatekeyfromfile() function. This flaw can be triggered if the file specified by the filename doesn't exist and may lead to possible signing failures or heap corruption.

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 the libssh implements abstract layer for message digest (MD) operations implemented by different supported crypto backends. The return values from these were not properly checked, which could cause low-memory situations failures, NULL dereferences, crashes, or usage of the uninitialized memory as an input for the KDF. In this case, non-matching keys will result in decryption/integrity failures, terminating the connection.

A flaw was found in libssh. By utilizing the ProxyCommand or ProxyJump feature, users can exploit unchecked hostname syntax on the client. This issue may allow an attacker to inject malicious code into the command of the features mentioned through the hostname parameter.

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

bintobase64() (src/base64.c) can experience an integer overflow and subsequent under allocation, leading to a write beyond bounds. The bug can occur only in 32-bit builds. The only problematic use case is sshgetfingerprinthash() in case the API is (mis)used and a libssh consumer passes in an unexpectedly large input buffer. As a mitigation, the function bintobase64() is adjusted to not allow inputs larger than 256MB, which is aligned with other functions that process user input.

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 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.

: null pointer dereference in libssh kex session id calculation

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 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.

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 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 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 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.

The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH's use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in chacha20-poly1305@openssh.com and (if CBC is used) the -etm@openssh.com MAC algorithms. This also affects Maverick Synergy Java SSH API before 3.1.0-SNAPSHOT, Dropbear through 2022.83, Ssh before 5.1.1 in Erlang/OTP, PuTTY before 0.80, AsyncSSH before 2.14.2, golang.org/x/crypto before 0.17.0, libssh before 0.10.6, libssh2 through 1.11.0, Thorn Tech SFTP Gateway before 3.4.6, Tera Term before 5.1, Paramiko before 3.4.0, jsch before 0.2.15, SFTPGo before 2.5.6, Netgate pfSense Plus through 23.09.1, Netgate pfSense CE through 2.7.2, HPN-SSH through 18.2.0, ProFTPD before 1.3.8b (and before 1.3.9rc2), ORYX CycloneSSH before 2.3.4, NetSarang XShell 7 before Build 0144, CrushFTP before 10.6.0, ConnectBot SSH library before 2.2.22, Apache MINA sshd through 2.11.0, sshj through 0.37.0, TinySSH through 20230101, trilead-ssh2 6401, LANCOM LCOS and LANconfig, FileZilla before 3.66.4, Nova before 11.8, PKIX-SSH before 14.4, SecureCRT before 9.4.3, Transmit5 before 5.10.4, Win32-OpenSSH before 9.5.0.0p1-Beta, WinSCP before 6.2.2, Bitvise SSH Server before 9.32, Bitvise SSH Client before 9.33, KiTTY through 0.76.1.13, the net-ssh gem 7.2.0 for Ruby, the mscdex ssh2 module before 1.15.0 for Node.js, the thrussh library before 0.35.1 for Rust, and the Russh crate before 0.40.2 for Rust.

The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH's use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in chacha20-poly1305@openssh.com and (if CBC is used) the -etm@openssh.com MAC algorithms. This also affects Maverick Synergy Java SSH API before 3.1.0-SNAPSHOT, Dropbear through 2022.83, Ssh before 5.1.1 in Erlang/OTP, PuTTY before 0.80, AsyncSSH before 2.14.2, golang.org/x/crypto before 0.17.0, libssh before 0.10.6, libssh2 through 1.11.0, Thorn Tech SFTP Gateway before 3.4.6, Tera Term before 5.1, Paramiko before 3.4.0, jsch before 0.2.15, SFTPGo before 2.5.6, Netgate pfSense Plus through 23.09.1, Netgate pfSense CE through 2.7.2, HPN-SSH through 18.2.0, ProFTPD before 1.3.8b (and before 1.3.9rc2), ORYX CycloneSSH before 2.3.4, NetSarang XShell 7 before Build 0144, CrushFTP before 10.6.0, ConnectBot SSH library before 2.2.22, Apache MINA sshd through 2.11.0, sshj through 0.37.0, TinySSH through 20230101, trilead-ssh2 6401, LANCOM LCOS and LANconfig, FileZilla before 3.66.4, Nova before 11.8, PKIX-SSH before 14.4, SecureCRT before 9.4.3, Transmit5 before 5.10.4, Win32-OpenSSH before 9.5.0.0p1-Beta, WinSCP before 6.2.2, Bitvise SSH Server before 9.32, Bitvise SSH Client before 9.33, KiTTY through 0.76.1.13, the net-ssh gem 7.2.0 for Ruby, the mscdex ssh2 module before 1.15.0 for Node.js, the thrussh library before 0.35.1 for Rust, and the Russh crate before 0.40.2 for Rust.

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.

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 client-side SFTP message handling. In sftpgetmessage() in src/sftpcommon.c, SFTP responses carrying unknown request IDs were accepted and kept queued instead of being rejected. A malicious SFTP server can repeatedly send responses for request IDs that were never issued by the client, causing unbounded growth of queued messages and leading to client-side memory exhaustion and 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.

A flaw was found in libssh client-side ProxyCommand handling. In sshsocketconnectproxycommand() in src/socket.c, the return value of fork() was not checked before being stored as the proxy child PID. If fork() fails, the value -1 can be retained in state and later used during cleanup, causing signals to be sent across the caller's accessible process tree. In deployments that use ProxyCommand, this can lead to local denial of service.