CVE-2026-102825

Executive Summary

CVE-2026-102825 is an improper restriction of excessive authentication attempts (CWE-307) in Russh, a Rust SSH client and server library. Prior to version 0.62.6, the server-side USERAUTH_REQUEST handling path reached from server::run_stream in russh/src/server/encrypted.rs increments an internal authentication attempt counter (self.common.auth_attempts) but never compares it against the configured server::Config.max_auth_attempts limit. Any unauthenticated remote client can therefore submit an unbounded number of authentication requests over a single connection, bypassing the deployment's attempt-limiting policy. This increases online credential-guessing opportunity and backend authentication workload. Exploitation requires network access to the SSH service but a relatively high degree of conditions for meaningful credential compromise, reflected in the CVSS score of 3.7.

Technical Analysis

The vulnerability resides in the server-side SSH authentication state machine of Russh. In SSH, authentication is carried out over the transport protocol via SSH_MSG_USERAUTH_REQUEST messages. A hardening control common to SSH servers is to cap the number of failed authentication attempts per connection; once the cap is reached, the server must terminate the connection. This limits brute-force and password-spraying opportunities.

In affected versions, the code path handling the USERAUTH_REQUEST message — reached from server::run_stream in russh/src/server/encrypted.rs — performs the increment of the shared attempt counter (self.common.auth_attempts) but omits the enforcement check against the configured maximum (server::Config.max_auth_attempts). Because the comparison is never executed, the counter has no operational effect and the connection is not terminated when the policy threshold is exceeded.

The result is a classic missing-enforcement defect (CWE-307, Improper Restriction of Excessive Authentication Attempts). The security control is configured and the accounting is performed, but the decision point that should reject or disconnect after N attempts is absent. From the attacker's perspective, the server behaves as if no attempt limit existed: a single TCP connection can carry an arbitrarily large stream of authentication requests.

The attack surface is the SSH authentication service exposed via a Russh-based server (server::run_stream). No authentication or prior trust is required — the messages are exchanged pre-authentication. The complexity component of the CVSS vector (AC:H) reflects that successful credential compromise still requires valid credentials to be guessed and that other environmental/defensive factors (rate limiting at network layers, account lockout on the backend, key-only authentication) may mitigate the practical outcome. The confidentiality-only, low-severity impact (C:L, I:N, A:N) matches credential-guessing as the residual effect rather than direct data manipulation or denial of service.

No public proof-of-concept, exploit code, or Nuclei template is known for this CVE. All technical statements above are derived directly from the NVD description.

Exploitation Scenarios

No public PoC is available; the attack chain below is inferred from the vulnerability class (CWE-307) and the mechanism described in the NVD entry.

1. Reconnaissance / target identification: An attacker enumerates internet-exposed or internally reachable SSH endpoints and identifies those backed by the Russh library in an affected version. Version fingerprinting of SSH banners may not reveal the library, so targeting is likely opportunistic against a known or suspected Russh deployment (e.g., a service known to embed Russh).

2. Triggering the flaw class: The attacker opens a single TCP connection and completes SSH transport negotiation, then begins submitting authentication requests (SSH_MSG_USERAUTH_REQUEST). Because the server increments the attempt counter but never compares it to server::Config.max_auth_attempts, the connection is not closed on exceeding the configured cap. The attacker can therefore continue issuing attempts on the same connection indefinitely, replacing what should have been a bounded number of tries with an unbounded stream.

3. Payload / execution method: At the vulnerability-class level, the payload is a repeated sequence of authentication attempts — for example, password or keyboard-interactive guesses, or repeated public-key probes — sent over the single persistent connection. No memory-corruption payload or code injection is required; the abuse is purely of the authentication protocol logic. The specific request contents depend on the authentication methods the target server offers; the NVD description does not specify which methods beyond the generic USERAUTH_REQUEST path.

4. Post-exploitation impact: If a guess succeeds, the attacker obtains authenticated access as the compromised account, which could enable further actions depending on account privileges and server configuration (impact is bounded to confidentiality and rated LOW in CVSS). Even without success, the attacker imposes sustained authentication workload on the server and any backend authentication provider, increasing resource consumption and expanding online guessing opportunity.

Impact Assessment

The primary impact is a weakening of authentication hardening: the configured per-connection attempt limit is not enforced, so an unauthenticated remote party can perform an open-ended number of authentication attempts on a single connection.

• Confidentiality (C:LOW): Success depends on guessing valid credentials; a successful guess yields access to whatever that account can read.
• Integrity (I:NONE) and Availability (A:NONE): The vector assigns no direct integrity or availability impact. The increased authentication workload is a secondary effect, not a scored availability impact.
• Attack vector (AV:NETWORK), no privileges required (PR:NONE), no user interaction (UI:NONE), scope unchanged (S:U), high attack complexity (AC:HIGH).

Blast radius is limited to deployments that (a) run an affected Russh version as their SSH server and (b) rely on attempt-limiting as a brute-force control. Environments using key-only authentication, network-layer rate limiting, or backend account lockout substantially reduce practical exploitability. Because this is a server library embedded in applications, affected systems are those applications — not generic OpenSSH infrastructure.

Detection Guidance

The following rules are detection aids. Because no public exploit exists, rules focus on the behavioral signature: an abnormally high number of SSH authentication requests on a single connection. Field names and event IDs vary by platform; validate and tune in your environment.

Sigma Rule

title: Excessive SSH Authentication Requests on a Single Connection (CVE-2026-102825)
id: 7f3c9a1e-2b6d-4c8a-9e01-0a1b2c3d4e5f
status: experimental
description: Detects an abnormally high number of authentication attempts over a single SSH connection, consistent with abuse of missing max_auth_attempts enforcement in Russh.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-102825
author: valtersit.com
date: 2026-01-01
logsource:
  product: linux
  service: sshd
detection:
  selection:
    message|contains:
      - 'Failed password'
      - 'Failed publickey'
      - 'Connection closed by authenticating user'
  timeframe: 1m
  condition: selection | count() by src_ip, src_port > 20
fields:
  - src_ip
  - src_port
  - user
falsepositives:
  - Legitimate automation with misconfigured retry logic
  - Health-check or monitoring agents with credential rotation
level: medium
tags:
  - attack.credential_access
  - attack.t1110

YARA Rule

rule CVE_2026_102825_Russh_Missing_Auth_Limit
{
    meta:
        description = "Detects Russh source artifacts referencing auth_attempts handling without max_auth_attempts enforcement (CVE-2026-102825)"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-102825"
        author = "valtersit.com"
        date = "2026-01-01"
        severity = "low"

    strings:
        $s1 = "auth_attempts" ascii
        $s2 = "max_auth_attempts" ascii
        $s3 = "USERAUTH_REQUEST" ascii nocase

    condition:
        // Flag files that reference auth_attempts and USERAUTH_REQUEST
        // but do NOT reference the max_auth_attempts enforcement constant.
        2 of ($s*) and not $s2
}

Suricata IDS Rule

alert tcp any any -> any 22 (msg:"CVE-2026-102825 Possible Russh SSH Auth Attempt Flood - Excessive USERAUTH_REQUEST on Single Connection"; flow:established,to_server; dsize:>0; threshold:type both, track by_src, count 30, seconds 60; classtype:attempted-recon; reference:cve,2026-102825; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-102825; sid:2026010282; rev:1;)

Elastic Detection

sequence by source.ip with maxspan=60s
  [network where network.transport == "tcp" and destination.port == 22]
  [network where network.transport == "tcp" and destination.port == 22]
  [network where network.transport == "tcp" and destination.port == 22]

Splunk SPL Query

index=ssh sourcetype=sshd ("Failed password" OR "Failed publickey" OR "Connection closed by authenticating user")
| bucket _time span=1m
| stats count AS attempts, dc(src_port) AS unique_src_ports BY src_ip, user, dest_host, _time
| where attempts > 20
| table _time, src_ip, user, dest_host, attempts, unique_src_ports
| sort - attempts

Wazuh OSSEC Rule

<group name="ssh,russh,">
  <rule id="100282" level="10" frequency="20" timeframe="60">
    <if_matched_sid>5710</if_matched_sid>
    <same_source_ip />
    <description>CVE-2026-102825: Excessive SSH authentication failures from same source within 60s, possible abuse of missing Russh max_auth_attempts enforcement.</description>
    <mitre>
      <id>T1110</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source).

1. Immediate mitigations

• Upgrade to Russh 0.62.6 or later, where the max_auth_attempts comparison is enforced. This is the definitive fix.
• If immediate upgrade is not possible, enforce attempt limiting externally: apply network-layer rate limiting or connection throttling on the SSH service (e.g., firewall connection limits, a load balancer, or an SSH proxy) so that abusive volumes from a single source are throttled regardless of library behavior.
• Prefer public-key authentication and disable password/keyboard-interactive methods where feasible, reducing the value of online guessing.
• Monitor for high authentication-attempt rates per source connection and alert or block as described above.

2. Patch/upgrade steps

• Update the Russh dependency to 0.62.6 or newer in Cargo.toml and rebuild the affected server application.
• Verify the deployed application links the patched version (check Cargo.lock), then confirm the configured server::Config.max_auth_attempts is set to a sane value and enforced.
• Since patch tracking shows no evidence from any tracked source, treat 0.62.6 as the vendor-stated fixed release and validate the enforcement behavior in a test environment.

3. Long-term hardening

• Set server::Config.max_auth_attempts explicitly and add regression tests asserting that a connection is terminated once the cap is exceeded.
• Layer defenses: network rate limiting, backend account lockout, and alerting on authentication anomalies.
• Track embedded/server-library CVEs (SBOM) so SSH-facing dependency vulnerabilities are inventoried and remediated.

References

• NVD — CVE-2026-102825: https://nvd.nist.gov/vuln/detail/CVE-2026-102825
• CWE-307, Improper Restriction of Excessive Authentication Attempts: https://cwe.mitre.org/data/definitions/307.html
• MITRE ATT&CK T1110, Brute Force: https://attack.mitre.org/techniques/T1110/
• Russh project repository (verify fixed release 0.62.6): https://github.com/Eugeny/russh
• CISA Known Exploited Vulnerabilities catalog (CVE-2026-102825 is NOT listed as of this report): https://www.cisa.gov/known-exploited-vulnerabilities-catalog