OSV 1.4.0 · github-reviewed · 修改于 2026-05-13 21:34
发布时间
2026-04-24 23:39
GitHub 审查时间
2026-04-24 23:39
NVD 发布时间
2026-05-09 04:16
源文件
advisories/github-reviewed/2026/04/GHSA-f5v4-2wr6-hqmg/GHSA-f5v4-2wr6-hqmg.json
A pre-authentication denial-of-service vulnerability exists in the server's keyboard-interactive authentication handler. A malicious client can crash any russh-based server that implements keyboard-interactive auth (e.g., for 2FA/TOTP) with a single malformed packet, requiring no credentials.
In russh/src/server/encrypted.rs, the function read_userauth_info_response decodes a u32 count from the client's SSH_MSG_USERAUTH_INFO_RESPONSE and passes it directly to Vec::with_capacity():
let n = map_err!(u32::decode(r))?;
// Bound both allocation and iteration by remaining packet data to
// prevent a malicious client from causing a multi-GB allocation or
// billions of loop iterations with a crafted count.
// Each response needs at least 4 bytes (length prefix).
let max_responses = r.remaining_len().saturating_add(3) / 4;
let n = (n as usize).min(max_responses);
let mut responses = Vec::with_capacity(n);
for _ in 0..n {
responses.push(Bytes::decode(r).ok())
}
An attacker can send n = 0x10000000 (268M) or larger in a minimal packet (~50 bytes after encryption). The server attempts to allocate n * ~24 bytes (size of Option<Bytes>) = ~6.4GB, causing an OOM crash.
USERAUTH_REQUEST with method keyboard-interactiveAuth::Partial with prompts (standard for 2FA/TOTP)USERAUTH_INFO_RESPONSE with n = 0x10000000 and no response dataVec::with_capacity(268_435_456), OOM killedNo authentication is required. The allocation occurs before the handler validates any credentials. The attack is repeatable faster than the server can restart.
Any russh-based server where the Handler::auth_keyboard_interactive implementation returns (i.e., sends prompts to the client). The default handler returns and is not affected.
Auth::PartialAuth::reject()Source code review suggests that downstream projects using keyboard-interactive for multi-step auth (e.g., TOTP/2FA) follow the affected pattern, since returning Auth::Partial before credential verification is the intended API usage for prompting.
There is a complete Docker-contained PoC confirming the OOM kill:
Auth::Partial for keyboard-interactiveUSERAUTH_INFO_RESPONSEAvailable on request.
Cap the Vec::with_capacity allocation to what the remaining packet data can actually contain. Each response requires at least 4 bytes (length prefix), so:
let n = map_err!(u32::decode(r))?;
// Bound both allocation and iteration by remaining packet data to
// prevent a malicious client from causing a multi-GB allocation or
// billions of loop iterations with a crafted count.
// Each response needs at least 4 bytes (length prefix).
let max_responses = r.remaining_len().saturating_add(3) / 4;
let n = (n as usize).min(max_responses);
let mut responses = Vec::with_capacity(n);
for _ in 0..n {
responses.push(Bytes::decode(r).ok())
}
This bounds the allocation to at most the packet size (~256KB), while preserving the existing behavior for well-formed packets. This fix has been implemented, tested, and contributed via the temporary private fork.
Pre-auth, remote, no credentials required, crashes the server process affecting all active sessions.