CVE-2026-116774 in russh
Summary
by MITRE • 10/27/2026
russh is a Rust SSH client and server library that includes an SSH agent protocol implementation. From 0.60.0 until 0.65.0, channel-open parsing accepts a peer-declared maximum_packet_size of zero and passes it into ChannelTx::poll_writable in russh/src/channels/io/tx.rs. The Channel::data, Channel::make_writer, and Channel::into_stream asynchronous write paths then calculate a writable size of zero and remain pending forever because window adjustments cannot satisfy a static zero packet maximum. An authenticated client can strand server writes, and a malicious server can strand client writes, allowing affected tasks, channels, and connections to accumulate without surfacing an error. This issue is fixed in version 0.65.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/27/2026
The russh library, implemented in Rust as both an SSH client and server with support for the SSH agent protocol, contains a critical logic flaw within its channel management subsystem that leads to resource exhaustion through indefinite task suspension. This vulnerability specifically affects versions ranging from 0.60.0 up to but not including 0.65.0. The core of the issue resides in the parsing and validation of incoming SSH packets during the channel-open negotiation phase. When a peer declares a maximum packet size for a new channel, the library fails to validate that this value is strictly greater than zero before accepting it into the internal state structures. This lack of input validation allows an attacker to inject a malformed or maliciously crafted parameter with a value of zero, which is then passed directly into the ChannelTx::poll_writable function responsible for managing write operations on that channel.
The technical consequence of this invalid configuration propagates through several asynchronous write paths within the library, including Channel::data, Channel::make_writer, and Channel::into_stream. These functions rely on calculating a writable size based on the configured maximum packet size to determine how much data can be safely queued for transmission without exceeding buffer limits or violating protocol constraints. When the maximum packet size is zero, these calculations invariably result in a writable size of zero. Consequently, any attempt to write data to this channel triggers an asynchronous wait condition where the task remains pending indefinitely because it cannot proceed with sending data. The SSH protocol relies on window adjustments to dynamically increase available space for writes when buffers clear; however, since the maximum packet size is statically set to zero by the vulnerability's root cause, no amount of window adjustment can ever satisfy a requirement that fundamentally prohibits any transmission.
From an operational impact perspective, this flaw enables two distinct attack vectors depending on whether the vulnerable component acts as a server or a client. An authenticated attacker acting as a client can exploit this behavior against a vulnerable SSH server by initiating channel openings with zero-sized packet declarations. This causes the server's write tasks to hang indefinitely, effectively stranding them in memory without surfacing an error condition that would allow for graceful termination or cleanup. Similarly, if the russh library is used as a client connecting to a malicious server, the server can force the client into this same state by sending channel-open messages with zero maximum packet sizes. In both scenarios, affected tasks accumulate over time because they are never completed nor errored out, leading to a gradual but steady consumption of system resources such as memory and thread handles. This accumulation does not immediately crash the application but creates a denial-of-service condition where legitimate operations may be starved of resources or the process becomes unresponsive due to excessive pending tasks.
This vulnerability aligns with CWE-20 Improper Input Validation, specifically regarding the failure to verify that numeric parameters meet expected constraints such as being positive integers. It also relates to CWE-770 Allocation of Resources Without Limits or Throttling in Cloud Environments, although applied here to local resource exhaustion via task scheduling rather than cloud-specific quotas. In terms of offensive security frameworks, this behavior is consistent with ATT&CK technique T1496 Resource Hijacking, where an attacker consumes system resources to degrade performance or availability. The lack of error propagation means the application remains in a zombie-like state regarding these specific channels, making detection difficult without monitoring task counts and memory usage over time.
Mitigation for this issue requires upgrading the russh library to version 0.65.0 or later, where the channel-open parsing logic has been corrected to reject zero values for maximum packet sizes. For organizations unable to immediately upgrade, implementing a network-level filter that inspects SSH handshake packets and drops any channel-open messages containing invalid parameters can provide temporary relief, though this is less effective against encrypted traffic unless deep packet inspection capabilities are available at the proxy level. Application developers should also consider adding defensive checks in their own code when integrating russh to ensure that no zero-sized buffers or channels are created inadvertently through other means. Regular monitoring of application health metrics, particularly regarding pending asynchronous tasks and memory consumption trends, can help detect such resource exhaustion attacks early before they lead to complete service unavailability.