CVE-2026-102823: russh: Client-side channel-scoped Handler callbacks fire for channel IDs the client never opened

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