Listen to this Post
A russh server can be driven to unbounded heap growth.
The peer speaks only standard SSH messages.
Default configuration is affected.
The peer starts a key re-exchange.
It sends SSH_MSG_KEXINIT.
It never sends SSH_MSG_KEX_ECDH_INIT.
The server enters SessionKexState::InProgress.
The server remains there indefinitely.
The peer controls whether rekey completes.
During rekey, three drain paths are gated off.
They are gated by if !self.kex.active().
The network-read path remains active.
Each SSH_MSG_CHANNEL_OPEN is processed inline.
Each open appends one reply to priority_receiver.
priority_receiver is an UnboundedReceiver.
It is not dequeued until rekey completes.
The peer decides rekey completion.
The queue grows without bound.
Server memory grows without bound.
This is reproducible end-to-end.
It uses a real russh server.
It uses a real encrypted transport.
A negative control uses same flood without rekey.
Control keeps memory flat.
Control isolates rekey window as trigger.
Impact is availability / DoS.
RSS climbs about 3.3 KB per CHANNEL_OPEN.
Process is OOM-killed.
One connection pushed server from ~4 MB to 2.57 GB.
Stock echoserverexample passed 4.8 GB.
No special configuration is needed.
Any handler is affected.
Rejecting every channel still accumulates replies.
No per-connection cap exists.
No queue backpressure exists.
Peer keeps connection alive by sending.
Inactivity timer never fires.
DailyCVE Form:
Platform: russh
Version: v0.63.1
Vulnerability: rekey unbounded queue
Severity: High
date: 2026-08-29
Prediction: not stated
(end of form)
What Undercode Say:
Analytics
C=russh-lab N=800000 ./poc/run.sh
poc/Dockerfile poc/poc_rekey_dos.rs poc/poc_server.rs poc/run.sh results/rerun-2026-08-29.log results/canonical-run.log patch/rekey-message-cap.patch
grep -R "pending_reads|pending_len" russh/src/
tokio::sync::mpsc::unbounded_channel()
UnboundedReceiver<Msg>
!self.kex.active()
Session::run → reply → server_read_encrypted
Exploit: (Educational Purposes!)
send SSH_MSG_KEXINIT never send SSH_MSG_KEX_ECDH_INIT flood SSH_MSG_CHANNEL_OPEN
poc/poc_rekey_dos.rs implements curve25519-sha256 / ssh-ed25519 / aes256-ctr / hmac-sha2-256 completes handshake and publickey auth then sends SSH_MSG_KEXINIT then never sends KEX_ECDH_INIT then floods SSH_MSG_CHANNEL_OPEN
channel_open_session // trait-default rejects by dropping handle
Protection:
patch/rekey-message-cap.patch cap non-kex messages during rekey disconnect peer exceeding cap bound/defer channel messages using pending_reads/pending_len with hard cap bound in-flight channel opens per connection match OpenSSH no new channels mid-kex
Impact:
~3.3 KB per CHANNEL_OPEN 4,208 KB → 2,566,256 KB past 4.8 GB against stock echoserverexample OOM-kill availability / DoS
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
