CVE-2026-102824 in Russh
Summary
by MITRE • 09/29/2026
Russh is a Rust SSH client and server library. Prior to 0.63.0, the hybrid ML-KEM 768 and X25519 implementation in russh/src/kex/hybrid_mlkem.rs accepts an all-zero 32-byte peer X25519 public key in both server_dh and compute_shared_secret, forcing the X25519 contribution to the combined shared secret to zero. A malicious SSH peer can therefore make the combined secret depend only on ML-KEM, defeating the hybrid exchange's intended fallback protection if ML-KEM is later weakened. This issue is fixed in version 0.63.0.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/29/2026
The vulnerability identified in Russh versions prior to 0.63.0 represents a critical failure in cryptographic key agreement logic within an SSH implementation written in Rust. The core of the issue lies in the hybrid Key Exchange (KEX) mechanism, specifically involving the combination of ML-KEM-768 and X25519 algorithms. Hybrid KEX schemes are designed to provide forward secrecy by combining two distinct cryptographic primitives, ensuring that if one algorithm is compromised or broken in the future, the other may still protect the session key. In this specific implementation, the function responsible for processing peer public keys fails to validate the mathematical validity of the X25519 component. Specifically, it accepts an all-zero 32-byte value as a valid X25519 public key in both the server_dh and compute_shared_secret routines. This lack of validation allows a malicious SSH peer to inject this invalid zero-value public key into the handshake process.
From a technical perspective, the acceptance of an all-zero public key results in the scalar multiplication operation yielding a point at infinity or effectively contributing zero entropy to the shared secret derivation. Consequently, the combined shared secret becomes dependent solely on the ML-KEM component of the hybrid exchange. This defeats the fundamental purpose of the hybrid approach, which is to ensure that the security of the session does not rely entirely on the strength of any single algorithm. If an attacker can break or weaken ML-KEM through cryptanalytic advances or quantum computing capabilities in the future, they would be able to derive the shared secret because the X25519 contribution provided no additional secrecy or protection. This scenario effectively reduces a robust hybrid cryptographic exchange into a single-algorithm exchange with known weaknesses, undermining the forward secrecy guarantees that SSH relies upon for secure remote access.
The operational impact of this vulnerability is severe in environments where Russh is used as an SSH server or client library handling untrusted connections. An attacker positioned on the network path can exploit this flaw to perform a downgrade attack against the key exchange process. By forcing the X25519 contribution to zero, the attacker ensures that the session keys are derived primarily from ML-KEM parameters. This weakens the overall security posture of the connection, making it potentially susceptible to future cryptanalytic attacks targeting lattice-based cryptography like ML-KEM. Furthermore, this flaw violates the principle of defense in depth by removing one layer of cryptographic protection intended to safeguard against algorithmic obsolescence or breakthroughs. The vulnerability is classified under CWE-295 Improper Certificate Validation and CWE-327 Use of a Broken or Risky Cryptographic Algorithm, as it involves accepting invalid public keys that compromise the integrity of the key exchange protocol.
In terms of threat modeling, this exploitation aligns with ATT&CK technique T1486 Data Encrypted for Impact, although more accurately it relates to T1502 Use of Alternate Authentication Methods or general cryptographic bypasses where an attacker manipulates authentication parameters to weaken security controls. The flaw allows a malicious peer to manipulate the key derivation process without necessarily breaking the encryption immediately but by ensuring that future compromises of ML-KEM will directly expose session data. This is particularly dangerous because SSH sessions often carry sensitive administrative commands and data, making forward secrecy crucial for long-term confidentiality even if keys are eventually exposed.
To mitigate this vulnerability, organizations using Russh must upgrade to version 0.63.0 or later immediately. The fix involves implementing strict validation checks on the received X25519 public key to ensure it is not an all-zero value and conforms to standard elliptic curve point representations before being used in shared secret computations. Developers integrating this library should verify that their build pipelines enforce minimum version requirements for Russh dependencies. Additionally, security teams should review configurations involving SSH servers built with older versions of Russh and consider temporary network-level restrictions or intrusion detection rules to monitor for anomalous key exchange patterns indicative of such exploitation attempts until the software is updated. Regular audits of cryptographic implementations against current standards are recommended to prevent similar logical flaws in hybrid schemes where input validation is critical to maintaining security guarantees.