CVE-2026-102821 in Russh
Summary
by MITRE • 09/29/2026
Russh is a Rust SSH client and server library. Prior to 0.63.2, an authenticated remote peer can send SSH_MSG_KEXINIT without the required SSH_MSG_KEX_ECDH_INIT and then flood SSH_MSG_CHANNEL_OPEN messages while SessionKexState::InProgress prevents priority_receiver in russh/src/server/session.rs from being drained. The server continues processing network input and enqueues a ChannelOpenReply for each request on an unbounded channel, allowing one connection to grow memory until the process is terminated. This issue is fixed in version 0.63.2.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/29/2026
The vulnerability identified in Russh, a Rust-based SSH client and server library, represents a significant resource exhaustion flaw that can lead to denial of service conditions within affected systems. Prior to version 0.63.2, the implementation contained a logic error in the key exchange state machine handling for authenticated sessions. Specifically, an attacker who has already established authentication with the SSH server could manipulate the protocol sequence by sending an SSH_MSG_KEXINIT message without subsequently providing the required SSH_MSG_KEX_ECDH_INIT message. This deviation from the expected cryptographic handshake procedure places the session into a persistent intermediate state known as SessionKexState::InProgress, which is intended to handle ongoing key exchange operations but fails to properly manage subsequent channel requests under these malformed conditions.
During this flawed state, the server continues to accept and process incoming network input rather than terminating or resetting the connection due to the protocol violation. For every SSH_MSG_CHANNEL_OPEN message received from the authenticated remote peer while in this invalid state, the server enqueues a ChannelOpenReply onto an unbounded channel located within the session handling logic. Because there is no mechanism to drain or limit the size of this priority_receiver queue during the key exchange phase, each malicious request results in additional memory allocation that persists for the duration of the connection. This behavior allows a single authenticated connection to consume increasing amounts of system memory as it floods the server with channel open requests.
The operational impact of this vulnerability is severe, primarily manifesting as a denial of service through resource exhaustion. As the unbounded channel fills up, the process consumes more and more RAM until the operating system terminates the Russh application due to out-of-memory conditions or excessive memory usage limits are reached. This effectively crashes the SSH server instance, disrupting connectivity for all other users relying on that specific process. The vulnerability is particularly dangerous because it requires only authenticated access, which may be achievable through compromised credentials or if authentication mechanisms are bypassed in certain configurations, although the primary vector relies on an attacker having valid login privileges to initiate this malformed sequence.
From a classification perspective, this issue aligns with CWE-400, Uncontrolled Resource Consumption, as the application fails to limit the amount of resources consumed by a single user or connection. It also relates to CWE-755, Improper Handling of Unexpected Exceptional Condition, since the server does not correctly handle the unexpected protocol state resulting from missing key exchange messages. In terms of attack patterns, this behavior is consistent with techniques found in MITRE ATT&CK under resource hijacking, where an adversary consumes resources to degrade service availability for legitimate users. The flaw highlights a critical gap in input validation and state management within the SSH server implementation during active sessions.
To mitigate this vulnerability, organizations running Russh must upgrade immediately to version 0.63.2 or later, which contains the necessary fixes to properly handle malformed key exchange sequences and prevent unbounded memory growth. For environments where upgrading is not immediately feasible, implementing network-level rate limiting on SSH connections can help reduce the impact of flooding attacks by restricting the number of channel open requests a single IP address can send within a given timeframe. Additionally, deploying intrusion detection systems that monitor for anomalous SSH protocol behavior, such as rapid succession of channel opens without proper key exchange completion, may provide an additional layer of defense against exploitation attempts until the software patch is applied.