CVE-2026-116773 in russh
Summary
by MITRE • 10/27/2026
russh is a Rust SSH client and server library that includes an SSH agent protocol implementation. Prior to 0.65.0, the client Session::process_packet path in russh/src/client/encrypted.rs accepts repeated packets encoded with russh's private msg::EXT_INFO = 7 before authentication, while the standards-compliant EXT_INFO message number 82 does not reach the affected handler. The handle_ext_info function appends every parsed extension name to received_extensions without clearing, deduplicating, or bounding the vector. A malicious SSH server that deliberately sends private message number 7 can therefore retain an unbounded number of attacker-controlled extension names for the session lifetime, causing progressive client memory exhaustion. This issue is fixed in version 0.65.0.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/27/2026
The vulnerability identified in russh versions prior to 0.65.0 represents a significant resource management flaw within its SSH agent protocol implementation and general client architecture. Russh, being a Rust-based library for both SSH clients and servers, relies on strict adherence to RFC standards for secure communication. However, the specific code path handling packet processing in the encrypted session phase contains a logic error regarding how extension information is parsed and stored. The core issue lies in the Session::process_packet function located within russh/src/client/encrypted.rs, which incorrectly accepts repeated packets encoded with the private message number EXT_INFO equal to 7 before authentication has been completed. According to SSH standards, the correct message type for extension negotiation during this phase should be message number 82. By accepting the non-standard or misinterpreted message number 7, the client inadvertently opens a channel for an attacker to inject arbitrary data into the session state without proper validation checks that would typically apply to standard-compliant messages.
The technical root cause of this vulnerability is found in the handle_ext_info function, which is responsible for processing extension information sent by the SSH server. Upon receiving these packets, the function appends every parsed extension name to a vector named received_extensions. Crucially, this implementation fails to clear previous entries, deduplicate incoming names, or impose any upper bound on the size of this vector. This lack of input validation and resource limiting means that each processed packet contributes directly to memory consumption without releasing prior allocations. In a normal operational scenario, extension negotiation is a brief phase at the start of an SSH connection involving a limited number of extensions. However, because the handler does not reset or limit storage, it treats every incoming EXT_INFO packet as new data to be retained for the entire lifetime of the session.
This architectural flaw leads directly to a severe operational impact in the form of progressive client memory exhaustion, commonly classified under CWE-400: Uncontrolled Resource Consumption. A malicious SSH server can exploit this by deliberately sending an unbounded number of EXT_INFO packets with message type 7 during the pre-authentication phase. Since each packet causes the received_extensions vector to grow without limit, the attacker can trigger a denial-of-service condition simply by maintaining a connection and continuously transmitting these crafted packets. The client process will gradually consume increasing amounts of RAM until it either crashes due to out-of-memory errors or becomes unresponsive, effectively disrupting service availability for legitimate users relying on this SSH library. This type of attack is particularly dangerous because it can be executed remotely without requiring any prior authentication credentials, aligning with ATT&CK techniques related to resource exhaustion and denial of service via application layer protocols.
The resolution for this vulnerability was implemented in version 0.65.0 of the russh library. The fix likely involves correcting the message type handling to strictly adhere to standard-compliant message numbers or implementing robust input validation that limits, deduplicates, or clears extension data as appropriate per SSH protocol specifications. To mitigate risks associated with this and similar vulnerabilities, organizations using russh must ensure they are operating on version 0.65.0 or later. Additionally, defensive measures such as deploying network-level rate limiting for incoming SSH connections can help reduce the impact of potential exploitation attempts by restricting the frequency at which clients accept new packets from untrusted servers. Regularly updating dependencies and conducting code reviews focused on resource management in cryptographic libraries are essential practices to maintain security posture against application-layer denial-of-service attacks.