CVE-2026-48107: Russh Keyboard-Interactive Auth DoS Vulnerability (v0.37.0–0.60.x)

Technical summary

The vulnerability exists in the keyboard-interactive authentication flow of russh versions 0.37.0 through 0.60.x. During USERAUTH_INFO_REQUEST handling, the client extracts a prompt count field from the SSH packet and passes it directly to Vec::with_capacity() to pre-allocate a vector before parsing the actual prompt data. An attacker can craft a USERAUTH_INFO_REQUEST with an inflated prompt count that does not match the amount of prompt data present in the packet. This causes the client to either: (1) wait indefinitely for data that will not arrive, or (2) fail when attempting to access memory that was not populated. The root cause is insufficient input validation—the prompt count is used without confirming that the remaining packet data can satisfy it. This is classified as improper input validation (CWE-20). The patched version 0.61.0 corrects this by validating the prompt count against available packet data before memory allocation.

Business impact

Organizations and developers using russh in SSH client applications face availability risk. Any application that accepts keyboard-interactive authentication from untrusted or compromised SSH servers could be crashed by a malicious server response. For applications where SSH client libraries are embedded in larger services—such as infrastructure automation, CI/CD pipelines, or remote management tools—this denial-of-service condition could disrupt critical workflows. The impact is localized to client availability rather than data breach or integrity compromise, but repeated crashes could affect operational continuity. Development teams maintaining Rust-based SSH clients must prioritize inventory and upgrade planning.

Affected systems

Russh library versions 0.37.0 through 0.60.x are affected. Any Rust application or library that depends on russh as a client for keyboard-interactive SSH authentication is potentially impacted. Applications that use only non-interactive authentication methods (such as public-key or password-based without the keyboard-interactive variant) may be less immediately exposed, though dependency chains can be complex. The vulnerability is in the client authentication code, not the server implementation, so russh-based SSH servers are not directly vulnerable. Organizations should audit their Rust dependency trees to identify applications using affected russh versions.

Exploitability

Exploitation is straightforward from a network perspective—it requires no authentication or special privileges, and does not require the attacker to compromise the client machine. However, practical exploitation depends on the attacker's ability to direct a target client to connect to a malicious SSH server or to perform a man-in-the-middle attack on an existing SSH connection. The attack surface is therefore conditional on network position or social engineering. Once a vulnerable client connects, a single malformed USERAUTH_INFO_REQUEST can trigger the denial-of-service condition. The technical complexity of crafting the malicious packet is low. CVSS score 6.5 (MEDIUM) reflects the ease of network exploitation but limited scope—only the connected client is affected, not confidentiality or integrity of the system.

Remediation

The immediate remediation is to upgrade russh to version 0.61.0 or later. This version includes validation of the prompt count against available packet data before memory allocation. For applications that cannot update immediately, temporary mitigations include restricting keyboard-interactive authentication in SSH client configurations where feasible, or using network-level controls to limit connections to trusted SSH servers only. However, these are defensive measures and not substitutes for patching. Development and DevOps teams should prioritize this update in their dependency management and release cycles.

Patch guidance

Verify your application's russh dependency version by checking Cargo.lock or Cargo.toml. If the version is 0.37.0 or any version through 0.60.x, an update is required. Upgrade to russh 0.61.0 or a later release by updating your Cargo.toml dependency line to the new version and running 'cargo update'. Test the update in a development or staging environment to confirm compatibility, as major version bumps sometimes include breaking API changes (though russh typically maintains backward compatibility in patch and minor updates). If your application is transitive (i.e., russh is a dependency of a dependency), ensure the parent dependency also supports or has updated to a non-vulnerable russh version. Consult the russh GitHub releases page for detailed changelog and migration notes.

Detection guidance

Detection requires understanding your deployment's SSH client configuration and dependency inventory. For development and build environments: examine Cargo.lock files in all Rust projects to identify russh versions in use. For runtime detection: if your SSH client is logging connection events, monitor for unusual disconnections or hangs during keyboard-interactive authentication with specific servers—these may indicate exploitation attempts. Network-based detection is challenging because the malicious USERAUTH_INFO_REQUEST appears as a valid SSH protocol message, though deep packet inspection could identify crafted prompt counts that exceed packet data bounds. Runtime instrumentation or memory allocation monitoring in controlled environments might flag unexpected pre-allocation patterns, but this is not a reliable detection method at scale. Prioritize inventory scanning and version auditing as your primary detection approach.

Why prioritize this

This vulnerability should be prioritized by any organization using russh-based SSH clients, particularly in critical infrastructure, automation, or deployment pipeline roles. While the CVSS score is MEDIUM and no public exploit is reported as weaponized or in the KEV catalog, the ease of exploitation and the potential for disruption in automated SSH-based workflows elevate operational risk. Teams managing CI/CD pipelines, infrastructure-as-code deployments, or remote administration tools that rely on keyboard-interactive SSH authentication should treat this as a near-term patch target. The fix is straightforward and low-risk (a version upgrade with minimal API changes), making delay difficult to justify. Prioritization should be higher if keyboard-interactive authentication is actively used in your SSH client configuration; lower if your deployment relies solely on key-based or password-based authentication without the interactive variant.

Risk score, explained

The CVSS 3.1 base score of 6.5 (MEDIUM) reflects: network-accessible attack vector (AV:N), low attack complexity (AC:L), no privilege requirement (PR:N), user interaction required in the sense that the client must initiate a connection (UI:R), and impact limited to the attacked service's availability (A:H) with no confidentiality or integrity impact (C:N, I:N). The 'user interaction' component refers to the client choosing to connect to or being directed to the attacker's server, not to an end-user clicking a button. This score appropriately captures that while the denial-of-service is easily triggered and requires no authentication, it is localized to individual client connections and does not threaten data or system-wide operations. Temporal adjustments might apply once patches are widely deployed and the remediation effort is measured across the ecosystem.

Frequently asked questions