Russh CVE-2026-102825

Exploitable only when the deployment sets server::Config.max_auth_attempts to a nonzero cap and relies on it to throttle guessing; the bug is that russh <0.62.6 increments auth_attempts on the USERAUTH_REQUEST path in russh/src/server/encrypted.rs but never compares it to that cap, so the limit is silently unenforced. No authentication or user interaction is required (PR:N/UI:N) and it works against network-reachable russh servers, but practical impact is LIMITED because the attacker still must guess valid credentials - the vulnerability only removes the lockout/disconnect that would otherwise cut off guessing, and it has no effect if operators use external throttling (e.g. fail2ban, firewall rate limits) or leave max_auth_attempts at 0.

All signals point to a genuine but low-priority issue. The vendor CVSS of 3.7 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N) is internally consistent with the described flaw: network-reachable and unauthenticated (AV:N/PR:N), but high complexity (AC:H) because the bug only removes a throttle - it does not itself grant access, so real-world impact still depends on the attacker eventually guessing valid credentials. Impact is correctly scoped to C:L with no integrity or availability effect. There is no EPSS score, no CISA KEV listing, and no public exploit in the provided data, so this is 'no public exploit identified at time of analysis.' The GitHub commit and regression tests confirm the root cause and fix, so the technical claim is solid, but this is squarely a low-real-risk hardening issue rather than a critical priority - it weakens a defense-in-depth control (attempt capping) rather than creating a direct compromise. No conflicting signals were found; the main caveat is that exploitability is entirely gated on the presence of guessable credentials and a configured max_auth_attempts policy that operators actually rely on.

An unauthenticated remote attacker opens a single SSH connection to a service built on russh <0.62.6 and repeatedly submits USERAUTH_REQUEST password attempts. Because auth_attempts is incremented but never compared to Config.max_auth_attempts, the server keeps answering with USERAUTH_FAILURE instead of disconnecting, letting the attacker run an uninterrupted online password-guessing campaign on one connection and generating extra backend authentication load. No public PoC exists, though the fix commit ships a regression test that demonstrates the pre-fix behavior.