Update Rust crate russh to 0.61 [SECURITY] by renovate[bot] · Pull Request #191 · trydirect/stacker

renovate · 2026-07-01T22:40:22Z

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Type	Update	Change
russh	dependencies	minor	`0.58` → `0.61`

russh has pre-auth DoS via unbounded allocation in its keyboard-interactive auth handler

CVE-2026-42189 / GHSA-f5v4-2wr6-hqmg

More information

Details

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

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

Attacker connects via TCP, completes key exchange (no credentials needed -- this is the anonymous DH handshake, not authentication)
Sends USERAUTH_REQUEST with method keyboard-interactive
Server handler returns Auth::Partial with prompts (standard for 2FA/TOTP)
Attacker sends USERAUTH_INFO_RESPONSE with n = 0x10000000 and no response data
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.

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Russh: Unchecked CryptoVec allocation and growth handling is reachable

CVE-2026-46673 / GHSA-g9f8-wqj9-fjw5

More information

Details

Title

Unchecked CryptoVec allocation and growth handling was reachable from local agent inputs in current russh releases and from remote SSH traffic in historical pre-0.58.0 releases

Summary

CryptoVec used unchecked capacity growth, unchecked length arithmetic, and unsafe allocation/locking paths. In current russh releases, local SSH agent peers could still feed attacker-controlled frame lengths into buffer growth before validation. In older russh releases before 0.58.0, remote SSH traffic also reached CryptoVec through transport and compression buffers.

Details

The underlying unsafe paths were in CryptoVec:

cryptovec/src/cryptovec.rs
- unchecked capacity growth
- unchecked length arithmetic in growth callers
- raw allocation and reallocation paths coupled to those sizes
cryptovec/src/platform/unix.rs
- mlock / munlock previously accepted zero-length calls and performed null-pointer validation inside the unsafe OS-call path

There are two relevant reachability stories:

current local reachability in russh

russh/src/keys/agent/client.rs
- AgentClient::read_response() read a peer-supplied u32 length and then resized self.buf to that value before reading the payload
russh/src/keys/agent/server.rs
- Connection::run() read a peer-supplied u32 length and then resized self.buf to that value before reading the payload

This is the path that still existed in current 0.60.x releases before the fix, although by then those buffers were no longer CryptoVec.

historical remote reachability in older russh

before commit 712e32b (first released in v0.58.0), non-secret transport and compression buffers in russh still used CryptoVec
I verified this in a detached pre-712e32b worktree by adding and running:
- cipher::tests::remote_packet_length_grows_transport_cryptovec_buffer
- compression::tests::remote_compressed_payload_expands_cryptovec_output
those tests show that remote SSH traffic could grow CryptoVec through:
- transport packet reads
- zlib decompression output

Also added a constrained-memory reproduction in that historical worktree:

compression::tests::remote_compressed_payload_can_crash_under_memory_limit

That test re-execs the test binary under prlimit --as=134217728, decompresses a highly compressible payload that expands to 96 MiB, and reliably aborts in the old Unix CryptoVec path when NonNull::new_unchecked() receives a null pointer after allocation failure.

The prepared patch does two things:

hardens CryptoVec itself
- checked capacity growth
- checked length arithmetic
- immediate allocation-failure handling
- zero-length mlock / munlock no-ops
- explicit null-pointer validation before entering the Unix unsafe locking calls
hardens the real untrusted-input path
- caps agent frame lengths at 256 * 1024 on both client and server before resizing buffers

This cap matches OpenSSH’s agent framing guardrail.

PoC

The following end-to-end tests demonstrate the real untrusted-input path by feeding oversized peer-controlled agent frame lengths into the public client and server flows and asserting that they are rejected before buffer growth.

Client-side agent reply path:

#[test]
fn oversized_agent_response_is_rejected_before_allocation() -> std::io::Result<()> {
    let runtime = tokio::runtime::Builder::new_current_thread()
        .enable_all()
        .build()?;

    runtime.block_on(async {
        let (mut writer, reader) = tokio::io::duplex(64);
        let server = tokio::spawn(async move {
            let mut frame = [0u8; 4];
            writer.read_exact(&mut frame).await?;
            let len = BigEndian::read_u32(&frame) as usize;
            let mut body = vec![0; len];
            writer.read_exact(&mut body).await?;

            BigEndian::write_u32(&mut frame, (MAX_AGENT_FRAME_LEN + 1) as u32);
            writer.write_all(&frame).await?;
            Ok::<(), std::io::Error>(())
        });

        let mut client = AgentClient::connect(reader);
        let err = client.request_identities().await.unwrap_err();
        assert!(matches!(err, Error::AgentProtocolError));
        server.await.expect("server task")?;
        Ok::<(), std::io::Error>(())
    })?;

    Ok(())
}

Server-side agent request path:

#[test]
fn oversized_agent_request_is_rejected_before_allocation() -> std::io::Result<()> {
    let runtime = tokio::runtime::Builder::new_current_thread()
        .enable_all()
        .build()?;

    runtime.block_on(async {
        let (server, mut client) = tokio::io::duplex(64);
        let connection = Connection {
            lock: Lock(std::sync::Arc::new(std::sync::RwLock::new(crate::CryptoVec::new()))),
            keys: KeyStore(std::sync::Arc::new(std::sync::RwLock::new(
                std::collections::HashMap::new(),
            ))),
            agent: Some(()),
            s: server,
            buf: Vec::new(),
        };
        let server = tokio::spawn(async move { connection.run().await });

        let mut frame = [0u8; 4];
        BigEndian::write_u32(&mut frame, (MAX_AGENT_FRAME_LEN + 1) as u32);
        client.write_all(&frame).await?;
        drop(client);

        let err = server.await.expect("server task").unwrap_err();
        assert!(matches!(err, Error::AgentProtocolError));
        Ok::<(), std::io::Error>(())
    })?;

    Ok(())
}

These tests pass on the fixed branch and fail on unfixed v0.60.2, where oversized agent frame lengths are not rejected at the framing boundary.

For historical russh < 0.58.0, I also verified remote reachability into CryptoVec in a detached pre-712e32b worktree (91d431d, package version 0.57.1).

Transport packet read path:

#[test]
fn remote_packet_length_grows_transport_cryptovec_buffer() -> std::io::Result<()> {
    let runtime = tokio::runtime::Builder::new_current_thread()
        .enable_all()
        .build()?;

    runtime.block_on(async {
        let packet_len = MAXIMUM_PACKET_LEN;
        let (mut writer, mut reader) = tokio::io::duplex(packet_len + 4);
        let writer_task = tokio::spawn(async move {
            let mut packet = vec![0u8; packet_len + 4];
            packet[..4].copy_from_slice(&(packet_len as u32).to_be_bytes());
            writer.write_all(&packet).await?;
            Ok::<(), std::io::Error>(())
        });

        let mut buffer = SSHBuffer::new();
        let mut cipher = clear::Key;
        let n = read(&mut reader, &mut buffer, &mut cipher).await.unwrap();

        assert_eq!(n, packet_len + 4);
        assert_eq!(buffer.buffer.len(), packet_len + 4);
        assert_eq!(&buffer.buffer[..4], &(packet_len as u32).to_be_bytes());

        writer_task.await.expect("writer task")?;
        Ok::<(), std::io::Error>(())
    })?;

    Ok(())
}

Compression growth path:

#[test]
fn remote_compressed_payload_expands_cryptovec_output() {
    let payload = vec![b'A'; 64 * 1024];

    let compression = Compression::new(&ZLIB);
    let mut compressor = Compress::None;
    let mut decompressor = Decompress::None;
    compression.init_compress(&mut compressor);
    compression.init_decompress(&mut decompressor);

    let mut compressed = CryptoVec::new();
    let encoded = compressor
        .compress(&payload, &mut compressed)
        .expect("compress")
        .to_vec();

    let mut output = CryptoVec::new();
    let decoded = decompressor
        .decompress(&encoded, &mut output)
        .expect("decompress");

    assert_eq!(decoded.len(), payload.len());
    assert_eq!(decoded, payload.as_slice());
    assert!(encoded.len() < output.len());
}

Constrained-memory crash reproduction for the historical remote compression path:

#[test]
fn remote_compressed_payload_can_crash_under_memory_limit() {
    const CHILD_ENV: &str = "RUSSH_REMOTE_COMPRESS_CRASH_CHILD";

    if std::env::var_os(CHILD_ENV).is_some() {
        let payload = vec![b'A'; 96 * 1024 * 1024];

        let compression = Compression::new(&ZLIB);
        let mut compressor = Compress::None;
        let mut decompressor = Decompress::None;
        compression.init_compress(&mut compressor);
        compression.init_decompress(&mut decompressor);

        let mut compressed = CryptoVec::new();
        let encoded = compressor
            .compress(&payload, &mut compressed)
            .expect("compress")
            .to_vec();

        let mut output = CryptoVec::new();
        let decoded = decompressor
            .decompress(&encoded, &mut output)
            .expect("decompress");
        assert_eq!(decoded.len(), payload.len());
        return;
    }

    let exe = std::env::current_exe().expect("current exe");
    let status = Command::new("prlimit")
        .args([
            "--as=134217728",
            "--",
            exe.to_str().expect("utf8 exe path"),
            "--exact",
            "compression::tests::remote_compressed_payload_can_crash_under_memory_limit",
            "--nocapture",
        ])
        .env(CHILD_ENV, "1")
        .status()
        .expect("spawn child");

    assert!(
        !status.success(),
        "expected child to fail under constrained address space"
    );
}

On that historical worktree, the constrained-memory child aborts in the old Unix CryptoVec path with:

unsafe precondition(s) violated: NonNull::new_unchecked requires that the pointer is non-null
thread caused non-unwinding panic. aborting.

To run the reproduced checks:

cargo test -p russh oversized_agent_response_is_rejected_before_allocation -- --nocapture
cargo test -p russh oversized_agent_request_is_rejected_before_allocation -- --nocapture
cargo test -p russh-cryptovec

Historical pre-0.58.0 checks were run from the detached 91d431d worktree with:

cargo test --offline -p russh remote_packet_length_grows_transport_cryptovec_buffer -- --nocapture
cargo test --offline -p russh remote_compressed_payload_expands_cryptovec_output -- --nocapture
cargo test --offline -p russh remote_compressed_payload_can_crash_under_memory_limit -- --nocapture

Impact

This is a memory-safety hardening issue with demonstrated untrusted-input reachability.

What is demonstrated:

current local agent peers could previously reach allocation growth directly from attacker-controlled frame lengths
historical remote SSH traffic could previously reach CryptoVec through transport and compression buffers in russh < 0.58.0
under constrained memory, the historical remote compression path can be turned into a process abort in the old Unix CryptoVec code
the fixed code now rejects oversized agent frames early and hardens the underlying allocation paths

What is not demonstrated:

practical code execution
a demonstrated integrity or confidentiality break

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

russh: Post-decompression SSH packet size was not bounded, allowing remote oversized compressed packets

CVE-2026-46702 / GHSA-wwx6-x28x-8259

More information

Details

Summary

When SSH compression is enabled, russh accepted compressed packets whose on-wire size passed the normal transport packet-length checks but whose decompressed size was much larger. This allowed a remote peer to send oversized post-decompression packets that should have been rejected.

In current releases, this is a remote denial-of-service / resource-exhaustion issue in the post-decompression receive path.

In older releases before 0.58.0, the same remote decompression path used CryptoVec, which appears to make the historical impact worse.

Details

The normal SSH transport read path enforces a packet-length limit before the packet body is read:

russh/src/cipher/mod.rs

However, RFC 4253 compression is applied to the SSH payload field only. The packet_length field and MAC are computed over the compressed payload, so a packet that is reasonably sized on the wire can still expand to a much larger message body after decompression.

In russh, compressed packet bodies are later decompressed in:

russh/src/compression.rs
russh/src/client/mod.rs
russh/src/server/session.rs

Before the fix, Decompress::decompress() grew its output buffer by repeated doubling and did not enforce a separate post-decompression ceiling. That meant a peer could send a small compressed packet that passed the normal on-wire transport length checks and then inflate it into a much larger packet after decompression.

It was verified that an attacker-crafted compressed payload can stay below the normal 256 KiB implementation transport packet cap while still inflating above the intended post-decompression bound. In other words, this is not only a "large on-wire packet" issue.

Version detail:

The underlying post-decompression bounds bug appears to affect russh as far back as 0.34.0.
In historical releases >= 0.34.0, < 0.58.0, the remote decompression path still used CryptoVec. Remote compressed SSH traffic could drive that path, and under constrained memory that historical code path could abort the process.
In current-style releases >= 0.58.0, non-secret packet/decompression buffers were moved off CryptoVec and onto Vec<u8>, but the post-decompression size still remained unbounded. So the bug class remained reachable remotely, but the maintained-line impact is a current remote DoS / oversized-packet-acceptance issue rather than the older CryptoVec-based abort story.
The maintained-line fix was verified against 0.60.2.

Compression is not selected in a default-vs-default russh session because the default preference order puts none first. However, the default server configuration still advertises zlib and zlib@openssh.com, and server-side negotiation follows the client's preference order for common algorithms. A client that prefers compression can therefore negotiate it with a default russh server.

OpenSSH portable was checked at /home/mjc/projects/openssh-portable commit 45b30e0a5. OpenSSH enforces a 256 KiB transport packet cap before decompression, but it does not reuse that cap after decompression. Instead, decompression writes to an sshbuf, which is indirectly bounded by OpenSSH's SSHBUF_SIZE_MAX hard maximum of 0x8000000 bytes (128 MiB).

The patch direction should follow that model: add an explicit post-decompression ceiling of 128 MiB, rather than assuming the compressed transport packet cap also bounds decompressed payload size.

Relevant OpenSSH reference points:

/home/mjc/projects/openssh-portable/packet.c: PACKET_MAX_SIZE (256 * 1024)
/home/mjc/projects/openssh-portable/packet.c: uncompress_buffer() inflates into compression_buffer
/home/mjc/projects/openssh-portable/sshbuf.h: SSHBUF_SIZE_MAX 0x8000000

RFC / OpenSSH Comparison

RFC 4253 section 6 defines the binary packet format:

packet_length
padding_length
payload
random padding
MAC

RFC 4253 section 6.2 says that, when compression is negotiated, the payload field is compressed, and that packet_length and MAC are computed from the compressed payload. The RFC also says implementations should check that packet length is reasonable to avoid denial-of-service and buffer-overflow attacks.

That means the pre-decompression transport packet length check is necessary but not sufficient. A correct implementation still needs a reasonable bound on the decompressed payload that becomes parser input.

OpenSSH provides such a bound indirectly through sshbuf's hard maximum. The russh fix should make the corresponding post-decompression bound explicit.

PoC

There were two kinds of proof:

a wire-cap sanity test showing an attacker-crafted best-compressed DEBUG payload can stay below the normal SSH transport packet cap while still inflating beyond the intended post-decompression bound
direct client and server receive-path tests that exercise the oversized post-decompression behavior itself

The current in-tree regression tests are:

tests::compress::oversized_debug_payload_can_stay_below_wire_cap
compression::tests::oversized_decompressed_packet_is_rejected
client::tests::compressed_debug_is_ignored_after_client_parses_it
client::tests::oversized_compressed_debug_is_rejected_before_client_ignores_it
server::session::tests::compressed_debug_is_ignored_after_server_parses_it
server::session::tests::oversized_compressed_debug_is_rejected_before_server_ignores_it

The important behavior is:

An attacker-crafted best-compressed DEBUG payload can stay below the normal 256 KiB transport packet cap while still inflating beyond 128 MiB.
In the direct client and server receive paths, small compressed DEBUG packets are still ignored normally after parsing.
In the direct client and server receive paths, oversized compressed DEBUG packets are rejected before the implementation reaches the normal "ignore DEBUG" behavior.

The strongest PoC for severity is the unauthenticated server-side case. A malicious client can choose zlib in the initial key exchange, because the default server advertises it and server-side negotiation follows the client's preference order for common algorithms. After NEWKEYS, but before authentication, the client can send a transport-layer SSH_MSG_DEBUG packet whose compressed body is below the transport packet cap but whose decompressed body exceeds the post-decompression cap.

That demonstrates the AV:N/AC:L/PR:N/UI:N case directly: the attacker is a remote SSH client and does not need a successfully authenticated session.

fn compressed_debug_payload(payload_len: usize) -> Vec<u8> {
    let mut payload = vec![b'A'; payload_len];
    payload[0] = crate::msg::DEBUG;

    let mut encoder =
        flate2::write::ZlibEncoder::new(Vec::new(), flate2::Compression::best());
    encoder.write_all(&payload).unwrap();
    let compressed = encoder.finish().unwrap();

    assert!(
        compressed.len() < 256 * 1024,
        "oversized post-decompression payload still fits under the wire cap"
    );
    compressed
}

fn incoming_packet(compressed: Vec<u8>) -> SSHBuffer {
    let mut buffer = SSHBuffer::new();
    // maybe_decompress() receives the clear SSHBuffer after packet framing,
    // and decompresses bytes after packet_length + padding_length.
    buffer.buffer.extend_from_slice(&[0; 5]);
    buffer.buffer.extend_from_slice(&compressed);
    buffer
}

#[test]
fn unauthenticated_client_zlib_debug_is_rejected_by_server_before_auth() {
    let mut server = preauth_server_session_after_newkeys_with_zlib_decompressor();
    let oversized = MAXIMUM_DECOMPRESSED_PACKET_LEN + 1024;
    let buffer = incoming_packet(compressed_debug_payload(oversized));

    let err = server.maybe_decompress(&buffer).unwrap_err();
    assert!(
        matches!(err, crate::Error::PacketSize(len) if len > MAXIMUM_DECOMPRESSED_PACKET_LEN)
    );
}

The equivalent wire-level attack shape is:

1. Connect to a russh server using the default compression advertisement.
2. Send SSH_MSG_KEXINIT with compression client-to-server preference:
   zlib,zlib@openssh.com,none
3. Complete key exchange and send SSH_MSG_NEWKEYS.
4. Before any SSH_MSG_USERAUTH_REQUEST, send a compressed SSH_MSG_DEBUG packet:
   - compressed packet body: < 256 KiB
   - decompressed packet body: > 128 MiB
5. Vulnerable behavior: russh accepts and inflates the packet, then reaches the
   normal DEBUG ignore path.
6. Fixed behavior: russh rejects during decompression with Error::PacketSize.

The direct receive-path client/server regression tests are still useful because they isolate the bug precisely. They construct the post-decryption compressed packet body passed to maybe_decompress() and prove that the oversized packet is rejected before normal DEBUG ignore handling. The server-side pre-auth variant above is the one that justifies the highest CVSS framing for this bug.

The most important targeted checks are:

cargo test -p russh oversized_debug_payload_can_stay_below_wire_cap -- --nocapture
cargo test -p russh oversized_compressed_debug_is_rejected_before_client_ignores_it -- --nocapture
cargo test -p russh oversized_compressed_debug_is_rejected_before_server_ignores_it -- --nocapture

Before the fix, both the direct client and direct server receive-path oversized checks went red because the compressed payload was accepted and decompressed instead of being rejected at the post-decompression boundary. After the fix, they pass.

Impact

Suggested CVSS v3.1 for current maintained releases:

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 by a remote SSH peer
AC:L: straightforward once compression is enabled
PR:N, UI:N: no prior auth or user interaction required
C:N, I:N: confidentiality or integrity impact was not demonstrated
A:H: remote peer can cause oversized post-decompression packet processing and disconnect / denial of service

Affected versions:

historical stronger case: russh >= 0.34.0, < 0.58.0
current maintained remote DoS case: russh >= 0.58.0, including 0.60.3

Fix / Patch Direction

Add an explicit maximum decompressed SSH packet size and enforce it inside Decompress::decompress() before returning decompressed bytes to the client or server packet parser.

The intended ceiling is 128 MiB, matching OpenSSH portable's effective sshbuf hard maximum for post-decompression packet storage. The fix should reject decompression output larger than that bound with a packet-size error before normal message dispatch.

The fix should preserve normal compressed packet behavior below the cap, including DEBUG packets that are decompressed and then ignored through the existing normal path.

Patch branch:

fix/zlib-decompression-cap

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

russh server userauth state is not reset when authentication principal changes

CVE-2026-46705 / GHSA-hpv4-5h6f-wqr3

More information

Details

Summary

The russh server authentication path keeps internal userauth state across SSH_MSG_USERAUTH_REQUEST messages without separating that state when the request principal changes.

RFC 4252 allows the user name and service name fields to change between authentication requests. The issue is not that such changes are invalid. The issue is that russh-owned authentication state, such as remaining methods, partial-success state, and in-progress method state, can remain associated with the connection and then influence a later request for a different (user, service).

This is an internal library state mismatch. Applications are responsible for any authentication state they keep in their own handlers, but russh must reset or separate state that russh itself owns.

Details

The relevant server-side auth logic is in:

russh/src/server/encrypted.rs
russh/src/auth.rs

RFC 4252 section 5 says the user name and service name fields are repeated in every SSH_MSG_USERAUTH_REQUEST and may change. It also says the server implementation must check those fields in every message and flush accumulated authentication state if they change; if it cannot flush that state, it must disconnect.

In vulnerable russh code, the username and service are decoded from each SSH_MSG_USERAUTH_REQUEST, while the AuthRequest state remains connection-scoped. That state includes:

methods, which is later encoded as the SSH_MSG_USERAUTH_FAILURE remaining-methods list.
partial_success, which is later encoded in SSH_MSG_USERAUTH_FAILURE.
current, which tracks in-progress method state such as public-key offer or keyboard-interactive challenge state.
rejection_count.

If one request narrows russh's internal methods set, a later request for a different user can observe that narrowed set unless the internal state is reset at the principal boundary.

PoC

The PoC demonstrates only russh-owned state. The handler does not store any cross-request state. Alice's request narrows russh's remaining methods to password; Bob's later plain reject should not reuse that internal state.

struct RemainingMethodsUserSwitchServer;

impl server::Handler for RemainingMethodsUserSwitchServer {
    type Error = russh::Error;

    async fn auth_none(&mut self, user: &str) -> Result<server::Auth, Self::Error> {
        if user == "alice" {
            Ok(server::Auth::Reject {
                proceed_with_methods: Some(MethodSet::from(&[MethodKind::Password][..])),
                partial_success: true,
            })
        } else {
            Ok(server::Auth::reject())
        }
    }
}

#[tokio::test]
async fn auth_does_not_carry_remaining_methods_across_username_change() {
    let alice = session.authenticate_none("alice").await.unwrap();

    assert!(matches!(
        alice,
        client::AuthResult::Failure {
            ref remaining_methods,
            ..
        } if *remaining_methods == MethodSet::from(&[MethodKind::Password][..])
    ));

    let bob = session.authenticate_none("bob").await.unwrap();

    if let client::AuthResult::Failure {
        remaining_methods, ..
    } = bob {
        assert!(
            remaining_methods.contains(&MethodKind::PublicKey),
            "server reused Alice's narrowed remaining methods for Bob: {remaining_methods:?}"
        );
    }
}

On upstream/main, this fails with:

server reused Alice's narrowed remaining methods for Bob: MethodSet([Password])

That failure is produced by russh's retained AuthRequest.methods; it does not depend on handler-owned MFA/session state.

Impact

Suggested provisional CVSS v3.1:

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

Reasoning:

AV:N: reachable by a remote SSH client during authentication.
AC:L: the attack is a normal sequence of SSH user-auth packets.
PR:N: the attacker does not need an already-authenticated SSH session.
UI:N: no user interaction is required on the server side.
S:U: the impact is within the vulnerable SSH server implementation.
C:N: the narrow PoC does not disclose confidential data.
I:L: russh-owned authentication state for one principal can affect the authentication flow for a different principal.
A:N: the narrow PoC does not demonstrate an availability impact.

This report does not claim that username changes are inherently invalid, nor does it rely on application-owned authentication state being mishandled by the embedding server.

Fix / Patch Direction

The fix should update russh's internal userauth state handling so that accumulated russh-owned state is flushed or separated when (user, service) changes between SSH_MSG_USERAUTH_REQUEST messages.

The fix stores the last seen (user, service) on AuthRequest. When a new auth request arrives for a different principal, russh resets its internal auth state before dispatching the new request. This keeps username changes protocol-valid while preventing prior russh-owned auth state from carrying into the new principal.

Severity

CVSS Score: 5.3 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Russh: Unchecked keyboard-interactive prompt count in client auth path

CVE-2026-48107 / GHSA-g9g7-5cgw-6v28

More information

Details

Summary

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 is a client-side denial-of-service / resource-exhaustion issue on the keyboard-interactive auth path.

Details

The vulnerable code path is in:

russh/src/client/encrypted.rs

When the client is in CurrentRequest::KeyboardInteractive state and receives SSH_MSG_USERAUTH_INFO_REQUEST, it parses:

name
instructions
language tag
n_prompts

Before the fix, the code then did:

let n_prompts = map_err!(u32::decode(&mut r))?;
let mut prompts = Vec::with_capacity(n_prompts.try_into().unwrap_or(0));

That means a malicious server could advertise an enormous n_prompts value even if the packet contained no prompt bodies at all.

The fix rejects inconsistent prompt counts before allocating:

let n_prompts = map_err!(u32::decode(&mut r))?;
let max_prompts = r.remaining_len() / 5;
let n_prompts = n_prompts as usize;
if n_prompts > max_prompts {
    return Err(crate::Error::Inconsistent.into());
}
let mut prompts = Vec::with_capacity(n_prompts);

Each prompt needs at least 4 bytes of string length plus 1 byte of echo flag, so remaining_len() / 5 is a safe upper bound. If the declared count exceeds what the packet can actually contain, the packet is malformed and is now rejected instead of being silently truncated.

The tester did not find a same-class server-side bug in the reciprocal USERAUTH_INFO_RESPONSE path. The server already bounds the response count by remaining packet length before allocating.

Affected package and versions:

package: russh
earliest affected stable: 0.37.0
confirmed affected current release: 0.60.2

The tester does not believe this issue affects the other crates in this workspace (russh-config, russh-cryptovec, pageant, or russh-util).

PoC

An in-tree regression test was added:

client::tests::oversized_keyboard_interactive_prompt_count_is_rejected

The test builds a client session in WaitingAuthRequest(KeyboardInteractive) state, feeds it a synthetic USERAUTH_INFO_REQUEST packet with:

normal name
normal instructions
empty language tag
n_prompts = u32::MAX
no prompt bodies

On the fixed code, the client rejects the packet with Error::Inconsistent and does not emit a reply to the caller.

For old-code impact verification, the pre-fix path was also checked separately with a constrained-memory repro. On unfixed upstream/main, the same malformed packet attempted a very large allocation and failed with:

memory allocation of 137438953440 bytes failed

Relevant verification commands:

cargo test -p russh oversized_keyboard_interactive_prompt_count_is_rejected -- --nocapture
cargo test -p russh --lib --no-default-features --features ring oversized_keyboard_interactive_prompt_count_is_rejected -- --nocapture

Impact

Suggested CVSS v3.1:

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

Reasoning:

AV:N: reached by a malicious SSH server over the network
AC:L: the packet format is straightforward
PR:N: no prior authentication required
UI:R: the victim must initiate a connection and proceed into keyboard-interactive auth
C:N, I:N: Confidentiality or integrity impact were not demonstrated
A:H: the server can drive a very large allocation attempt in the client auth path, which can abort or exhaust client-side resources depending on allocator and platform behavior

Severity

CVSS Score: 6.5 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Russh: SSH identification parsing accepted non-canonical client banners and did not bound pre-banner input

CVE-2026-48108 / GHSA-76r6-x97p-67vr

More information

Details

Summary

russh did not enforce the SSH identification-string rules as deliberately as OpenSSH. In particular, the server-side identification reader used the same permissive path as the client, allowing pre-banner lines from clients, and the reader did not enforce a bounded number of pre-banner lines.

For a library server built on russh, this could allow a remote peer to hold connection setup resources in the cleartext pre-authentication phase with malformed identification input that should have been rejected early.

Details

RFC 4253 section 4.2 defines the SSH protocol version exchange. The identification string is a single line terminated by CR LF, must fit within 255 characters including CR LF, and clients should not send pre-banner lines before their SSH identification string.

Before the fix, russh's identification reader lived in:

russh/src/ssh_read.rs
russh/src/server/mod.rs

The same read_ssh_id() behavior was used for both client and server contexts. That allowed server-side parsing to accept preliminary banner lines from clients, even though RFC 4253 only describes server-side pre-identification text. The reader also discarded preliminary lines without a line-count cap, so a peer could repeatedly send short non-SSH lines and keep the connection in identification parsing until an application-level timeout or external resource limit intervened.

This also creates a remotely observable parser-state oracle inside a single connection. A client can send candidate identification lines one after another: lines not recognized as SSH identification are discarded as pre-banner text, while an accepted identification string terminates banner parsing and advances the connection into key exchange. A strict server would reject the first invalid client pre-banner line and force a reconnect for each probe. This can disclose server-side parser acceptance behavior and make fingerprinting cheaper, though it does not disclose application secrets, credentials, keys, or authenticated user data.

The patch splits the behavior between generic/server-banner-tolerant reading and stricter client-identification reading. It also adds explicit limits for line length and pre-banner line count.

Relevant branch commit:

3de4a68 Harden SSH identification parsing

RFC / OpenSSH Comparison

RFC 4253 section 4.2 says each side sends an identification string of the form SSH-protoversion-softwareversion SP comments CR LF. It allows a server to send other lines before its identification string, but says a client must be able to process such lines. It does not grant the same pre-banner allowance to clients.

OpenSSH portable enforces explicit identification limits:

/home/mjc/projects/openssh-portable/ssh.h: SSH_MAX_BANNER_LEN
/home/mjc/projects/openssh-portable/ssh.h: SSH_MAX_PRE_BANNER_LINES
/home/mjc/projects/openssh-portable/kex.c: client-side handling of server pre-banner lines
/home/mjc/projects/openssh-portable/ssh_api.c: rejects pre-banner lines when acting as a server

I checked /home/mjc/projects/openssh-portable at 45b30e0a5. OpenSSH uses an implementation banner line limit of 8192 bytes and a pre-banner line cap of 1024, which is more permissive than RFC 4253's 255-character identification-string limit. The relevant alignment is the parser shape: OpenSSH permits bounded pre-banner lines when reading a server banner as a client, but rejects pre-banner lines when acting as a server and reading a client identification string.

The russh fix follows that shape: accept bounded pre-banner lines only where the protocol allows them, and reject malformed or excessive identification input early.

PoC

Inline highest-CVSS PoC: unauthenticated remote client pre-banner input to the server identification parser. This demonstrates AV:N/AC:L/PR:N/UI:N.

#[tokio::test]
async fn poc_server_accepts_client_pre_banner_before_ssh_id() {
    use russh::server;
    use tokio::io::{AsyncReadExt, AsyncWriteExt};

    let config = std::sync::Arc::new(server::Config::default());
    let (mut client, server_stream) = tokio::io::duplex(4096);

    let server = tokio::spawn(async move {
        server::run_stream(config, server_stream, NoAuthHandler).await
    });

    let mut server_id = Vec::new();
    client.read_until(b'\n', &mut server_id).await.unwrap();

    client
        .write_all(b"attacker-controlled pre-banner\r\nSSH-2.0-poc\r\n")
        .await
        .unwrap();

    let result = tokio::time::timeout(std::time::Duration::from_millis(250), server).await;

    assert!(
        result.is_err(),
        "vulnerable code keeps processing after accepting a client pre-banner before SSH identification"
    );
}

On vulnerable code, the server-side reader accepts the client pre-banner line and continues instead of rejecting the malformed identification input promptly. The fixed parser rejects client pre-banner lines on the server path.

Impact

Suggested CVSS v3.1:

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

Reasoning:

AV:N: reachable over the SSH transport connection
AC:L: no special race or unusual setup is required
PR:N, UI:N: occurs before authentication and needs no user interaction
C:N, I:N: no confidentiality or integrity impact demonstrated
A:L: malformed identification input can consume connection setup resources until rejected by timeout or external limits

Additional impact investigation did not identify a stronger confidentiality, integrity, downgrade, or code-execution primitive. The accepted client pre-banner line is discarded before key exchange and does not become part of remote_sshid; the final client identification string is what feeds the key-exchange transcript. remote_sshid is otherwise exposed to library handlers and debug formatting, but the discarded pre-banner text does not influence authentication state, strict-kex negotiation, KEX algorithm selection, or later packet framing.

One parser-boundary nuance on vulnerable code is that behavior can depend on read chunking: if a client pre-banner line and the real SSH identification line are delivered in the same read, the old parser can discard the buffered identification line and then wait or disconnect; if delivered separately, the old server path can accept the pre-banner and continue. This supports malformed pre-authentication availability impact, but not a demonstrated confidentiality or integrity impact.

Fix / Patch Direction

Use a stricter server-side client-identification reader, enforce the RFC identification-line length, and cap preliminary banner lines. The server path should reject client pre-banner lines instead of treating them like allowed server pre-identification text.

Severity

CVSS Score: 5.3 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

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

CVE-2026-48110 / GHSA-4r3c-5hpg-58qr

More information

Details

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 USERAUTH_FAILURE method lists
client USERAUTH_BANNER text fields
client USERAUTH_PK_OK fields
client EXT_INFO extension fields
server SERVICE_REQUEST names
server USERAUTH_REQUEST 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 ssh_encoding::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 take_str, take_bytes, and take_name_list.

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 SSH_MSG_KEXINIT 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: kex_input_kexinit() / kex_buf2prop()
openssh-portable: auth2.c: USERAUTH_REQUEST 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: sshpkt_get_cstring(), sshpkt_get_string(), sshpkt_get_end()

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 SSH_MSG_KEXINIT 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:

threads=512
iterations_per_thread=8
total_iterations=4096
payload_bytes=262103
errors=0
elapsed_ms=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 SSH_MSG_KEXINIT 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:

threads=512
iterations_per_thread=2
total_iterations=1024
decompressed_payload_bytes=600103
compressed_payload_bytes=652
errors=0
elapsed_ms=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:

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.

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

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

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

    fn no_crypto_preferred() -> 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 encode_string(buf: &mut Vec<u8>, value: &[u8]) {
        let mut len = [0; 4];
        BigEndian::write_u32(&mut len, value.len() as u32);
        buf.extend_from_slice(&len);
        buf.extend_from_slice(value);
    }

    fn kexinit_with_kex_list(kex_list: &str) -> Vec<u8> {
        let mut payload = Vec::new();
        payload.push(msg::KEXINIT);
        payload.extend_from_slice(&[0; 16]);
        encode_string(&mut payload, kex_list.as_bytes());
        encode_string(&mut payload, b"ssh-ed25519");
        encode_string(&mut payload, b"none");
        encode_string(&mut payload, b"none");
        encode_string(&mut payload, b"none");
        encode_string(&mut payload, b"none");
        encode_string(&mut payload, b"none");
        encode_string(&mut payload, b"none");
        encode_string(&mut payload, b"");
        encode_string(&mut payload, b"");
        payload.push(0);
        payload.extend_from_slice(&[0; 4]);
        payload
    }

    fn memory_status() -> (Option<usize>, Option<usize>) {
        let Ok(status) = std::fs::read_to_string("/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.strip_prefix("VmRSS:") {
                rss = value
                    .split_whitespace()
                    .next()
                    .and_then(|value| value.parse().ok());
            } else if let Some(value) = line.strip_prefix("VmHWM:") {
                hwm = value
                    .split_whitespace()
                    .next()
                    .and_then(|value| valu

> ✂ **Note**
> 
> PR body was truncated to here.

Update Rust crate russh to 0.61 [SECURITY]

fa1f6a3

vsilent merged commit 2b8e149 into main Jul 2, 2026
13 checks passed

renovate Bot deleted the renovate/crate-russh-vulnerability branch July 2, 2026 11:20

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Update Rust crate russh to 0.61 [SECURITY]#191

Update Rust crate russh to 0.61 [SECURITY]#191
vsilent merged 1 commit into
mainfrom
renovate/crate-russh-vulnerability

renovate Bot commented Jul 1, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

renovate Bot commented Jul 1, 2026

russh has pre-auth DoS via unbounded allocation in its keyboard-interactive auth handler

Details

Summary

Vulnerability Details

Attack Flow

Affected Configurations

Confirmed End-to-End PoC

Proposed Fix

Severity

Severity

References

Russh: Unchecked CryptoVec allocation and growth handling is reachable

Details

Title

Summary

Details

PoC

Impact

Severity

References

russh: Post-decompression SSH packet size was not bounded, allowing remote oversized compressed packets

Details

Summary

Details

RFC / OpenSSH Comparison

PoC

Impact

Fix / Patch Direction

Severity

References

russh server userauth state is not reset when authentication principal changes

Details

Summary

Details

PoC

Impact

Fix / Patch Direction

Severity

References

Russh: Unchecked keyboard-interactive prompt count in client auth path

Details

Summary

Details

PoC

Impact

Severity

References

Russh: SSH identification parsing accepted non-canonical client banners and did not bound pre-banner input

Details

Summary

Details

RFC / OpenSSH Comparison

PoC

Impact

Fix / Patch Direction

Severity

References

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

Details

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

Summary

Affected Versions

Details

RFC / OpenSSH Comparison

PoC

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant