Most recent entries from all

EUVD-2026-326645

fkie_cve-2026-46673

Russh is a Rust SSH client & server library. Prior to version 0.60.3, 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. This issue has been patched in version 0.60.3.

GHSA-g9f8-wqj9-fjw5 — Russh: Unchecked CryptoVec allocation and growth handling is reachable

Affected: crates.io: russh-cryptovec, crates.io: russh

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

1. 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,…

RUSTSEC-2026-0153 — Unchecked `CryptoVec` allocation and growth handling

Affected: crates.io: russh-cryptovec

`CryptoVec` used unchecked capacity growth, unchecked length arithmetic, and unsafe allocation and locking paths. In affected `russh` releases, attacker-controlled input could reach these code paths through buffer resizing operations.

Two affected reachability paths were identified:

* **Current `russh` releases (`0.60.x` before the fix)** Local SSH agent peers could provide attacker-controlled frame lengths that were used to resize internal buffers before validation in:

* `AgentClient::read_response` * `agent::server::Connection::run`

* **Historical `russh` releases before `0.58.0`** `CryptoVec` was also used for non-secret transport and compression buffers, allowing remote SSH traffic to trigger `CryptoVec` growth through:

* transport packet reads * zlib decompression output

These remote paths were removed in `0.58.0` when `CryptoVec` stopped being used for those buffers.

Under constrained memory conditions, historical `russh` versions prior to `0.58.0` can abort the process when remote compressed payload expansion causes allocation failure in `CryptoVec`. This was reproduced through the compression path and resulted in process termination in the Unix allocation/locking implementation after null pointer allocation failure.

For current affected releases, oversized local SSH agent frame lengths could trigger untrusted-input-driven buffer growth prior to validation.

No practical remote code execution, integrity or confidentiality impact has been demons…