Source: rust-russh Version: 0.57.1-2 Severity: grave Tags: security upstream Justification: user security hole X-Debbugs-Cc: [email protected], Debian Security Team <[email protected]>
Hi, The following vulnerabilities were published for rust-russh. CVE-2026-42189[0]: | Russh is a Rust SSH client & server library. Prior to version | 0.60.1, a pre-authentication denial-of-service vulnerability exists | in the server's keyboard-interactive authentication handler. A | malicious client can crash any russh-based server that implements | keyboard-interactive auth (e.g., for 2FA/TOTP) with a single | malformed packet, requiring no credentials. This issue has been | patched in version 0.60.1. CVE-2026-46673[1]: | Russh is a Rust SSH client & server library. Prior to version | 0.60.3, CryptoVec used unchecked capacity growth, unchecked length | arithmetic, and unsafe allocation/locking paths. In current russh | releases, local SSH agent peers could still feed attacker-controlled | frame lengths into buffer growth before validation. In older russh | releases before 0.58.0, remote SSH traffic also reached CryptoVec | through transport and compression buffers. This issue has been | patched in version 0.60.3. CVE-2026-46702[2]: | Russh is a Rust SSH client & server library. From version 0.34.0 to | before version 0.61.1, when SSH compression is enabled, russh | accepted compressed packets whose on-wire size passed the normal | transport packet-length checks but whose decompressed size was much | larger. This allowed a remote peer to send oversized post- | decompression packets that should have been rejected. In current | releases, this is a remote denial-of-service / resource-exhaustion | issue in the post-decompression receive path. In older releases | before 0.58.0, the same remote decompression path used CryptoVec, | which appears to make the historical impact worse. This issue has | been patched in version 0.61.1. CVE-2026-46705[3]: | Russh is a Rust SSH client & server library. From version | 0.34.0-beta.1 to before version 0.61.0, the russh server | authentication path keeps internal userauth state across | SSH_MSG_USERAUTH_REQUEST messages without separating that state when | the request principal changes. RFC 4252 allows the user name and | service name fields to change between authentication requests. The | issue is not that such changes are invalid. The issue is that russh- | owned authentication state, such as remaining methods, partial- | success state, and in-progress method state, can remain associated | with the connection and then influence a later request for a | different (user, service). This is an internal library state | mismatch. This issue has been patched in version 0.61.0. CVE-2026-48107[4]: | Russh is a Rust SSH client & server library. From version 0.37.0 to | before version 0.61.0, in the russh client keyboard-interactive | authentication path, a malicious SSH server could send a | USERAUTH_INFO_REQUEST with an attacker-controlled prompt count, and | the client would use that raw count directly in | Vec::with_capacity(...) before validating that enough prompt data | was actually present in the packet. This issue has been patched in | version 0.61.0. CVE-2026-48108[5]: | Russh is a Rust SSH client & server library. From version | 0.34.0-beta.1 to before version 0.61.0, russh did not enforce the | SSH identification-string rules as deliberately as OpenSSH. In | particular, the server-side identification reader used the same | permissive path as the client, allowing pre-banner lines from | clients, and the reader did not enforce a bounded number of pre- | banner lines. For a library server built on russh, this could allow | a remote peer to hold connection setup resources in the cleartext | pre-authentication phase with malformed identification input that | should have been rejected early. This issue has been patched in | version 0.61.0. CVE-2026-48110[6]: | Russh is a Rust SSH client & server library. From version 0.34.0 to | before version 0.61.0, several russh client and server message | handlers decoded attacker-controlled SSH strings, name-lists, and | byte fields into owned allocations before applying field-specific | bounds. A remote SSH peer could send oversized, high-fanout, or | malformed length-prefixed fields and make the library allocate, | attempt to allocate, or split data before rejecting input that | should have been rejected earlier. This issue has been patched in | version 0.61.0. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2026-42189 https://www.cve.org/CVERecord?id=CVE-2026-42189 [1] https://security-tracker.debian.org/tracker/CVE-2026-46673 https://www.cve.org/CVERecord?id=CVE-2026-46673 [2] https://security-tracker.debian.org/tracker/CVE-2026-46702 https://www.cve.org/CVERecord?id=CVE-2026-46702 [3] https://security-tracker.debian.org/tracker/CVE-2026-46705 https://www.cve.org/CVERecord?id=CVE-2026-46705 [4] https://security-tracker.debian.org/tracker/CVE-2026-48107 https://www.cve.org/CVERecord?id=CVE-2026-48107 [5] https://security-tracker.debian.org/tracker/CVE-2026-48108 https://www.cve.org/CVERecord?id=CVE-2026-48108 [6] https://security-tracker.debian.org/tracker/CVE-2026-48110 https://www.cve.org/CVERecord?id=CVE-2026-48110 Regards, Salvatore
