russh is a Rust SSH client and server library that includes an SSH agent protocol implementation. From 0.60.0 until 0.65.0, channel-open parsing accepts a peer-declared maximumpacketsize of zero and passes it into ChannelTx::pollwritable in russh/src/channels/io/tx.rs. The Channel::data, Channel::makewriter, and Channel::intostream asynchronous write paths then calculate a writable size of zero and remain pending forever because window adjustments cannot satisfy a static zero packet maximum. An authenticated client can strand server writes, and a malicious server can strand client writes, allowing affected tasks, channels, and connections to accumulate without surfacing an error. This issue is fixed in version 0.65.0.

Details

Affected versions and vulnerable location

- Confirmed present on default branch main at HEAD 0089c89c94753bebbec12b956c07a1cd38740379. - Crate version at HEAD: 0.62.4. - Vulnerable locations on current default branch: - russh/src/server/mod.rs:91 (pub maxauthattempts: usize) - russh/src/server/mod.rs:121 (default maxauthattempts: 10) - russh/src/server/encrypted.rs:89 (USERAUTHREQUEST dispatch into auth handler path) - russh/src/server/encrypted.rs:98 (self.common.authattempts += 1) - russh/src/server/encrypted.rs:53 (only runtime read of authattempts, used for initial reject timing, not attempt limiting) - Default-branch history check did not show a newer merged commit adding enforcement against config.maxauthattempts.

Reachability trace verified

1. Entry point: exported server API server::runstream in russh/src/server/mod.rs:1049. 2. Session run loop in russh/src/server/session.rs processes incoming packets and calls reply(...) (server/session.rs:725). 3. reply forwards encrypted packets to session.serverreadencrypted(...) (server/mod.rs:1221). 4. serverreadencrypted routes USERAUTHREQUEST to enc.serverreadauthrequest(...) (server/encrypted.rs:89). 5. On each request, self.common.authattempts += 1 executes (server/encrypted.rs:98). 6. No comparison against self.common.config.maxauthattempts is present in this runtime flow.

PoC

Reproduction steps and observed output

I did not run a full server process in this environment because Rust tooling is unavailable. I verified the issue from source and command output on the audited tree.

1. Show where maxauthattempts appears:

bash rtk rg -n "maxauthattempts" .scratch/russh/russh/src/server/mod.rs .scratch/russh/russh/src/server/encrypted.rs .scratch/russh/russh/src/server/session.rs

Observed:

text .scratch/russh/russh/src/server/mod.rs:91: pub maxauthattempts: usize, .scratch/russh/russh/src/server/mod.rs:121: maxauthattempts: 10, .scratch/russh/russh/src/server/mod.rs:148: .field("maxauthattempts", &self.maxauthattempts)

2. Show runtime auth-attempt handling:

bash rtk rg -n "authattempts == 0|authattempts \\+= 1" .scratch/russh/russh/src/server/encrypted.rs

Observed:

text 53: let initialnonerejectionwaituntil = if self.common.authattempts == 0 { 98: self.common.authattempts += 1;

3. Show production entrypoint-to-auth path references:

bash rtk rg -n "pub async fn runstream|match reply\\(|serverreadencrypted\\(|serverreadauthrequest\\(" .scratch/russh/russh/src/server/mod.rs .scratch/russh/russh/src/server/session.rs .scratch/russh/russh/src/server/encrypted.rs

Observed:

text .scratch/russh/russh/src/server/encrypted.rs:89: enc.serverreadauthrequest( .scratch/russh/russh/src/server/session.rs:725: match reply(&mut self, &mut handler, &mut pkt).await { .scratch/russh/russh/src/server/mod.rs:1049:pub async fn runstream<H, R>( .scratch/russh/russh/src/server/mod.rs:1221: session.serverreadencrypted(handler, pkt).await

4. Toolchain check:

bash cargo --version

Observed:

text /bin/bash: line 1: cargo: command not found

Impact

Attacker model

- Attacker: unauthenticated remote client with TCP reachability to a russh-backed SSH service. - Preconditions: deployer expects server::Config.maxauthattempts to cap attempts. - Impact: repeated USERAUTHREQUEST attempts continue for a single connection beyond configured limit, increasing online guessing opportunity and backend auth workload.

Suggested fix

Enforce maxauthattempts in the USERAUTHREQUEST branch before invoking auth-method handlers, and fail closed once threshold is reached.

Concrete patch direction in russh/src/server/encrypted.rs:

rust if self.common.config.maxauthattempts > 0 && self.common.authattempts >= self.common.config.maxauthattempts { self.common.disconnect( Disconnect::NoMoreAuthMethodsAvailable, "Too many authentication attempts", "", )?; return Ok(()); }

How it was found and a note on tooling

The researcher synthesized three lens outputs, then revalidated each claim against current main: source presence and commit history, advisory overlap checks in both GitHub advisories and OSV, entrypoint-to-sink reachability, attacker-model realism, and execution-claim integrity. The researcher used gh, git, rg, and direct source inspection under .scratch/russh. Because Rust tooling is unavailable in this worker, this report is intentionally marked source-only.

AI assistance was used while investigating this and while drafting this report. The finding was verified by reading the cited code at HEAD. The vulnerability was not executed it, and that limit is stated plainly above rather than left implied.

Credits: arpitjain099.

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

Summary SshBlockCipher implementations (AES-CBC, AES-CTR, 3DES-CBC, etc.) report needsmac() == true, meaning they are documented/intended to always be paired with a separate integrity MAC. However, key-exchange negotiation only checks needsmac() inside the fallback branch of MAC algorithm selection (used when no common MAC algorithm exists). If both peers' preferred MAC lists simply contain none and it is successfully negotiated through the normal selection path, nothing rejects pairing none with a cipher that requires a MAC. Once negotiated, a single crafted packet from either peer causes cipher::read() to shrink an already-allocated buffer below the number of bytes it is about to index, causing a Rust slice-index-out-of-range panic and killing that connection's task.

Details In russh/src/cipher/mod.rs, read() for a block cipher: 1. Reads packetlengthtoreadforblocklength() bytes up front (16 bytes for any SshBlockCipher) into buffer.buffer. 2. Decrypts the first block to recover the plaintext packet-length field len. 3. Computes buffer.len = len + cipher.taglen(). 4. Calls buffer.buffer.resize(buffer.len + 4, 0). 5. Immediately indexes buffer.buffer[16..] (via the constant used for the first block read) to continue decrypting/reading the rest of the packet.

When the negotiated MAC is none, taglen() == 0. If the attacker (or a MITM holding the session key, or simply the accepting peer testing a hostile client) sends a packet whose decrypted length field is 0, then buffer.len = 0 and resize(0 + 4, 0) shrinks the buffer that was already grown to 16 bytes in step 1 down to 4 bytes. The subsequent slice operation buffer.buffer[16..] then panics with range start index 16 out of range for slice of length 4.

The file already defines a MINIMUMPACKETLEN constant, but it is only consulted on the write/padding side, never on the read path — so nothing prevents an incoming packet from declaring a length shorter than the bytes already buffered.

Negotiation gap: negotiation.rs's Select MAC-selection logic only special-cases needsmac() when negotiation would otherwise fail (no common MAC), substituting none only if the cipher does not need one. It never re-validates the case where none is a common/successfully-negotiated MAC on both sides regardless of what the chosen cipher requires. So an application (or a malicious peer, since negotiation is attacker-influenced on one side) that includes none in its own preferred MAC list — while still allowing the default CTR/CBC cipher suite — ends up with an invalid, panic-inducing combination that the library itself should refuse.

PoC 1. Configure one side's Preferred config to include mac::NONE in the MAC list (this is a supported, non-default configuration exposed by the crate's public Preferred API — used e.g. for legacy/interop compatibility), while leaving the default cipher list (which includes aes256-ctr/aes256-cbc) untouched. 2. Complete a normal key exchange; negotiation lands on {cipher: aes-ctr (or -cbc), mac: none} because none is present and preferred/common on both sides, and nothing during negotiation rejects this pairing. 3. From the peer, send one transport packet whose decrypted packet-length field is 0 (trivial to construct once the session keys are known to that peer, or for the peer that legitimately owns the connection to simply hand-craft, e.g. a modified client for testing). 4. cipher::read() on the receiving side panics: range start index 16 out of range for slice of length 4. 5. Because each connection is handled in its own tokio::spawn'ed task (see the per-connection select! loop that calls into cipher::read()), the panic unwinds only that task by default, but it unconditionally terminates that SSH connection/session — a working, currently-unauthenticated, already-established connection is killed with no attacker interaction beyond the one crafted packet, and the check runs on every inbound packet including pre-auth ones.

Impact Denial of service: a remote peer that can influence MAC preference negotiation (or a MITM in possession of the session key) can crash any individual SSH connection/session that ends up negotiating a block cipher together with mac=none, with a single crafted packet, pre-authentication. This does not affect the process as a whole (panic is scoped to that connection's task under panic=unwind), and does require a non-default configuration that permits none as a preferred MAC — hence Low severity.

Suggested fix In the MAC-selection logic in negotiation.rs, reject (or force substitution of) mac::NONE whenever the negotiated cipher's needsmac() is true, regardless of how none came to be selected — not only in the "no common MAC" fallback branch. Defensively, cipher::read() could also refuse to shrink a buffer below the number of bytes already consumed for the length-field block, returning a protocol error instead of resizing blindly.

For credit/changelog purposes, please use: Yazan Balawneh, Cystack.ps

Summary

A russh server can be driven to unbounded heap growth (process OOM / kill) by a peer that speaks only standard SSH messages, in the default configuration.

The peer starts a key re-exchange (sends SSHMSGKEXINIT) but never sends the follow-up SSHMSGKEXECDHINIT, leaving the server's kex state machine in SessionKexState::InProgress indefinitely. While a rekey is in progress the server's three message-drain paths are all gated off (if !self.kex.active()), but the network-read path stays active, so every SSHMSGCHANNELOPEN the peer sends is processed inline and appends one reply to an unbounded internal queue (priorityreceiver, an UnboundedReceiver) that is not dequeued until the rekey completes. Because the peer decides whether the rekey ever completes, the queue — and the server's memory — grows without bound.

This is reproducible end-to-end against a real russh server over a real encrypted transport; see "Proof of concept". A one-line negative control (same flood, no rekey) keeps memory flat, isolating the rekey window as the sole trigger.

Impact

- Availability / DoS. Server RSS climbs at roughly 3.3 KB per CHANNELOPEN, driven entirely by the peer, until the process is OOM-killed. In the reproduction one connection pushed the server from ~4 MB to 2.57 GB (and past 4.8 GB against the stock echoserver example) and it was still climbing when the flood was stopped. - Reached with standard messages, no special configuration. Any handler is affected, including one that rejects every channel (the reply enqueued on rejection is exactly what accumulates). There is no per-connection cap on in-flight channel opens or on the queue, and the queue's sender has no backpressure. - The peer keeps the connection alive simply by continuing to send, so the inactivity timer never fires.

Affected component

- russh/src/server/session.rs — Session::run tokio::select! loop. The network-read arm is ungated; the three drain paths are gated on !self.kex.active(). - russh/src/server/mod.rs — reply() routes a non-kex message received during a rekey straight to serverreadencrypted (inline processing). - russh/src/libinner.rs — ChannelOpenHandleInner's accept/reject/Drop all send a reply on an UnboundedSender.

Verified on v0.63.1 (commit d3ae702), which is the latest release. The gating logic predates it.

Details

Session::run (russh/src/server/session.rs:631) drives a tokio::select! (:713). Three of its message-drain sites are gated on !self.kex.active():

- the pre-select! batch drain of priorityreceiver/receiver (session.rs:680), - the priorityreceiver.recv() arm (session.rs:762), - the receiver.recv() arm (session.rs:770, which also holds the only other priorityreceiver drain at :777).

The fourth arm, r = &mut reading (session.rs:714), is ungated: it reads and processes one incoming packet every loop iteration regardless of rekey state, calling reply() (server/mod.rs:1128).

During a rekey, session.common.encrypted.issome(), so the strict-kex message-ordering guard (server/mod.rs:1143, which is additionally gated on encrypted.isnone()) does not apply. A non-kex message therefore falls through reply() to session.serverreadencrypted(handler, pkt) (server/mod.rs:1232) and is handled inline. For SSHMSGCHANNELOPEN this reaches the channel-open handling, which hands the application a ChannelOpenHandle.

Whether the handler accepts or (the trait default) rejects, the handle's accept / reject / Drop all send a Msg::ChannelOpenReply on an UnboundedSender (russh/src/libinner.rs:560-603; Drop sends AdministrativelyProhibited at :594-603). That sender feeds priorityreceiver, declared UnboundedReceiver<Msg> (session.rs:23) and created with tokio::sync::mpsc::unboundedchannel() (session.rs:1522). Its only drain sites are the three arms gated off during the rekey. So each CHANNELOPEN processed during the rekey window appends one reply (carrying a PendingChannelOpen = channel params + mpsc ChannelRef + ids, a few KB retained in practice) to a queue that is never dequeued.

Two facts make this unbounded and remote:

1. The server enters InProgress the moment it receives the peer's KEXINIT (server/mod.rs:1153-1158, beginrekey) and only leaves it upon receiving the peer's KEXECDHINIT. The peer decides whether to ever send that, so the window is attacker-held. 2. There is no per-connection cap on channels or on the priority queue, and the sender is unbounded (no backpressure).

Root cause

The intended design was to buffer packets received during a rekey and replay them afterwards: the fields pendingreads: Vec<Vec<u8>> and pendinglen: u32 (session.rs:26-27) exist and are drained at kex completion (server/mod.rs:1194-1198). But nothing ever pushes to pendingreads or increments pendinglen (they are dead — confirmed by grep across russh/src/). Instead of being buffered, channel messages received during a rekey are processed inline, and their replies pile up in the unbounded priorityreceiver. The missing piece is a bound on — or bounded deferral of — channel processing while kex.active().

Proof of concept

Everything runs inside a container; nothing touches the host.

Lab. poc/Dockerfile builds russh-lab:head from Eugeny/russh @ d3ae702 (v0.63.1), default features (rust 1.91). A raw-SSH-client PoC (poc/pocrekeydos.rs) implements curve25519-sha256 / ssh-ed25519 / aes256-ctr / hmac-sha2-256 by hand, completes the handshake and a publickey auth, then:

1. sends SSHMSGKEXINIT (server enters kex.active()), 2. never sends KEXECDHINIT (rekey stalls, attacker-held), 3. floods SSHMSGCHANNELOPEN.

A minimal server (poc/pocserver.rs) uses the trait-default channelopensession (which rejects by dropping the handle), so the measured growth is purely the undrained priority queue, not accepted-channel state.

poc/run.sh runs the attack leg and an identical negative control with no rekey. Fresh run inside the lab, N = 800,000 opens (results/rerun-2026-08-29.log):

=== ATTACK (rekey stall) === (pocserver baselineRSS=4208KB, N=800000) t=2s serverRSS=667760KB t=4s serverRSS=1599600KB t=6s serverRSS=2556016KB t=8s serverRSS=2566256KB (flood done; memory retained) === CONTROL (no rekey) === (pocserver baselineRSS=4208KB, N=800000) t=2s..t=12s serverRSS=4208KB (flat throughout)

- ATTACK: RSS 4,208 KB → 2,566,256 KB (~2.57 GB) and retained after the flood ends — ~3.3 KB per CHANNELOPEN, attacker-driven. (An earlier canonical run reached 2.7 GB at 800k opens, and past 4.8 GB against the stock echoserver example at 1.5 M opens — see results/canonical-run.log.) - CONTROL: RSS flat at 4,208 KB. Without the rekey window the replies are drained normally; TCP backpressure (the client never reads the failure replies) even throttles the flood.

The control isolates the rekey window as the sole trigger. Both legs exercise the real server entry point (Session::run → reply → serverreadencrypted) over a real encrypted transport.

Reproduce: C=russh-lab N=800000 ./poc/run.sh (see poc/POC-README.md).

Remediation

The priority queue carries locally generated channel-open replies, which are non-kex messages the server must not send during a rekey anyway (RFC 4253 §7.1). So the fix is to bound how much channel work is done during a rekey, not to drain the queue mid-rekey. Any of:

- (recommended, minimal) cap the number of non-kex messages processed while a rekey is in progress and disconnect a peer that exceeds it. A stalled/abusive rekey is then torn down after a small constant instead of growing memory without bound. See patch/rekey-message-cap.patch (a ~10-line change local to Session::run, validated in the lab — the attack leg is disconnected after the cap and RSS stays flat; a normal rekey, which completes in one round trip, is unaffected). - bound / deferred-buffer channel messages during a rekey using the existing (currently dead) pendingreads/pendinglen machinery, with a hard cap. - bound the number of in-flight channel opens per connection and reject beyond it.

OpenSSH does not service new channels mid-kex; matching that intent closes the whole family.

Summary In the russh client keyboard-interactive authentication path, a malicious SSH server could send a USERAUTHINFOREQUEST with an attacker-controlled prompt count, and the client would use that raw count directly in Vec::withcapacity(...) before validating that enough prompt data was actually present in the packet.

This is a client-side denial-of-service / resource-exhaustion issue on the keyboard-interactive auth path.

Details The vulnerable code path is in:

- russh/src/client/encrypted.rs

When the client is in CurrentRequest::KeyboardInteractive state and receives SSHMSGUSERAUTHINFOREQUEST, it parses:

1. name 2. instructions 3. language tag 4. nprompts

Before the fix, the code then did:

rust let nprompts = maperr!(u32::decode(&mut r))?; let mut prompts = Vec::withcapacity(nprompts.tryinto().unwrapor(0));

That means a malicious server could advertise an enormous nprompts value even if the packet contained no prompt bodies at all.

The fix rejects inconsistent prompt counts before allocating:

rust let nprompts = maperr!(u32::decode(&mut r))?; let maxprompts = r.remaininglen() / 5; let nprompts = nprompts as usize; if nprompts > maxprompts { return Err(crate::Error::Inconsistent.into()); } let mut prompts = Vec::withcapacity(nprompts);

Each prompt needs at least 4 bytes of string length plus 1 byte of echo flag, so remaininglen() / 5 is a safe upper bound. If the declared count exceeds what the packet can actually contain, the packet is malformed and is now rejected instead of being silently truncated.

The tester did not find a same-class server-side bug in the reciprocal USERAUTHINFORESPONSE path. The server already bounds the response count by remaining packet length before allocating.

Affected package and versions:

- package: russh - earliest affected stable: 0.37.0 - confirmed affected current release: 0.60.2

The tester does not believe this issue affects the other crates in this workspace (russh-config, russh-cryptovec, pageant, or russh-util).

PoC An in-tree regression test was added:

- client::tests::oversizedkeyboardinteractivepromptcountisrejected

The test builds a client session in WaitingAuthRequest(KeyboardInteractive) state, feeds it a synthetic USERAUTHINFOREQUEST packet with:

- normal name - normal instructions - empty language tag - nprompts = u32::MAX - no prompt bodies

On the fixed code, the client rejects the packet with Error::Inconsistent and does not emit a reply to the caller.

For old-code impact verification, the pre-fix path was also checked separately with a constrained-memory repro. On unfixed upstream/main, the same malformed packet attempted a very large allocation and failed with:

text memory allocation of 137438953440 bytes failed

Relevant verification commands:

bash cargo test -p russh oversizedkeyboardinteractivepromptcountisrejected -- --nocapture cargo test -p russh --lib --no-default-features --features ring oversizedkeyboardinteractivepromptcountisrejected -- --nocapture

Impact Suggested CVSS v3.1:

- CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H - Score: 6.5

Reasoning:

- AV:N: reached by a malicious SSH server over the network - AC:L: the packet format is straightforward - PR:N: no prior authentication required - UI:R: the victim must initiate a connection and proceed into keyboard-interactive auth - C:N, I:N: Confidentiality or integrity impact were not demonstrated - A:H: the server can drive a very large allocation attempt in the client auth path, which can abort or exhaust client-side resources depending on allocator and platform behavior