What is the CVSS score of CVE-2026-48107?

CVE-2026-48107 has a CVSS 3.1 base score of 6.5 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H. EPSS exploitation probability: 0.1%.

Is there a patch available for CVE-2026-48107?

Yes, a patch is available for CVE-2026-48107. Update the affected software to the latest version immediately.

Russh CVE-2026-48107

EUVD-2026-36129 MEDIUM

Improper Input Validation (CWE-20)

2026-06-10 GitHub_M

GHSA-g9g7-5cgw-6v28

Information Disclosure Russh

6.5

CVSS 3.1 · Vendor: GitHub_M

Severity by source

Vendor (GitHub_M) PRIMARY

6.5 MEDIUM

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

vuln.today AI

6.5 MEDIUM

Attacker controls a remote server (AV:N, AC:L, PR:N); client must connect voluntarily (UI:R); crash is client-local only (S:U); purely DoS, no data exposure (C:N, I:N, A:H).

3.1 AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

Required

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

Lifecycle Timeline

Patch available

Jun 10, 2026 - 22:01 EUVD

Analysis Generated

Jun 10, 2026 - 21:21 vuln.today

DescriptionCVE.org

Russh is a Rust SSH client & server library. From version 0.37.0 to before version 0.61.0, in the russh client keyboard-interactive authentication path, a malicious SSH server could send a USERAUTH_INFO_REQUEST with an attacker-controlled prompt count, and the client would use that raw count directly in Vec::with_capacity(...) before validating that enough prompt data was actually present in the packet. This issue has been patched in version 0.61.0.

AnalysisAI

Denial of service in Russh (versions 0.37.0-0.60.x), a Rust SSH client and server library, allows a malicious SSH server to crash connecting clients by exploiting improper input validation in the keyboard-interactive authentication path. The server supplies an attacker-controlled prompt count in a USERAUTH_INFO_REQUEST message, which the client passes directly to Vec::with_capacity() before verifying the packet contains the claimed number of prompts - resulting in a panic or out-of-memory condition that terminates the client process. No public exploit has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog.

Technical ContextAI

Russh (CPE: cpe:2.3:a:eugeny:russh:*:*:*:*:*:*:*:*) is a pure-Rust SSH protocol library implementing both client and server roles. The affected code path implements RFC 4256 keyboard-interactive authentication, where the server sends a USERAUTH_INFO_REQUEST SSH message containing a prompt-count field (a 32-bit unsigned integer). The client is expected to parse this count, verify the packet body contains that many prompts, then collect them. The defect (CWE-20: Improper Input Validation) is that the raw, server-supplied integer is fed directly into Vec::with_capacity() as the allocation hint before the packet is checked for sufficient data. In Rust, Vec::with_capacity() with a very large value causes an allocation attempt that may panic on OOM, and subsequent index-out-of-bounds reads on an underfilled vector produce panics that crash the process. Because the malicious server fully controls the USERAUTH_INFO_REQUEST payload, it can supply any arbitrary count value with zero or few actual prompts.

RemediationAI

Upgrade russh to version 0.61.0, which patches this vulnerability by validating the server-supplied prompt count against the actual packet data before calling Vec::with_capacity(). The fix is confirmed by the upstream GitHub Security Advisory GHSA-g9g7-5cgw-6v28 at https://github.com/Eugeny/russh/security/advisories/GHSA-g9g7-5cgw-6v28. Update your Cargo.toml dependency to russh = "0.61.0" or later and run cargo update to resolve. If an immediate upgrade is not possible, a compensating control is to disable keyboard-interactive authentication in russh client configuration and restrict the client to publickey or password authentication methods only - note this may break compatibility with servers that mandate keyboard-interactive. Additionally, restricting which SSH server hostnames or IP addresses the application may connect to (allowlisting) reduces the attack surface by preventing connections to attacker-controlled servers.