CVE-2026-102825 is a low-severity (CVSS 3.7) CWE-307 vulnerability in russh. A fix is available for russh — see the affected versions and patch details below.
Russh: Configured server auth-attempt cap is not enforced in the USERAUTH_REQUEST runtime path
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-102825.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
CVE-2026-102825 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 394,803 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
russhReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.
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 Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🦀crates.io | russh | all versions | 0.62.6cargo update -p russh --precise 0.62.6 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for russh, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update russh to 0.62.6 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-102825 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
The russh crate is included as a dependency of openshell in Hummingbird. The flaw has been addressed via tracker HUM-9177.
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.Source: Red Hat security advisory for CVE-2026-102825 (CC BY 4.0)
| Product | Fixed in | Advisory |
|---|---|---|
| Red Hat Hardened Images | openshell-main-0.1.2-0.2.hum1 | RHSA-2026:74586 |
Frequently Asked Questions
Is CVE-2026-102825 in your dependencies?
Find it across crates.io, including transitive dependencies.