fix(deps): update rust crate russh to v0.61.1 [security]

[renovate]

This PR contains the following updates:

Package	Type	Update	Change
russh	dependencies	minor	=0.60.3 → =0.61.1

---

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:

1. An attacker-crafted best-compressed DEBUG payload can stay below the normal 256 KiB transport packet cap while still inflating beyond 128 MiB.
2. In the direct client and server receive paths, small compressed DEBUG packets are still ignored normally after parsing.
3. 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

• https://github.com/Eugeny/russh/security/advisories/GHSA-wwx6-x28x-8259
• https://github.com/advisories/GHSA-wwx6-x28x-8259

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

• https://github.com/Eugeny/russh/security/advisories/GHSA-hpv4-5h6f-wqr3
• https://github.com/advisories/GHSA-hpv4-5h6f-wqr3

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

---

Release Notes

warp-tech/russh (russh)

v0.61.1

Compare Source

Security fixes

GHSA-wwx6-x28x-8259

When compression is negotiated, an attacker can craft a "ZIP bomb" style packet that would bypass the maximum packet size checks. This could allow the attacker to hit the OOM limit and either get the server process killed by the OS, or, prior to russh@​0.58.0, aborted. A similar issue existed in the AgentClient as well, which could be triggered by a malformed SSH agent response.

Fixes

• keys/agent: forward full agent signature blob for sk-ecdsa/sk-ed25519 keys (#​701) #​701 (ztbh)
• accept empty name-list in KEXINIT (RFC 4251 §5) (#​710) #​710 (Bernardo Meurer)

v0.61.0

Compare Source

Changes

• 32fd46f: Reduce russh write-path copies with direct Bytes sends (#​695) (Mika Cohen) #​695

  • New APIs allow zero-copy writes into channels:
    • Channel::data_bytes
    • Channel::extended_data_bytes
    • ChannelWriteHalf::data_bytes
    • ChannelWriteHalf::extended_data_bytes

• deps: migrate to stable versions pkcs5 / pkcs8 / ed25519 and loosen prerelease pins (extends #​697) (#​702) #​702 (escapecode)

• 72b250a: migrate to upstream ssh-key crate and update RustCrypto crates (#​709) (Eugene) #​709

Security fixes

Part of the hardening efforts by @​mjc

GHSA-hpv4-5h6f-wqr3

• When a client changed their username between authentication requests, russh server implementation would not correctly reset its internal state (allowed methods and "partial success" state), which could lead to incorrect responses to the client.
  • Note that you still need to handle the case where the client sends a subsequent authentication request with a different username and reset any accumulated authentication state your application might have

GHSA-g9g7-5cgw-6v28

• When a client sent a keyboard-interactive authentication request, the prompt counter was used to directly allocate memory without verifying it, which can lead to denial of service.

GHSA-76r6-x97p-67vr

• russh server did not enfore the SSH protocol header validation strictly enough, allowing a client to hold the connection open indefinitely, wasting resources.

GHSA-4r3c-5hpg-58qr

• "Name list" fields such as algorithm lists were only bounded by the packet size. While the SSH protocol does not impose a limit, in practice it could allow a client to waste resources by spamming huge KEXINIT messages via multiple connections.

Fixes

• 4186cf2: Refactor block-cipher packet-length probing to avoid unsafe state duplication (#​706) (Mika Cohen) #​706
• reject trailing KEX and channel-open payloads (Mika Cohen)
• reject trailing encrypted message payloads (Mika Cohen)

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • ""
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 47.56%. Comparing base (7e848bd) to head (c599b49).
⚠️ Report is 318 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #693      +/-   ##
==========================================
+ Coverage   41.28%   47.56%   +6.28%     
==========================================
  Files          16       25       +9     
  Lines         671     2075    +1404     
==========================================
+ Hits          277      987     +710     
- Misses        394     1088     +694     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.