https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 01 Oct 2026 21:50:41 +0000 https://vulnerability.circl.lu/vuln/fkie_cve-2026-102821 <p>Russh is a Rust SSH client and server library. Prior to 0.63.2, an authenticated remote peer can send SSH_MSG_KEXINIT without the required SSH_MSG_KEX_ECDH_INIT and then flood SSH_MSG_CHANNEL_OPEN messages while SessionKexState::InProgress prevents priority_receiver in russh/src/server/session.rs from being drained. The server continues processing network input and enqueues a ChannelOpenReply for each request on an unbounded channel, allowing one connection to grow memory until the process is terminated. This issue is fixed in version 0.63.2.</p> <p>Russh is a Rust SSH client and server library. Prior to 0.63.2, an authenticated remote peer can send SSH_MSG_KEXINIT without the required SSH_MSG_KEX_ECDH_INIT and then flood SSH_MSG_CHANNEL_OPEN messages while SessionKexState::InProgress prevents priority_receiver in russh/src/server/session.rs from being drained. The server continues processing network input and enqueues a ChannelOpenReply for each request on an unbounded channel, allowing one connection to grow memory until the process is terminated. This issue is fixed in version 0.63.2.</p> https://vulnerability.circl.lu/vuln/fkie_cve-2026-102821 https://vulnerability.circl.lu/vuln/ghsa-35g8-35p8-c8fw <p><strong>Affected:</strong> crates.io: russh</p> <p>## Summary</p> <p>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**.</p> <p>The peer starts a key re-exchange (sends `SSH_MSG_KEXINIT`) but never sends the follow-up `SSH_MSG_KEX_ECDH_INIT`, leaving the server&#39;s kex state machine in `SessionKexState::InProgress` **indefinitely**. While a rekey is in progress the server&#39;s three message-drain paths are all gated off (`if !self.kex.active()`), but the network-read path stays active, so every `SSH_MSG_CHANNEL_OPEN` the peer sends is processed inline and appends one reply to an **unbounded** internal queue (`priority_receiver`, an `UnboundedReceiver`) that is not dequeued until the rekey completes. Because the peer decides whether the rekey ever completes, the queue — and the server&#39;s memory — grows without bound.</p> <p>This is reproducible end-to-end against a real russh server over a real encrypted transport; see &#34;Proof of concept&#34;. A one-line negative control (same flood, no rekey) keeps memory flat, isolating the rekey window as the sole trigger.</p> <p>## Impact</p> <p>- **Availability / DoS.** Server RSS climbs at roughly 3.3 KB per `CHANNEL_OPEN`, 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,…</p> <p><strong>Affected:</strong> crates.io: russh</p> <p>## Summary</p> <p>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**.</p> <p>The peer starts a key re-exchange (sends `SSH_MSG_KEXINIT`) but never sends the follow-up `SSH_MSG_KEX_ECDH_INIT`, leaving the server&#39;s kex state machine in `SessionKexState::InProgress` **indefinitely**. While a rekey is in progress the server&#39;s three message-drain paths are all gated off (`if !self.kex.active()`), but the network-read path stays active, so every `SSH_MSG_CHANNEL_OPEN` the peer sends is processed inline and appends one reply to an **unbounded** internal queue (`priority_receiver`, an `UnboundedReceiver`) that is not dequeued until the rekey completes. Because the peer decides whether the rekey ever completes, the queue — and the server&#39;s memory — grows without bound.</p> <p>This is reproducible end-to-end against a real russh server over a real encrypted transport; see &#34;Proof of concept&#34;. A one-line negative control (same flood, no rekey) keeps memory flat, isolating the rekey window as the sole trigger.</p> <p>## Impact</p> <p>- **Availability / DoS.** Server RSS climbs at roughly 3.3 KB per `CHANNEL_OPEN`, 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,…</p> https://vulnerability.circl.lu/vuln/ghsa-35g8-35p8-c8fw