Russh CVE-2026-102824

Requires the russh peer to negotiate the hybrid ML-KEM-768 + X25519 key exchange (the mlkem768x25519 method in kex/hybrid_mlkem.rs) with a version prior to 0.63.0; the attacker must be the remote SSH peer (server or client) able to send the KEX_ECDH_INIT/reply with an all-zero X25519 public key. No authentication or user interaction is needed since the flaw triggers during key exchange. The critical LIMITING factor is that there is NO actual confidentiality impact unless and until ML-KEM-768 is independently weakened - today this only removes the classical safety net, making it a latent/theoretical exposure rather than a practical decryption vector.

This is a genuine cryptographic weakness but a low real-world priority. The CVSS 3.1 base score of 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) reflects only a partial confidentiality impact, and even that is contingent on a future event that has not occurred. The core flaw (CWE-327) is that russh's hybrid ML-KEM-768 + X25519 key exchange accepts an all-zero (low-order) X25519 public key, zeroing out the classical contribution so the combined secret depends solely on ML-KEM. This defeats the entire point of a hybrid exchange - the classical curve is supposed to remain a safety net if the post-quantum primitive is broken - but it produces NO immediate compromise while ML-KEM-768 remains sound. There is no EPSS score, no CISA KEV listing, and no public exploit identified at time of analysis, so this is best characterized as a defense-in-depth / future-proofing fix rather than an actively exploitable bug. Signal conflict to note: the vendor vector uses PR:L, but SSH key exchange occurs pre-authentication, so a malicious peer needs no credentials - PR:N is arguably more accurate, which would raise the base score to ~5.3; I flag this as a metric disagreement, not a factual claim. Overall, real priority is LOW: patch on the normal maintenance cycle.

A malicious SSH server (or client) that russh connects to during the hybrid ML-KEM-768/X25519 key exchange sends an all-zero 32-byte X25519 public key. russh accepts it, so the X25519 contribution to the combined shared secret collapses to zero and the session's security rests entirely on ML-KEM-768. No confidentiality loss occurs today; the harm only materializes if ML-KEM-768 is later cryptanalytically weakened, at which point such a session would have no classical fallback. No public exploit code exists.