GHSA-G9HV-X236-4QP3

Russh: client wrong-length X25519 clonefromslice panic (pre-auth DoS)

cd vuln_poc/vuln_002_client_wronglen_x25519_panic
cargo run --release

[poc] panic captured: panicked at russh/src/kex/curve25519.rs:113:25:
  copy_from_slice: source slice length (16) does not match destination slice length (32)
[!] Vulnerability reproduced: russh client panicked in Curve25519Kex::compute_shared_secret
  on a wrong-length (16-byte) server ephemeral before verifying the host key signature
  (pre-auth client DoS).

MSG_KEX_ECDH_REPLY (1 byte, value 0x1f)
  string K_S            (server host key blob, any valid-looking bytes)
  string f              (server ephemeral, 16 bytes of 0x00 instead of 32)
  string signature      (fake; never verified by the client)

What kind of vulnerability: CWE-704 (incorrect type conversion / cast ,
clone_from_slice length mismatch) → deterministic panic → pre-authentication
per-connection Denial-of-Service. The attacker does not need the server's
private key; any network position that can deliver a malformed
KEX_ECDH_REPLY (a rogue server, or a MitM before authentication) suffices.

Who is impacted: any deployment that uses russh::client::connect (or
connect_stream) to connect to an attacker-controlled or MitM-reachable SSH
server, and that negotiates curve25519-sha256 (the default and
most-preferred kex algorithm in russh). A single malformed
KEX_ECDH_REPLY kills the client session; the attack is deterministic and
single-packet. The panic is isolated to the spawned session task
(tokio::spawn catches it and surfaces a JoinError), so the embedding
process keeps running, the impact is per-connection DoS, not process crash,
unless the embedder installs a custom panic hook that calls
std::process::abort.

Workaround: until a fix is released, clients can reduce exposure by
disabling curve25519-sha256 in the Preferred::kex list and preferring a
kex algorithm whose peer-ephemeral length is validated (e.g. the ECDH-NIST
or DH/GEX paths). This is a mitigation, not a fix.

Suggested fix (one-line length check, mirrors the existing server-side
server_dh check):

// russh/src/kex/curve25519.rs, at the top of compute_shared_secret:
fn compute_shared_secret(&mut self, remote_pubkey_: &[u8]) -> Result<(), crate::Error> {
    if remote_pubkey_.len() != 32 {
        return Err(crate::Error::Kex);
    }
    let local_secret = self.local_secret.take().ok_or(crate::Error::KexInit)?;
    let mut remote_pubkey = MontgomeryPoint([0; 32]);
    remote_pubkey.0.clone_from_slice(remote_pubkey_);
    let shared = local_secret * remote_pubkey;
    self.shared_secret = Some(shared);
    Ok(())
}

This makes the client-side compute_shared_secret consistent with the
existing server-side server_dh check at russh/src/kex/curve25519.rs:61-65
and with the other kex paths that already validate peer ephemeral lengths.

vuln_poc.zip

GHSA-G9HV-X236-4QP3 has a CVSS score of 5.3 (Medium). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.62.4); upgrading removes the vulnerable code path.

Kodem intelligence

Already deployed Kodem?

1. What is GHSA-G9HV-X236-4QP3? GHSA-G9HV-X236-4QP3 is a medium-severity security vulnerability in russh (rust), affecting versions <= 0.62.3. It is fixed in 0.62.4.
2. How severe is GHSA-G9HV-X236-4QP3? GHSA-G9HV-X236-4QP3 has a CVSS score of 5.3 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of russh are affected by GHSA-G9HV-X236-4QP3? russh (rust) versions <= 0.62.3 is affected.
4. Is there a fix for GHSA-G9HV-X236-4QP3? Yes. GHSA-G9HV-X236-4QP3 is fixed in 0.62.4. Upgrade to this version or later.
5. Is GHSA-G9HV-X236-4QP3 exploitable, and should I be worried? Whether GHSA-G9HV-X236-4QP3 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether GHSA-G9HV-X236-4QP3 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix GHSA-G9HV-X236-4QP3? Upgrade russh to 0.62.4 or later.

Other vulnerabilities in russh