CVE-2026-42189

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

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:

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.

The application allocates resources such as memory, threads, or file descriptors based on untrusted input without enforcing a cap. Typical impact: resource exhaustion leading to denial of service.

CVE-2026-42189 has a CVSS score of 7.5 (High). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.60.1); upgrading removes the vulnerable code path.

Kodem intelligence

1. What is CVE-2026-42189? CVE-2026-42189 is a high-severity allocation of resources without limits or throttling vulnerability in russh (rust), affecting versions < 0.60.1. It is fixed in 0.60.1. The application allocates resources such as memory, threads, or file descriptors based on untrusted input without enforcing a cap.
2. How severe is CVE-2026-42189? CVE-2026-42189 has a CVSS score of 7.5 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of russh are affected by CVE-2026-42189? russh (rust) versions < 0.60.1 is affected.
4. Is there a fix for CVE-2026-42189? Yes. CVE-2026-42189 is fixed in 0.60.1. Upgrade to this version or later.
5. Is CVE-2026-42189 exploitable, and should I be worried? Whether CVE-2026-42189 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-42189 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-42189? Upgrade russh to 0.60.1 or later.