Russh CVE-2026-102821

Requires an authenticated remote peer to a russh server (or client) prior to 0.63.2 (PR:L). The attacker then abuses the rekey state machine: send SSH_MSG_KEXINIT but never send the required SSH_MSG_KEX_ECDH_INIT so the session stays in SessionKexState::InProgress and priority_receiver in russh/src/server/session.rs is never drained, then flood SSH_MSG_CHANNEL_OPEN messages whose ChannelOpenReply entries pile up on an unbounded channel until memory is exhausted. The primary limiting factor is that valid authentication is required first - this is not reachable pre-auth - so exposure scales with how trusted the server's authenticated user population is; no user interaction, no special non-default configuration, and no platform constraint beyond running an affected russh version (<0.63.2) apply.

This is a legitimate but moderate-priority availability issue. The CVSS 3.1 vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H (base 6.5) is internally consistent with the description: network-reachable (AV:N), low complexity (AC:L, a deterministic protocol-state abuse requiring no race), no user interaction, and pure availability impact (A:H) with no confidentiality or integrity loss. Critically, PR:L confirms the attacker must FIRST be an authenticated remote peer - the description explicitly says 'an authenticated remote peer,' so this is NOT an unauthenticated pre-auth DoS. That materially narrows the threat: an attacker needs valid credentials (or a permitted auth method) on the russh server before the memory-exhaustion primitive is reachable. No EPSS score, no CISA KEV listing, and no standalone weaponized exploit were provided, so exploitation status is: no public exploit identified at time of analysis. However, the fixing commit ships a regression test (channel_open_after_peer_kexinit_during_rekey_is_rejected) that demonstrates the exact trigger sequence, so a working reproduction path is effectively documented in the source tree even though it is not packaged as a public PoC. Signals are not conflicting: every source (description, CWE-400 resource exhaustion, CVSS A:H-only vector, tag 'Denial Of Service') agrees this is a memory-exhaustion DoS. The main gap between raw CVSS and real-world risk is the PR:L gate - for servers that only admit trusted authenticated users, real risk is low; for servers exposing russh to semi-trusted or large user populations, a single authenticated connection killing the process is a genuine availability concern.

An attacker who has authenticated to a russh-based SSH server initiates a key re-exchange by sending SSH_MSG_KEXINIT but deliberately withholds the follow-up SSH_MSG_KEX_ECDH_INIT, parking the session in SessionKexState::InProgress. While the priority_receiver is thus never drained, the attacker floods SSH_MSG_CHANNEL_OPEN messages; the server keeps enqueuing a ChannelOpenReply for each onto an unbounded channel, driving process memory up until the OS terminates it. No public exploit is packaged, but the fix commit includes a test reproducing the stalled-rekey-plus-channel-flood sequence.