russh EUVD-2026-111389

Server-side (authenticated remote DoS): an authenticated client (PR:L) opens a session channel advertising maximum_packet_size = 0, and the server application must write to that channel via the AsyncWrite path specifically - Channel::data(), Channel::make_writer(), or Channel::into_stream(); the *_bytes write variants are NOT affected because they already enforce the Error::Inconsistent guard. Client-side: a malicious or buggy server confirms the channel (CHANNEL_OPEN_CONFIRMATION) with maximum_packet_size = 0, stalling the client's writes. LIMITING FACTORS: the server path requires valid authentication; exploitation only strands tasks if the application uses the AsyncWrite API rather than the guarded *_bytes calls; and affected versions are strictly 0.60.0-0.64.1. Note that the server inactivity_timeout (default 600 s) is reset by keep-alive traffic so stranded resources persist, and the client inactivity_timeout defaults to None so nothing tears a stalled client session down - both factors extend, rather than limit, the impact.

This is a genuine but moderate-priority availability issue, not a critical emergency. The CVSS vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L (NVD base 4.3) describes a network-reachable, low-complexity flaw requiring low privileges and no user interaction, with no confidentiality or integrity impact - consistent with the authenticated-client-against-server scenario. Note a signal conflict on impact magnitude: the vendor GHSA-fw5c-8223-6h42 scores the same vector with A:H (6.5, medium) because stranded tasks/channels/connections accumulate silently into resource exhaustion, while NVD uses A:L (4.3); the A:H reading is better supported by the CWE-400/CWE-835 mechanism and the permanent, non-self-healing nature of the stall. No EPSS score was provided, so exploitation probability cannot be quantified. The issue is NOT on CISA KEV and there is no confirmed public exploit; the vuln.today Decision label is this_month, indicating scheduled remediation rather than emergency action. Overall: a real, easy-to-trigger DoS against a niche Rust library - worth patching on a normal cycle, but lacking the exploitation-in-the-wild or confidentiality/integrity signals that would make it urgent.

An authenticated client opens a session channel to a russh-based server and advertises maximum_packet_size = 0 in CHANNEL_OPEN; when the server application later writes to that channel through the AsyncWrite path (Channel::data, make_writer, or into_stream - the pattern used by russh's own echo/SFTP examples), the write future parks in ChannelTx::poll_writable and never completes or errors, silently stranding the handler task. The same works in reverse: a malicious server confirms a channel with maximum_packet_size = 0 to permanently stall a client's writes. No public exploit code is published, but the advisory documents a reproducer verified end-to-end against stock russh v0.64.1 (default config plus a single maximum_packet_size = 0 toggle), and AC:L/PR:L confirm the trigger is trivial for any authenticated peer.