GHSA-47hw-gvq5-r2gm: Input Validation
Summary CVE-2026-68930 was fixed by adding Session::isestablishedchannel() in russh/src/server/encrypted.rs, which gates every channel-scoped SERVER-side message (CHANNELREQUEST, CHANNELDATA, CHANNELEOF, CHANNELCLOSE, CHANNELWINDOWADJUST, CHANNELEXTENDEDDATA) on enc.channels.get(&channel).issomeand(|c| c.confirmed) before invoking any Handler callback. The identical validation was never added to the CLIENT side (russh/src/client/encrypted.rs), which processes channel-scoped messages sent by the SSH SERVER once the client has authenticated.
Details In clientreadauthenticated (russh/src/client/encrypted.rs, ~lines 431-757), for CHANNELDATA, CHANNELEXTENDEDDATA, CHANNELEOF, CHANNELCLOSE, CHANNELOPENFAILURE, CHANNELSUCCESS, CHANNELFAILURE, and the CHANNELREQUEST sub-types exit-status/exit-signal/xon-xoff, the code only optionally forwards the event to the internal per-channel mpsc sender via if let Some(chan) = self.channels.get(&channelnum) { ... } (a no-op if the channel is unknown), but then unconditionally calls the corresponding public Handler trait method (client.data(...), client.exitstatus(...), client.channelclose(...), client.channelsuccess(...), etc.) regardless of whether channelnum corresponds to any channel the client ever opened or that was ever confirmed. Only CHANNELOPENCONFIRMATION (closes the connection with Error::Inconsistent if unknown) and CHANNELWINDOWADJUST (returns early with Ok(()) if unknown) correctly validate channel existence before acting.
Corroborating evidence this check was intended but never wired up: crate::Error defines a dedicated WrongChannel variant documented as "Message received/sent on unopened channel" (russh/src/libinner.rs, ~line 144-146), yet a repo-wide search shows this variant is never constructed or returned anywhere in the codebase — dead code left over from (or intended for) exactly this validation.
Because Session::newchannelid() (russh/src/session.rs, ~line 708) allocates channel IDs sequentially starting at 1, a malicious or compromised SSH server can trivially predict the ID of the client's next channel and inject spoofed lifecycle events for it before or interleaved with the real channel-open exchange, or replay events for already-closed channel IDs.
PoC Many real-world consumers of russh-as-a-client (deployment/orchestration tools, CI runners connecting to build/bastion hosts, git-over-ssh style tooling, database/tunnel clients) implement the client::Handler trait directly and key their own state (e.g. HashMap<ChannelId, CommandState>, exit-code trackers, per-channel byte counters, completion futures) off the channel IDs the library hands them, trusting the documented contract that events like "The remote process has exited" (exitstatus) or "Called when the server closes a channel" (channelclose) only fire for a channel the application itself opened.
A malicious, MITM'd (via a compromised/rogue jump host the client is configured to trust), or simply hostile SSH server can send SSHMSGCHANNELREQUEST (exit-status/exit-signal), SSHMSGCHANNELDATA, SSHMSGCHANNELCLOSE, SSHMSGCHANNELSUCCESS/FAILURE, or SSHMSGCHANNELOPENFAILURE for an arbitrary/predicted/never-opened channel ID at any point after authentication completes. Because the library invokes the Handler callback unconditionally, this reaches application code with an ID it never registered.
Impact (1) A reliable, purely protocol-level trigger for an application panic/DoS in any client that indexes per-channel state by ChannelId without itself re-checking channel validity — the exact class of bug CVE-2026-68930 fixed server-side; and (2) lets the server spoof exit-status/exit-signal/close/success/failure notifications for a channel the client has not yet opened or has already released, desynchronizing the client's command-completion bookkeeping (e.g. reporting a forged exit code 0 for a not-yet-run remote command, or a premature channelclose before real output/exit-status has arrived) — a business-logic-level integrity violation of the SSH channel lifecycle that automation built on russh implicitly relies on.
Suggested fix: add the same isestablishedchannel()-style gate already used in server/encrypted.rs to client/encrypted.rs's clientreadauthenticated, checking self.channels.get(&channelnum) before invoking any Handler callback (not just the mpsc forward), for every channel-scoped message type.
For credit/changelog purposes, please use: Yazan Balawneh, Cystack.ps
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
rust/russhto a version that resolves this vulnerability.Fixed in 0.63.1 - Compensating control
In russh/src/client/encrypted.rs, add an is_established_channel()-style validation in client_read_authenticated that checks self.channels.get(&channel_num) before invoking any Handler callback for channel-scoped server messages, including CHANNEL_DATA, CHANNEL_EXTENDED_DATA, CHANNEL_EOF, CHANNEL_CLOSE, CHANNEL_OPEN_FAILURE, CHANNEL_SUCCESS, CHANNEL_FAILURE, and CHANNEL_REQUEST exit-status/exit-signal/xon-xoff subtypes.
Event History
Frequently Asked Questions
Who is exposed to this issue?
Applications using russh as an SSH client are exposed after client authentication if they connect to a malicious or compromised SSH server. The missing validation is on the client-side processing path, not the server-side gate described in the fix for the related issue.
What does an attacker need to do to trigger the vulnerable behavior?
The attacker must act as the SSH server and send channel-scoped messages for an unknown or unconfirmed channel after the client has authenticated. The affected client path can invoke public Handler callbacks even when no matching channel exists in its internal channel map.
How can I determine whether my code is affected?
Review the russh client authenticated-message handling in russh/src/client/encrypted.rs. It is affected if channel-scoped messages such as CHANNEL_DATA, CHANNEL_EOF, CHANNEL_CLOSE, CHANNEL_SUCCESS, CHANNEL_FAILURE, or the listed CHANNEL_REQUEST sub-types can reach public Handler methods without first verifying that the channel exists and is confirmed.