Most recent entries from all

EUVD-2026-326633

2026-10-05T09:47:18.618308+00:00

EUVD-2026-326633

fkie_cve-2026-46705

2026-10-05T09:47:18.618353+00:00

Russh is a Rust SSH client & server library. From version 0.34.0-beta.1 to before version 0.61.0, 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. This issue has been patched in version 0.61.0.

GHSA-hpv4-5h6f-wqr3 — russh server userauth state is not reset when authentication principal changes

2026-10-05T09:47:18.618394+00:00

Affected: crates.io: russh

### 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. - `p…