CVE-2026-102822 in russh
Summary
by MITRE • 09/29/2026
Russh is a Rust SSH client and server library. Prior to 0.63.1, a connection configured to permit mac=none can negotiate it with a MAC-requiring CTR or CBC block cipher because the selection logic validates needs_mac() only when MAC selection fails. A remote peer can then send a packet with a decrypted length of zero, causing russh/src/cipher/mod.rs to shrink the previously read block before indexing buffer.buffer[16..], which panics and terminates the connection task. This issue is fixed in version 0.63.1.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/29/2026
The vulnerability identified in Russh, a Rust-based SSH client and server library, represents a critical flaw in the cryptographic negotiation and packet processing logic that can lead to service disruption through application termination. The core of this issue lies in the interaction between MAC (Message Authentication Code) selection algorithms and block cipher modes such as CTR or CBC. In versions prior to 0.63.1, the library's connection configuration allows for a scenario where mac=none is permitted during initial setup. However, the internal validation logic responsible for ensuring that selected ciphers are compatible with their required MAC types contains a logical gap. Specifically, the function needs_mac() is only invoked when explicit MAC selection fails or is ambiguous. If a client or server explicitly negotiates no MAC but pairs it with a block cipher like CTR or CBC, which inherently requires integrity protection to prevent padding oracle attacks and other cryptographic abuses, the library proceeds without enforcing this compatibility check during the handshake phase.
This oversight creates an exploitable condition where a remote peer can establish a connection using mac=none alongside a MAC-requiring cipher mode. Once the tunnel is established, the attacker can craft malicious SSH packets designed to exploit how Russh handles decryption and buffer indexing under these specific parameters. When such a packet arrives, it may contain decrypted data that results in a length field of zero or triggers an edge case in the padding removal process for CBC/CTR modes. The library's cipher module then attempts to shrink the previously read block based on this invalid state before proceeding to index into the buffer at offset 16 with the expression buffer.buffer[16..]. Because the preceding operation has altered the buffer size or content incorrectly, this indexing operation exceeds valid bounds, triggering a panic in Rust.
The operational impact of this vulnerability is significant for any service relying on Russh as an SSH server component. Since the flaw results in a hard panic rather than a graceful error handling routine, it causes immediate termination of the connection task. In a multi-threaded or asynchronous environment typical of modern servers, this can lead to resource leaks if cleanup routines are not properly executed during panic unwinding, and more critically, it facilitates Denial of Service attacks against SSH services built on Russh. An attacker does not need authentication credentials; they merely need network access to the target port and the ability to initiate a connection with the specific malformed parameters described above. This makes the vulnerability remotely exploitable without prior authorization, classifying it as a high-severity availability risk.
From a standards perspective, this flaw aligns closely with CWE-20 Improper Input Validation, as the application fails to adequately validate the compatibility between cryptographic algorithms before accepting them for use in secure communication channels. Furthermore, the exploitation technique falls under MITRE ATT&CK T1499 Endpoint Denial of Service, specifically via resource exhaustion or loop-induced crashes, although here it manifests through a direct crash rather than sustained load. The failure to enforce integrity checks on ciphers that require them also touches upon CWE-327 Use of a Broken or Risky Cryptographic Algorithm, as using CTR or CBC without MAC is generally considered insecure practice in SSH implementations due to the lack of authentication for ciphertext blocks.
Mitigation strategies primarily involve upgrading to version 0.63.1 or later, where the developers have corrected the selection logic to ensure that needs_mac() is evaluated regardless of explicit MAC negotiation outcomes when using vulnerable cipher modes. For organizations unable to immediately patch their systems due to dependency constraints, temporary mitigations should focus on network-level controls such as firewall rules or intrusion prevention system signatures that block SSH traffic attempting to negotiate mac=none with CTR or CBC ciphers. Additionally, implementing strict configuration policies within the application layer to reject any cipher suites that do not include a valid MAC algorithm can provide defense-in-depth against this specific attack vector until the underlying library is updated.