[From nobody Wed Oct 7 00:37:07 2026 Received: (at submit) by bugs.debian.org; 12 Jun 2026 04:12:45 +0000 X-Spam-Checker-Version: SpamAssassin 4.0.1-bugs.debian.org_2005_01_02 (2024-03-25) on buxtehude.debian.org X-Spam-Level: X-Spam-Status: No, score=-9.9 required=4.0 tests=BAYES_00, FOURLA, FROMDEVELOPER, NO_RELAYS,XMAILER_REPORTBUG autolearn=ham autolearn_force=no version=4.0.1-bugs.debian.org_2005_01_02 X-Spam-Bayes: score:0.0000 Tokens: new, 65; hammy, 150; neutral, 185; spammy, 0. spammytokens: hammytokens:0.000-+--H*F:U*carnil, 0.000-+--XDebbugsCc, 0.000-+--X-Debbugs-Cc, 0.000-+--HTo:N*Debian, 0.000-+--H*Ad:N*Bug Return-path: <carnil@debian.org> Received: via submission by buxtehude.debian.org with esmtp (Exim 4.96) (envelope-from <carnil@debian.org>) id 1wXtG7-002ItD-1g for submit@bugs.debian.org; Fri, 12 Jun 2026 04:12:45 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Salvatore Bonaccorso <carnil@debian.org> To: Debian Bug Tracking System <submit@bugs.debian.org> Subject: rust-russh: CVE-2026-42189 CVE-2026-46673 CVE-2026-46702 CVE-2026-46705 CVE-2026-48107 CVE-2026-48108 CVE-2026-48110 Message-ID: <178123756240.3618490.8375437919297372066.reportbug@eldamar.lan> X-Mailer: reportbug 13.2.0 Date: Fri, 12 Jun 2026 06:12:42 +0200 Delivered-To: submit@bugs.debian.org Source: rust-russh Version: 0.57.1-2 Severity: grave Tags: security upstream Justification: user security hole X-Debbugs-Cc: carnil@debian.org, Debian Security Team <team@security.debian.org> 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 ]