https://db.gcve.eu/rss/recent/all/10 Most recent entries from all 2026-10-01T13:39:29.994860+00:00 Vulnerability-Lookup info@gcve.eu python-feedgen Contains only the most 10 recent entries. https://db.gcve.eu/vuln/fkie_cve-2026-102825 fkie_cve-2026-102825 2026-10-01T13:39:30.013685+00:00

Russh is a Rust SSH client and server library. Prior to 0.62.6, the USERAUTH_REQUEST path reached from server::run_stream in russh/src/server/encrypted.rs increments self.common.auth_attempts but never compares it with server::Config.max_auth_attempts. An unauthenticated remote client can continue submitting authentication requests on one connection beyond the configured cap, bypassing the deployment's attempt-limiting policy and increasing online guessing opportunity and backend authentication workload. This issue is fixed in version 0.62.6.

 https://db.gcve.eu/vuln/ghsa-g6xm-f9xp-qq35 GHSA-g6xm-f9xp-qq35 — Russh: Configured server auth-attempt cap is not enforced in the USERAUTH_REQUEST runtime path 2026-10-01T13:39:30.013763+00:00

Affected: crates.io: russh

### Details

#### Affected versions and vulnerable location

- Confirmed present on default branch `main` at HEAD `0089c89c94753bebbec12b956c07a1cd38740379`. - Crate version at HEAD: `0.62.4`. - Vulnerable locations on current default branch: - `russh/src/server/mod.rs:91` (`pub max_auth_attempts: usize`) - `russh/src/server/mod.rs:121` (default `max_auth_attempts: 10`) - `russh/src/server/encrypted.rs:89` (`USERAUTH_REQUEST` dispatch into auth handler path) - `russh/src/server/encrypted.rs:98` (`self.common.auth_attempts += 1`) - `russh/src/server/encrypted.rs:53` (only runtime read of `auth_attempts`, used for initial reject timing, not attempt limiting) - Default-branch history check did not show a newer merged commit adding enforcement against `config.max_auth_attempts`.

#### Reachability trace verified

1. Entry point: exported server API `server::run_stream` in `russh/src/server/mod.rs:1049`. 2. Session run loop in `russh/src/server/session.rs` processes incoming packets and calls `reply(...)` (`server/session.rs:725`). 3. `reply` forwards encrypted packets to `session.server_read_encrypted(...)` (`server/mod.rs:1221`). 4. `server_read_encrypted` routes `USERAUTH_REQUEST` to `enc.server_read_auth_request(...)` (`server/encrypted.rs:89`). 5. On each request, `self.common.auth_attempts += 1` executes (`server/encrypted.rs:98`). 6. No comparison against `self.common.config.max_auth_attempts` is present in this runtime flow.

### PoC

#### Reproduction steps and…