PT-2026-36863 · Crates.Io · Russh

Published

2026-04-24

·

Updated

2026-04-24

CVSS v3.1

7.5

High

VectorAV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Summary

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.

Vulnerability Details

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():
rust
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.

Attack Flow

  1. Attacker connects via TCP, completes key exchange (no credentials needed -- this is the anonymous DH handshake, not authentication)
  2. Sends USERAUTH REQUEST with method keyboard-interactive
  3. Server handler returns Auth::Partial with prompts (standard for 2FA/TOTP)
  4. Attacker sends USERAUTH INFO RESPONSE with n = 0x10000000 and no response data
  5. Server calls Vec::with capacity(268 435 456), OOM killed
No authentication is required. The allocation occurs before the handler validates any credentials. The attack is repeatable faster than the server can restart.

Affected Configurations

Any russh-based server where the Handler::auth keyboard interactive implementation returns Auth::Partial (i.e., sends prompts to the client). The default handler returns Auth::reject() and is not affected.
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.

Confirmed End-to-End PoC

There is a complete Docker-contained PoC confirming the OOM kill:
  • Minimal russh server returning Auth::Partial for keyboard-interactive
  • Python client (paramiko for key exchange) sends malformed USERAUTH INFO RESPONSE
  • Container with 512MB memory limit; server is OOM-killed (exit code 137)
Available on request.

Proposed Fix

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:
rust
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.

Severity

Pre-auth, remote, no credentials required, crashes the server process affecting all active sessions.

Fix

Allocation of Resources Without Limits

Found an issue in the description? Have something to add? Feel free to write us 👾
dbugs@ptsecurity.com

Weakness Enumeration

CWE-789CWE-770

Related Identifiers

GHSA-F5V4-2WR6-HQMG

Affected Products

Russh