CVE-2026-128087

### Summary A malicious SSH server whose host key is rejected can still cause russh's `client::Handler::kex_done()` callback to execute with the raw key-exchange shared secret. Applications using the callback for its documented protocol-bridging purpose may derive keys, initialize a secondary data channel, or perform another externally visible action before russh calls `check_server_key()` and rejects the server. ### Details During the initial key exchange, russh calls `kex_done()` immediately after the server proves possession of the presented host key, but before the application decides whether that key belongs to the intended server: ```rust let shared_secret = newkeys.kex.shared_secret_bytes(); handler .kex_done(shared_secret, &newkeys.names, session) .await?; // Initial KEX only checks trust afterwards. if let Some(certificate) = server_host_certificate { if !handler.check_server_key(&certificate.into()).await? { return Err(crate::Error::UnknownKey.into()); } } else if let Some(server_host_key) = server_host_key { let check = handler.check_server_key(&server_host_key.into()).await?; if !check { return Err(crate::Error::UnknownKey.into()); } } ``` This is in `russh/src/client/mod.rs` at lines 2036-2078 of commit `183a22e8f8f490fa09b6eb7bd044ef99d8c4414f`. The API documentation describes `check_server_key()` as the important trust decision that prevents man-in-the-middle attacks. It describes `kex_done()` as the callback for deriving keys for secondary encrypted channels. The feature request that introduced the callback specifically lists VPN-over-SSH, UDP data planes, file transfer, and custom enterprise transports as intended uses. Cryptographic verification of the KEX signature does not establish peer identity: an attacker operating its own SSH server can always produce a valid signature with its own host key. Identity is established only when `check_server_key()` accepts that key or certificate. ### Expecte