Russh EUVD-2026-89206

Requires the russh-based application to act as an SSH CLIENT (versions prior to 0.63.1) and to connect to a server the attacker controls or has compromised; the malicious server then sends channel-scoped protocol messages (CHANNEL_DATA, CHANNEL_EXTENDED_DATA, CHANNEL_EOF, CHANNEL_CLOSE, CHANNEL_OPEN_FAILURE, CHANNEL_SUCCESS, CHANNEL_FAILURE, or CHANNEL_REQUEST exit-status/exit-signal/xon-xoff) referencing channel IDs the client never opened, whose open was denied, or that are not yet confirmed. The key LIMITING factor is the trust model: exploitation is not possible against an arbitrary victim over the open network - the attacker must occupy the server side of a connection the client initiates and trusts, so risk concentrates in scenarios with untrusted or attacker-influenced SSH endpoints (malicious jump hosts, MITM, automation connecting to untrusted hosts).

The vendor-assigned CVSS is 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N), scoring this as a network-reachable integrity break with no confidentiality or availability impact. That labeling is internally inconsistent with the description, which explicitly states the primary consequence is 'application panics' - a denial-of-service (availability) effect - alongside 'corrupting command completion and exit-code tracking' (the integrity effect). A more defensible read is I:H plus a real availability component; there is no confidentiality impact, so the 'Information Disclosure' tag is wrong. Critically, the AV:N/PR:N/UI:N framing understates the trust model: this is a CLIENT-side library flaw, and exploitation requires the victim client to connect to a MALICIOUS or compromised SSH server. There is no EPSS score, no CISA KEV listing, and no public exploit code in the provided data, so this is not confirmed as actively exploited - no public exploit identified at time of analysis. Net: it is a legitimate correctness/robustness bug (CWE-20) fixed cleanly in 0.63.1 and worth patching for any Rust project embedding russh as a client, but it is a moderate-priority issue, not an urgent one - the 7.5 rating overstates real-world urgency because the attacker must already control the SSH server the client trusts, and the realistic outcome is a client crash or corrupted exit-status bookkeeping rather than code execution or data theft.

A victim application built on russh (versions prior to 0.63.1) connects as an SSH client to a server the attacker controls or has compromised (e.g. a malicious jump host, a spoofed endpoint, or an untrusted host in an automation/CI pipeline). The malicious server sends CHANNEL_DATA, CHANNEL_CLOSE, CHANNEL_REQUEST exit-status/exit-signal, or similar lifecycle messages referencing channel IDs the client never opened or that are unconfirmed, driving Handler callbacks for phantom channels and causing the client to panic or record bogus exit codes. No public proof-of-concept is referenced in the provided intelligence.