Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🦀
🦀 crates.io
Not in CISA KEV
MEDIUM severity

CVE-2026-111061 — russh

MEDIUMFix: Eugeny/russh@4c30503

CVE-2026-111061 is a medium-severity (CVSS 4.3) CWE-770 vulnerability in russh. A fix is available for russh — see the affected versions and patch details below.

russh agent server converts constraint records into unbounded never-rolled-back tasks

Also known asGHSA-4wc5-f2rc-q74m
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 22, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-111061.

EPSS Exploitation Probability

via FIRST.org ↗
0.3%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs27th percentile — riskier than 27% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

CVE-2026-111061 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 394,415 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

1 pkg affected
🦀russh

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.

Description

Summary

russh_keys::agent::server::add_key (russh/src/keys/agent/server.rs:271-319) spawns a dedicated tokio task for every 5-byte SSH_AGENT_CONSTRAIN_LIFETIME record attached to an added key, each cloning the key blob and sleeping for the declared lifetime (up to ~136 years). The loop has no per-request task budget, and spawned tasks are not rolled back when the overall request fails. Repeating one constrained add-key message over an agent connection converts wire bytes into resident tasks and heap at roughly 141x amplification: in our measurement 10.2 MiB of protocol traffic produced ~2,096,120 live tasks and +1,447,856 KiB RSS, while the same traffic sent as unconstrained add-key requests cost +268 KiB. An attacker reaching the agent socket (a local process, or a remote SSH server the user connects to with agent forwarding, since russh clients accept the [email protected] channel by default at russh/src/client/mod.rs:2686) can exhaust the agent process's memory and task capacity with a renewable, cheap request stream. Verified on russh HEAD efa9a03 (v0.63.3-10, 2026-10-01).

Details

// russh/src/keys/agent/server.rs:271-319 (add_key, constraint loop)
while let Ok(t) = u8::decode(r) {
 match t {
 SSH_AGENT_CONSTRAIN_LIFETIME => {
 let lifetime = u32::decode(r)?;
 ...
 tokio::spawn({
 let key = key.clone;
 async move { tokio::time::sleep(...lifetime...).await; /* remove key */ }
 });
 }
 ...

Each lifetime record clones the key blob into a new task regardless of how many records the same request already spawned, and a failure later in the request leaves earlier tasks alive. Data flow: agent connection -> SSH_AGENTC_ADD_IDENTITY_CONSTRAINED -> constraint decode loop -> unbounded tokio::spawn per 5 bytes. The control measurement (identical wire volume as unconstrained adds) isolates the constraint path as the amplifier.

Proof of concept

Prerequisites: Linux host with cargo and git. The archive's deploy script provisions russh at the pinned revision and the PoC crate (rewriting the path dependency); the PoC runs a real russh agent server on loopback and speaks the agent protocol to it.

$ POC_HOME=$HOME/russh-poc RUSSH_REPO=/home/ubuntu/HuntTargets/russh ./deployment/deploy.sh
russh at efa9a03 -> /home/ubuntu/russh-poc/poc

$ POC_HOME=$HOME/russh-poc ./poc/poc.sh 40
[*] round 29: reply code=6 RSS=1090272 KiB (delta +1087580 KiB)
[*] round 39: reply code=6 RSS=1450548 KiB (delta +1447856 KiB)
[*] final RSS = 1450548 KiB (delta +1447856 KiB, x141 amplification by wire bytes)
[*] ~2096120 tasks now sleep for ~136 years holding their blob + timer.
[*] fds = 19

The broker acks every request (code 6 = SUCCESS) while RSS grows to +1.45 GB from ~10 MiB of input. The harness's control mode (same wire volume, unconstrained adds) measured +268 KiB. The automated archive run reproduces exactly this trace.

Manual reproduction, step by step (no archive required)

  1. Provision russh at the pinned revision and build the PoC crate (it hosts a real russh agent server in-process):
git clone https://github.com/Eugeny/russh && cd russh && git checkout efa9a03e541b69505d5e6ec0d9213d011c9f6310
cargo build --release   # in the PoC crate directory; the path dependency points at the clone
  1. Run the PoC: it starts the agent on loopback, then sends repeated SSH_AGENTC_ADD_IDENTITY_CONSTRAINED messages whose constraint sections contain ~52,000 five-byte SSH_AGENT_CONSTRAIN_LIFETIME records each:
./target/release/poc-agent-addkey 40
# [*] round 29: reply code=6 RSS=1090272 KiB (delta +1087580 KiB)
# [*] round 39: reply code=6 RSS=1450548 KiB (delta +1447856 KiB)
# [*] final RSS = 1450548 KiB (delta +1447856 KiB, x141 amplification by wire bytes)
# [*] ~2096120 tasks now sleep for ~136 years holding their blob + timer.
  1. Control: the same wire volume sent as UNCONSTRAINED add-key requests measures +268 KiB (MODE=control), isolating the constraint-record task spawn as the amplifier.

  2. Reachability: any local process with access to the agent socket, or a remote SSH server the user connects to with agent forwarding (russh clients accept [email protected] channels by default, russh/src/client/mod.rs:2686), can drive this. Each spawned task clones the key blob and sleeps for the declared lifetime (up to ~136 years); tasks are never rolled back when a request fails.

Impact

An attacker able to speak the agent protocol to a russh-based agent (local process on the socket, or a remote SSH server the user connects to with agent forwarding enabled) can drive gigabyte-scale memory growth and millions of leaked tasks per session with megabytes of traffic, renewable until the agent process is starved or OOM-killed, taking the user's SSH key agent down. The trust boundary is the agent protocol peer versus the agent process's resources. No confidentiality or integrity impact.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🦀crates.iorusshall versions0.64.1cargo update -p russh --precise 0.64.1

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for russh, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update russh to 0.64.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-111061 is resolved across your whole dependency graph.

  3. Workarounds

    Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.

Frequently Asked Questions

### Summary `russh_keys::agent::server::add_key` (`russh/src/keys/agent/server.rs:271-319`) spawns a dedicated tokio task for every 5-byte `SSH_AGENT_CONSTRAIN_LIFETIME` record attached to an added key, each cloning the key blob and sleeping for the declared lifetime (up to ~136 years). The loop has no per-request task budget, and spawned tasks are not rolled back when the overall request fails. Repeating one constrained add-key message over an agent connection converts wire bytes into resident tasks and heap at roughly 141x amplification: in our measurement 10.2 MiB of protocol traffic produ
O3 Security · Impact-Aware SCA

Is CVE-2026-111061 in your dependencies?

Find it across crates.io, including transitive dependencies.

CVE-2026-111061: russh — Fixed in 0.64.1