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

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

: null pointer dereference in libssh kex session id calculation

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

libssh can try to open any file during configuration parsing, when misconfigured or when local attacker can provide malicious configuration. This applies for all configuration loaded from default location, configuration provided through the sshconfigparsefile() and sshbindconfigparsefile() functions as well as configuration files included from them directly or through glob wildcards.

The possibly dangerous files involve block devices, fifo, named pipe or huge system files that could cause Denial of Service.

The solution here is allowing to read only regular files and enforcing configuration file size limit of 16MB. Currently, maximum line length of a configuration file is 1K so this will effectively mean configuration files of 16K lines should still keep working.

A malicious SFTP server can send malformed longname field of the SSHFXPNAME message (file listing). Due to the missing NULL check, the libssh could read beyond the buffer bounds on heap, causing unexpected behavior or crashes.

NULL Pointer Dereference vulnerability in the session ID calculation logic of the libssh library. The flaw arises from improper handling of allocation errors during cryptographic operations in the key exchange (KEX) phase. If a memory allocation fails, the resulting NULL pointer may be dereferenced, leading to a crash in both SSH clients and servers. This vulnerability can be exploited by a local attacker with limited privileges and no user interaction, potentially disrupting services that rely on libssh for secure communication.The issue affects libssh versions up to and including 0.11.2.

Memory Exhaustion vulnerability in the key exchange logic of the libssh library. When an authenticated client repeatedly performs rekeying with incorrect firstkexpacketfollows guesses, libssh allocates new ephemeral key pairs without freeing old ones stored in session->nextcrypto. Over time, this results in a memory leak that can exhaust system memory and cause a client-side denial-of-service (DoS). This flaw affects several KEX algorithms (Curve25519, ECDH, sntrup761x25519, DH-GEX) across multiple crypto backends (libgcrypt, OpenSSL, mbedTLS). The issue requires an authenticated client and does not impact the server side. Versions Affected : libssh >= 0.6.0

If there is an error in initializing ChaCha20 cipher with OpenSSL, an invalid error code is returned. This can happen if there is an heap exhaustion. This error is not correctly detected and could allow libssh to use partially initialized cipher context. This is caused by the mismatch of return value meaning from OpenSSL and libssh, where OpenSSL error (rv=0) aliases with SSHOK (0) and is returned directly from the function chacha20poly1305setkey(). This will likely cause error somewhere down the road.

Out-of-Bounds Read vulnerability in the SFTP server implementation of libssh, specifically within the sftphandle() function. The flaw is due to an incorrect boundary check that permits the function to access memory beyond the valid handle list. This leads to the return of an invalid pointer, which is subsequently used in further processing. Although the issue requires authenticated access to the server, it can be exploited by a remote attacker with valid credentials to potentially read unintended memory regions, which could expose sensitive information or affect service behavior.

Incorrect Success Return vulnerability in the sshkdf() function of libssh when built with OpenSSL versions prior to 3.0. This issue arises because libssh interprets OpenSSL's return value 0 (indicating failure) as SSHOK (indicating success). As a result, on failure, the function may return success without initializing the output key buffers. This can lead to the use of uninitialized cryptographic keys, affecting the encryption and decryption of SSH traffic. The vulnerability allows an attacker to exploit improper key handling, potentially resulting in data leakage, integrity issues, or denial of service during SSH communication.

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.