CVE-2026-46705: Russh SSH Authentication Bypass Vulnerability

CVE-2026-46705 Overview

CVE-2026-46705 affects Russh, a Rust SSH client and server library maintained by Eugeny. The vulnerability impacts versions from 0.34.0-beta.1 up to but not including 0.61.0. The russh server retains internal user authentication state across SSH_MSG_USERAUTH_REQUEST messages without separating that state when the request principal changes. RFC 4252 permits the user name and service name fields to change between authentication requests, but russh-owned state such as remaining methods, partial-success state, and in-progress method state can carry over to a later request for a different (user, service) pair. The flaw is classified under [CWE-287] Improper Authentication and was patched in version 0.61.0.

Critical Impact
Internal authentication state leakage between principals can influence the authentication flow for a different user or service on the same SSH connection.

Affected Products

Russh versions 0.34.0-beta.1 through 0.60.x
Rust SSH server implementations built on the russh library
Applications embedding russh for SSH server functionality

Discovery Timeline

2026-06-10 - CVE-2026-46705 published to NVD
2026-06-10 - Last updated in NVD database

Technical Details for CVE-2026-46705

Vulnerability Analysis

The vulnerability stems from how russh manages SSH user authentication state within a single transport connection. RFC 4252 permits clients to send multiple SSH_MSG_USERAUTH_REQUEST messages with differing user name and service name fields. A compliant server must treat each unique (user, service) pair as an independent authentication context.

Russh fails to reset or scope its internal authentication state when the principal changes mid-session. Remaining authentication methods, partial-success indicators, and in-progress method state persist across requests. A second request targeting a different user or service can inherit progress made under the prior principal.

This is an internal library state mismatch rather than a violation of RFC 4252. The behavior can influence authentication outcomes for principals the client has not legitimately progressed against. The integrity impact is limited, consistent with the partial-success and method-tracking surfaces involved.

Root Cause

The root cause is missing state separation in the russh server authentication path. The library treats userauth state as connection-scoped rather than (user, service)-scoped, violating the implicit isolation boundary RFC 4252 expects between authentication contexts.

Attack Vector

An unauthenticated network attacker sends a sequence of SSH_MSG_USERAUTH_REQUEST messages on a single transport, alternating the user name or service name fields. Retained state from one principal can then influence the authentication path evaluated for another principal. No user interaction or prior privileges are required. See the GitHub Security Advisory GHSA-hpv4-5h6f-wqr3 for technical details on the affected state transitions.

Detection Methods for CVE-2026-46705

Indicators of Compromise

Multiple SSH_MSG_USERAUTH_REQUEST messages within a single connection that alternate user name or service name fields
Unexpected SSH_MSG_USERAUTH_SUCCESS or partial-success responses following principal changes
SSH sessions reaching authenticated state for users that did not complete a full method sequence

Detection Strategies

Inventory dependencies for russh versions below 0.61.0 using cargo tree or SBOM scanning
Inspect SSH server logs for sequences of userauth requests with shifting (user, service) tuples on one connection
Add server-side audit logging that records the principal associated with each userauth state transition

Monitoring Recommendations

Forward SSH server authentication logs to a centralized log platform for correlation
Alert on sessions issuing more than a small number of userauth requests with differing principals
Monitor build pipelines and registries for any release artifacts still pinned to vulnerable russh versions

How to Mitigate CVE-2026-46705

Immediate Actions Required

Upgrade russh to version 0.61.0 or later in all affected projects
Rebuild and redeploy any binaries that statically link earlier russh versions
Audit SSH server authentication logs for anomalous userauth sequences on long-lived connections

Patch Information

The maintainers fixed the issue in russh 0.61.0 by properly scoping authentication state to the requested (user, service) pair. Refer to the GitHub Security Advisory GHSA-hpv4-5h6f-wqr3 for the upstream fix details.

Workarounds

Terminate SSH connections that issue userauth requests with changing user or service names if the application does not require that behavior
Restrict network exposure of russh-based servers to trusted clients until patching completes
Enforce strict authentication method ordering at the application layer where possible

bash

# Update russh in Cargo.toml to the patched version
cargo update -p russh --precise 0.61.0
cargo build --release