CVE-2026-46705: Russh Russh Server Userauth State Is Vulnerability

MODERATE
Advisory Identifier: GHSA-hpv4-5h6f-wqr3
CVSS 5.3
CWE-287
Published
Advisory Summary

CVE-2026-46705 is a MODERATE (CVSS 5.3) russh server userauth state is vulnerability (CWE-287: Improper Authentication) affecting Russh libraries in the crates.io ecosystem. The issue involves russh server userauth state is not reset when authentication principal changes. Remediation is available by upgrading affected packages to version 0.61.0.

CVE-2026-46705 at a Glance

CVE Identifier CVE-2026-46705
GHSA Identifier GHSA-hpv4-5h6f-wqr3
Severity MODERATE
CVSS v3.1 Base Score 5.3
CWE Classification CWE-287: Improper Authentication
Affected Product Russh
Package Ecosystem crates.io
Published Date
Last Updated

Security Impact

CVSS: 5.3

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality None (C:N)
Integrity Low (I:L)
Availability None (A:N)

How to Fix CVE-2026-46705

To remediate this vulnerability, upgrade all affected Russh dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

russh fixed: 0.61.0
Upgrade russh to 0.61.0
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for russh

How to Check if You Are Affected

To determine whether your application is affected by CVE-2026-46705, inspect your project dependencies for Russh:

inspect dependencies for russh

Analyze the terminal output to locate any version of Russh in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 0.61.0), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-287: Improper Authentication, where when an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct. In Russh, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### Summary The `russh` server authentication path keeps internal userauth state across `SSH_MSG_USERAUTH_REQUEST` messages without separating that state when the request principal changes. RFC 4252 allows the `user name` and `service name` fields to change between authentication requests. The issue is not that such changes are invalid. The issue is that russh-owned authentication state, such as remaining methods, partial-success state, and in-progress method state, can remain associated with the connection and then influence a later request for a different `(user, service)`. This is an internal library state mismatch. Applications are responsible for any authentication state they keep in their own handlers, but russh must reset or separate state that russh itself owns. ### Details The relevant server-side auth logic is in: - `russh/src/server/encrypted.rs` - `russh/src/auth.rs` RFC 4252 section 5 says the `user name` and `service name` fields are repeated in every `SSH_MSG_USERAUTH_REQUEST` and may change. It also says the server implementation must check those fields in every message and flush accumulated authentication state if they change; if it cannot flush that state, it must disconnect. In vulnerable `russh` code, the username and service are decoded from each `SSH_MSG_USERAUTH_REQUEST`, while the `AuthRequest` state remains connection-scoped. That state includes: - `methods`, which is later encoded as the `SSH_MSG_USERAUTH_FAILURE` remaining-methods list. - `partial_success`, which is later encoded in `SSH_MSG_USERAUTH_FAILURE`. - `current`, which tracks in-progress method state such as public-key offer or keyboard-interactive challenge state. - `rejection_count`. If one request narrows russh's internal `methods` set, a later request for a different user can observe that narrowed set unless the internal state is reset at the principal boundary. ### PoC The PoC demonstrates only russh-owned state. The handler does not store any cross-request state. Alice's request narrows russh's remaining methods to `password`; Bob's later plain reject should not reuse that internal state. ```rust struct RemainingMethodsUserSwitchServer; impl server::Handler for RemainingMethodsUserSwitchServer { type Error = russh::Error; async fn auth_none(&mut self, user: &str) -> Result<server::Auth, Self::Error> { if user == "alice" { Ok(server::Auth::Reject { proceed_with_methods: Some(MethodSet::from(&[MethodKind::Password][..])), partial_success: true, }) } else { Ok(server::Auth::reject()) } } } #[tokio::test] async fn auth_does_not_carry_remaining_methods_across_username_change() { let alice = session.authenticate_none("alice").await.unwrap(); assert!(matches!( alice, client::AuthResult::Failure { ref remaining_methods, .. } if *remaining_methods == MethodSet::from(&[MethodKind::Password][..]) )); let bob = session.authenticate_none("bob").await.unwrap(); if let client::AuthResult::Failure { remaining_methods, .. } = bob { assert!( remaining_methods.contains(&MethodKind::PublicKey), "server reused Alice's narrowed remaining methods for Bob: {remaining_methods:?}" ); } } ``` On `upstream/main`, this fails with: ```text server reused Alice's narrowed remaining methods for Bob: MethodSet([Password]) ``` That failure is produced by russh's retained `AuthRequest.methods`; it does not depend on handler-owned MFA/session state. ### Impact Suggested provisional CVSS v3.1: - `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N` - Score: `5.3` Reasoning: - `AV:N`: reachable by a remote SSH client during authentication. - `AC:L`: the attack is a normal sequence of SSH user-auth packets. - `PR:N`: the attacker does not need an already-authenticated SSH session. - `UI:N`: no user interaction is required on the server side. - `S:U`: the impact is within the vulnerable SSH server implementation. - `C:N`: the narrow PoC does not disclose confidential data. - `I:L`: russh-owned authentication state for one principal can affect the authentication flow for a different principal. - `A:N`: the narrow PoC does not demonstrate an availability impact. This report does not claim that username changes are inherently invalid, nor does it rely on application-owned authentication state being mishandled by the embedding server. ### Fix / Patch Direction The fix should update russh's internal userauth state handling so that accumulated russh-owned state is flushed or separated when `(user, service)` changes between `SSH_MSG_USERAUTH_REQUEST` messages. The fix stores the last seen `(user, service)` on `AuthRequest`. When a new auth request arrives for a different principal, russh resets its internal auth state before dispatching the new request. This keeps username changes protocol-valid while preventing prior russh-owned auth state from carrying into the new principal.

CVE-2026-46705 Affected Russh Versions

1 component(s)
Fixed Versions:
0.61.0
Product / Package Ecosystem Affected Versions Fixed Version
russh
crates.io
≥ 0.34.0-beta.1
< 0.61.0
0.61.0

References

Frequently Asked Questions

What is CVE-2026-46705?
CVE-2026-46705 is a security vulnerability in Russh involving russh server userauth state is not reset when authentication principal changes under CWE-287: Improper Authentication.
Which Russh versions are affected?
Affected versions include releases prior to 0.61.0 across affected packages: russh.
What version fixes CVE-2026-46705?
Upgrading to 0.61.0 (or the latest patched release for your respective branch) resolves the vulnerability.
Is russh affected?
Yes, russh is affected in releases prior to 0.61.0. Upgrade your dependency to 0.61.0 or later.
What is the CVSS score of CVE-2026-46705?
CVE-2026-46705 has a CVSS v3.1 base score of 5.3 (MODERATE) with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N.
What CWE is associated with CVE-2026-46705?
CVE-2026-46705 is classified under CWE-287: Improper Authentication (When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.).
How can I check crates.io dependencies for CVE-2026-46705?
Run the dependency tree command: 'inspect dependencies for russh'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-hpv4-5h6f-wqr3",
  "modified" : "2026-06-11T14:06:30Z",
  "published" : "2026-05-29T19:39:41Z",
  "aliases" : [ "CVE-2026-46705" ],
  "summary" : "russh server userauth state is not reset when authentication principal changes",
  "details" : "### Summary\nThe `russh` server authentication path keeps internal userauth state across `SSH_MSG_USERAUTH_REQUEST` messages without separating that state when the request principal changes.\n\nRFC 4252 allows the `user name` and `service name` fields to change between authentication requests. The issue is not that such changes are invalid. The issue is that russh-owned authentication state, such as remaining methods, partial-success state, and in-progress method state, can remain associated with the connection and then influence a later request for a different `(user, service)`.\n\nThis is an internal library state mismatch. Applications are responsible for any authentication state they keep in their own handlers, but russh must reset or separate state that russh itself owns.\n\n### Details\nThe relevant server-side auth logic is in:\n\n- `russh/src/server/encrypted.rs`\n- `russh/src/auth.rs`\n\nRFC 4252 section 5 says the `user name` and `service name` fields are repeated in every `SSH_MSG_USERAUTH_REQUEST` and may change. It also says the server implementation must check those fields in every message and flush accumulated authentication state if they change; if it cannot flush that state, it must disconnect.\n\nIn vulnerable `russh` code, the username and service are decoded from each `SSH_MSG_USERAUTH_REQUEST`, while the `AuthRequest` state remains connection-scoped. That state includes:\n\n- `methods`, which is later encoded as the `SSH_MSG_USERAUTH_FAILURE` remaining-methods list.\n- `partial_success`, which is later encoded in `SSH_MSG_USERAUTH_FAILURE`.\n- `current`, which tracks in-progress method state such as public-key offer or keyboard-interactive challenge state.\n- `rejection_count`.\n\nIf one request narrows russh's internal `methods` set, a later request for a different user can observe that narrowed set unless the internal state is reset at the principal boundary.\n\n### PoC\nThe PoC demonstrates only russh-owned state. The handler does not store any cross-request state. Alice's request narrows russh's remaining methods to `password`; Bob's later plain reject should not reuse that internal state.\n\n```rust\nstruct RemainingMethodsUserSwitchServer;\n\nimpl server::Handler for RemainingMethodsUserSwitchServer {\n    type Error = russh::Error;\n\n    async fn auth_none(&mut self, user: &str) -> Result<server::Auth, Self::Error> {\n        if user == \"alice\" {\n            Ok(server::Auth::Reject {\n                proceed_with_methods: Some(MethodSet::from(&[MethodKind::Password][..])),\n                partial_success: true,\n            })\n        } else {\n            Ok(server::Auth::reject())\n        }\n    }\n}\n\n#[tokio::test]\nasync fn auth_does_not_carry_remaining_methods_across_username_change() {\n    let alice = session.authenticate_none(\"alice\").await.unwrap();\n\n    assert!(matches!(\n        alice,\n        client::AuthResult::Failure {\n            ref remaining_methods,\n            ..\n        } if *remaining_methods == MethodSet::from(&[MethodKind::Password][..])\n    ));\n\n    let bob = session.authenticate_none(\"bob\").await.unwrap();\n\n    if let client::AuthResult::Failure {\n        remaining_methods, ..\n    } = bob {\n        assert!(\n            remaining_methods.contains(&MethodKind::PublicKey),\n            \"server reused Alice's narrowed remaining methods for Bob: {remaining_methods:?}\"\n        );\n    }\n}\n```\n\nOn `upstream/main`, this fails with:\n\n```text\nserver reused Alice's narrowed remaining methods for Bob: MethodSet([Password])\n```\n\nThat failure is produced by russh's retained `AuthRequest.methods`; it does not depend on handler-owned MFA/session state.\n\n### Impact\nSuggested provisional CVSS v3.1:\n\n- `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N`\n- Score: `5.3`\n\nReasoning:\n\n- `AV:N`: reachable by a remote SSH client during authentication.\n- `AC:L`: the attack is a normal sequence of SSH user-auth packets.\n- `PR:N`: the attacker does not need an already-authenticated SSH session.\n- `UI:N`: no user interaction is required on the server side.\n- `S:U`: the impact is within the vulnerable SSH server implementation.\n- `C:N`: the narrow PoC does not disclose confidential data.\n- `I:L`: russh-owned authentication state for one principal can affect the authentication flow for a different principal.\n- `A:N`: the narrow PoC does not demonstrate an availability impact.\n\nThis report does not claim that username changes are inherently invalid, nor does it rely on application-owned authentication state being mishandled by the embedding server.\n\n### Fix / Patch Direction\nThe fix should update russh's internal userauth state handling so that accumulated russh-owned state is flushed or separated when `(user, service)` changes between `SSH_MSG_USERAUTH_REQUEST` messages.\n\nThe fix stores the last seen `(user, service)` on `AuthRequest`. When a new auth request arrives for a different principal, russh resets its internal auth state before dispatching the new request. This keeps username changes protocol-valid while preventing prior russh-owned auth state from carrying into the new principal.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "crates.io",
      "name" : "russh"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0.34.0-beta.1"
      }, {
        "fixed" : "0.61.0"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/Eugeny/russh/security/advisories/GHSA-hpv4-5h6f-wqr3"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-46705"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/Eugeny/russh"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-287" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-05-29T19:39:41Z",
    "nvd_published_at" : "2026-06-10T22:17:00Z"
  }
}