GHSA-g6xm-f9xp-qq35 CVE-2026-102825
Russh: Configured server auth-attempt cap is not enforced in the USERAUTH_REQUEST runtime path
- Severity
- 3.7 / 10
- Low · CVSS 3.1
- Exploit chance (EPSS)
- 0.35%
- Chance of exploitation in the next 30 days. Higher than 28.94% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-307 Improper Restriction of Excessive Authentication Attempts
- Fix
0.62.6- Upgrade russh to this version or later
Description
Details
Affected versions and vulnerable location
- Confirmed present on default branch
mainat HEAD0089c89c94753bebbec12b956c07a1cd38740379. - 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(defaultmax_auth_attempts: 10)russh/src/server/encrypted.rs:89(USERAUTH_REQUESTdispatch into auth handler path)russh/src/server/encrypted.rs:98(self.common.auth_attempts += 1)russh/src/server/encrypted.rs:53(only runtime read ofauth_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
- Entry point: exported server API
server::run_streaminrussh/src/server/mod.rs:1049. - Session run loop in
russh/src/server/session.rsprocesses incoming packets and callsreply(...)(server/session.rs:725). replyforwards encrypted packets tosession.server_read_encrypted(...)(server/mod.rs:1221).server_read_encryptedroutesUSERAUTH_REQUESTtoenc.server_read_auth_request(...)(server/encrypted.rs:89).- On each request,
self.common.auth_attempts += 1executes (server/encrypted.rs:98). - No comparison against
self.common.config.max_auth_attemptsis present in this runtime flow.
PoC
Reproduction steps and observed output
I did not run a full server process in this environment because Rust tooling is unavailable. I verified the issue from source and command output on the audited tree.
- Show where
max_auth_attemptsappears:
rtk rg -n "max_auth_attempts" .scratch/russh/russh/src/server/mod.rs .scratch/russh/russh/src/server/encrypted.rs .scratch/russh/russh/src/server/session.rs
Observed:
.scratch/russh/russh/src/server/mod.rs:91: pub max_auth_attempts: usize,
.scratch/russh/russh/src/server/mod.rs:121: max_auth_attempts: 10,
.scratch/russh/russh/src/server/mod.rs:148: .field("max_auth_attempts", &self.max_auth_attempts)
- Show runtime auth-attempt handling:
rtk rg -n "auth_attempts == 0|auth_attempts \\+= 1" .scratch/russh/russh/src/server/encrypted.rs
Observed:
53: let initial_none_rejection_wait_until = if self.common.auth_attempts == 0 {
98: self.common.auth_attempts += 1;
- Show production entrypoint-to-auth path references:
rtk rg -n "pub async fn run_stream|match reply\\(|server_read_encrypted\\(|server_read_auth_request\\(" .scratch/russh/russh/src/server/mod.rs .scratch/russh/russh/src/server/session.rs .scratch/russh/russh/src/server/encrypted.rs
Observed:
.scratch/russh/russh/src/server/encrypted.rs:89: enc.server_read_auth_request(
.scratch/russh/russh/src/server/session.rs:725: match reply(&mut self, &mut handler, &mut pkt).await {
.scratch/russh/russh/src/server/mod.rs:1049:pub async fn run_stream<H, R>(
.scratch/russh/russh/src/server/mod.rs:1221: session.server_read_encrypted(handler, pkt).await
- Toolchain check:
cargo --version
Observed:
/bin/bash: line 1: cargo: command not found
Impact
Attacker model
- Attacker: unauthenticated remote client with TCP reachability to a russh-backed SSH service.
- Preconditions: deployer expects
server::Config.max_auth_attemptsto cap attempts. - Impact: repeated
USERAUTH_REQUESTattempts continue for a single connection beyond configured limit, increasing online guessing opportunity and backend auth workload.
Suggested fix
Enforce max_auth_attempts in the USERAUTH_REQUEST branch before invoking auth-method handlers, and fail closed once threshold is reached.
Concrete patch direction in russh/src/server/encrypted.rs:
if self.common.config.max_auth_attempts > 0
&& self.common.auth_attempts >= self.common.config.max_auth_attempts
{
self.common.disconnect(
Disconnect::NoMoreAuthMethodsAvailable,
"Too many authentication attempts",
"",
)?;
return Ok(());
}
How it was found and a note on tooling
The researcher synthesized three lens outputs, then revalidated each claim against current main: source presence and commit history, advisory overlap checks in both GitHub advisories and OSV, entrypoint-to-sink reachability, attacker-model realism, and execution-claim integrity. The researcher used gh, git, rg, and direct source inspection under .scratch/russh. Because Rust tooling is unavailable in this worker, this report is intentionally marked source-only.
AI assistance was used while investigating this and while drafting this report. The finding was verified by reading the cited code at HEAD. The vulnerability was not executed it, and that limit is stated plainly above rather than left implied.
Credits: arpitjain099.
Affected versions
crates.io
| Package | Vulnerable | Fixed in |
|---|---|---|
| russh | < 0.62.6 |
0.62.6 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
russh crates.io → 0.62.6
- cargo
cargo update -p russh --precise 0.62.6
Severity breakdown
CVSS 3.1 3.7
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N
- Attack vector
- Network
- Attack complexity
- High
- Privileges required
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- Low
- Integrity
- None
- Availability
- None
Weakness
CWE-307: Improper Restriction of Excessive Authentication Attempts
The product does not implement sufficient measures to prevent multiple failed authentication attempts within a short time frame.
How to prevent it
- Architecture and Design: Common protection mechanisms include: Disconnecting the user after a small number of failed attempts Implementing a timeout Locking out a targeted account Requiring a computational task on the user's part.
- Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. Consider using libraries with authentication capabilities such as OpenSSL or the ESAPI Authenticator. [REF-45]
References
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-vp5q-ff62-jwqv russh: Agent server never calls `Agent::confirm`, so keys added with the confirm constraint (`ssh-add -c`) sign without confirmation | High | Also affects russh |
| GHSA-fw5c-8223-6h42 russh: peer-declared zero maximum packet size permanently stalls channel writes (silent AsyncWrite hang) | Medium | Also affects russh |
| GHSA-9wfm-jcj8-jfv9 russh's SSH agent server is susceptible to unbound allocations via repeated SSH_AGENT_CONSTRAIN_CONFIRM messages | Low | Also affects russh |
| GHSA-4p9f-7p9m-5vfg russh's SSH client is susceptible to unbounded allocations via EXT_INFO packets | Medium | Also affects russh |
| GHSA-4wc5-f2rc-q74m russh: Unbounded memory allocation in agent protocol server via crafted constraint records | Medium | Also affects russh |
| GHSA-j7h2-66j4-ghjf A russh SSH server accepts a publickey authentication whose signature uses a different algorithm than the one named in the request | Low | Also affects russh |
| GHSA-w3jg-pjxf-73p4 Russh: Missing X25519 zero-point validation in hybrid ML-KEM key exchange | Medium | Also affects russh |
| GHSA-47hw-gvq5-r2gm russh: Client-side channel-scoped Handler callbacks fire for channel IDs the client never opened | High | Also affects russh |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor