CVE-2026-46705: Russh SSH Authentication State Isolation Flaw

Technical summary

CVE-2026-46705 is a state management vulnerability in russh versions 0.34.0-beta.1 through 0.60.x affecting the SSH_MSG_USERAUTH_REQUEST message handler. RFC 4252 permits the user name and service name fields to change across consecutive authentication requests on the same connection; russh does not isolate its internal authentication state—including remaining available methods, partial-success flags, and method-specific state machines—when these principal fields change. An attacker can craft a sequence of authentication requests with different (user, service) combinations, causing authentication decisions made for one principal to influence validation logic for another. The vulnerability is rooted in CWE-287 (Improper Authentication) and requires network access but no prior credentials or user interaction.

Business impact

Organizations deploying russh-based SSH servers face authentication bypass risk. Depending on the server's authentication policy, an attacker could potentially authenticate as an unintended user, escalate privileges, or gain shell access without valid credentials. The CVSS score of 5.3 reflects low confidentiality impact but meaningful integrity risk. The threat is highest in environments where russh servers handle sensitive infrastructure, cloud platforms, or systems with strict access control requirements. Development teams relying on russh must update to prevent this state-crossing attack vector in production deployments.

Affected systems

This vulnerability affects russh library versions 0.34.0-beta.1 through 0.60.x. Any SSH server built on an affected version of russh is vulnerable if it accepts multiple authentication requests per connection. This includes custom SSH servers, embedded SSH services, and third-party tools that depend on russh. The vendor product list for this CVE is not populated in the advisory; affected organizations should identify russh usage in their codebase or dependencies via package managers (Cargo for Rust projects) and verify their specific version.

Exploitability

The vulnerability is network-accessible (CVSS AV:N) and requires no authentication (PR:N) or user interaction (UI:N). Exploitation requires crafting valid SSH protocol messages but does not demand knowledge of valid credentials beforehand. Proof-of-concept would involve an SSH client sending multiple SSH_MSG_USERAUTH_REQUEST messages with different usernames and observing state pollution. The attack is deterministic and repeatable; no timing, race conditions, or brute force are needed. However, practical impact depends on the server's authentication configuration—not all SSH servers are equally vulnerable to principal-crossing attacks.

Remediation

Update russh to version 0.61.0 or later, which properly isolates authentication state when the user name or service name changes in successive SSH_MSG_USERAUTH_REQUEST messages. Developers should review their Cargo.lock or Cargo.toml to identify the current russh version and bump the dependency. After patching, test SSH authentication flows to ensure your server rejects unexpected principal changes or correctly resets state. Organizations unable to update immediately should consider network-level controls: restrict SSH access to trusted IP ranges, use a WAF or SSH gateway, or temporarily disable the affected SSH service if alternative access methods exist.

Patch guidance

Verify your russh dependency: run `cargo tree | grep russh` or inspect Cargo.toml. If the version is 0.60.x or earlier, update to 0.61.0 or newer by editing Cargo.toml to `russh = "^0.61.0"` (or your organization's preferred version constraint), then run `cargo update`. Compile and test your SSH server in a staging environment to confirm authentication still works correctly for legitimate users. Pay special attention to multi-factor or multi-method authentication flows. Finally, rebuild and redeploy your application, and confirm the new russh version is in use by checking runtime logs or `cargo --version` output.

Detection guidance

Monitor SSH authentication logs for unusual patterns: multiple authentication requests with different usernames from the same client session, or authentication success for unexpected users. If your russh server logs authentication attempts, look for state pollution indicators—such as a client attempting to authenticate as user A, failing, then succeeding as user B without providing valid B credentials. Network-level detection is challenging; focus on application-level logging and audit trails. Code review of russh-dependent applications is recommended to identify whether your use case is vulnerable (i.e., whether you accept and process multiple SSH_MSG_USERAUTH_REQUEST messages per connection).

Why prioritize this

Although the CVSS score is MEDIUM (5.3), this vulnerability should be prioritized for any organization running russh-based SSH infrastructure. The lack of complexity (AC:L), ease of network access, and direct impact on authentication integrity make it a practical concern. Threat actors can attack publicly exposed SSH services without reconnaissance. Prioritize systems handling critical access (CI/CD, cloud platforms, bastion hosts) and those exposed to untrusted networks. Development teams should treat patching russh as a standard release-blocking issue.

Risk score, explained

The CVSS v3.1 score of 5.3 reflects: Network accessibility (AV:N) with no attack complexity (AC:L), no privileges required (PR:N), and no user interaction (UI:N), yielding a broad attack surface. The integrity impact is Low (I:L) because authentication bypass affects authorization decisions but may not directly corrupt data. Confidentiality and availability impacts are None, limiting the score ceiling. However, the *local* risk for SSH-dependent systems is higher than CVSS suggests, because compromised authentication is a foothold for further attacks. Contextualize the score within your threat model: if your SSH server is internet-facing or user-facing, treat this as higher risk.

Frequently asked questions