KEVWire

Security intelligence, with context.

Response snapshot Oct 31, 2026, 01:26 UTC

Back to the wire
Permalink
VulnerabilityCVE-2026-116696

russh's SSH agent server is susceptible to unbound allocations via repeated SSH_AGENT_CONSTRAIN_CONFIRM messages

All evidence, reproduction steps, and scripts in the report were verified against a real running instance. Nothing is fabricated or synthetic; every verdict is backed by captured output from an actual deployment.

Published Updated

At a glance

Exploited
Not known
Severity
3.3 Low (CVSS 3.1)
Chance of exploitation
Not estimated
Sources
1 source

What to do

GitHub lists first patched versions: russh: 0.65.0. Confirm the affected range and upgrade guidance in the exact advisory.

Read GitHub-reviewed advisory GHSA-9wfm-jcj8-jfv9 (opens a new tab)

What happened

Summary

All evidence, reproduction steps, and scripts in the report were verified against a real running instance. Nothing is fabricated or synthetic; every verdict is backed by captured output from an actual deployment.

The SSH agent server that ships with russh (russh::keys::agent::server::serve) parses client key-addition requests and, for each SSH_AGENT_CONSTRAIN_CONFIRM (0x02) record it finds, pushes one Constraint::Confirm value into a per-key vector inside an unbounded loop, then stores the resulting pair permanently in its keystore (russh/src/keys/agent/server.rs:296-303).

Neither the constraint vector nor the keystore has a size or count limit: the only boundary is the 256 KiB agent frame cap, and every 1-byte record a client sends becomes a 56-byte enum retained for the life of the process.

Continue reading

Any process that can connect to the agent socket - the same trust model the project itself established when fixing a prior advisory about this same request handler - can therefore grow the agent's memory without bound and renew the growth at will: six 256 KiB requests retained 72.4 MiB (about 12.

1 MiB per request, a roughly 48-fold amplification) while an equal number of unconstrained key additions retained nothing, measured against the unmodified server through its public API on v0.64.1.

The earlier fix for that prior advisory deduplicates only the sibling SSH_AGENT_CONSTRAIN_LIFETIME (0x01) record type and leaves this parallel variant untouched, and since constrained keys never expire the retained memory is never reclaimed.

Details

When a client adds a key with constraints, the server walks the constraint section byte by byte and collects typed values with no upper bound on how many it will accept:

russh/src/keys/agent/server.rs:296-297 (v0.64.1 = main = e5d80a07dc554480b6ea3b2e14adfc190407b627)
 } else if t == msg::CONSTRAIN_CONFIRM {
 c.push(Constraint::Confirm) // inside the record loop, no length cap
russh/src/keys/agent/server.rs:303-308
 - the (key, timestamp, constraints) triple is inserted into the keystore,
 and keys without a LIFETIME constraint never expire

The Constraint enum is aligned to its largest variant, so each 1-byte 0x02 record on the wire costs 56 bytes of retained heap, and the frame cap of 256 KiB (server.rs:23,109) is the only thing shaping a single request - the number of requests, and the number of keys in the keystore, are unbounded. The project's fix for its prior agent advisory (commit 4c30503, shipped in 0.64.

1) addressed the SSH_AGENT_CONSTRAIN_LIFETIME record by deduplicating lifetime entries and collapsing the per-record timer tasks; the CONSTRAIN_CONFIRM branch in the very same loop was left as-is, so the fixed release still accepts and retains arbitrary amounts of confirm records per key.

The privilege model is the one the project used for the prior advisory: any local process able to connect to the agent's listening socket, which in agent-forwarding scenarios includes processes on the remote side of a forwarded session. Both file references are identical on the latest tag v0.64.

1 and on main (same commit e5d80a07dc554480b6ea3b2e14adfc190407b627), and the confirm-record handling predates the fork that merged the keys crate, so all released versions are affected.

Proof of concept

The instance is the unmodified russh v0.64.1 agent server started through its public russh::keys::agent::server::serve API inside the PoC process, with the attacker leg and the control leg connecting over an in-process duplex socket exactly as a foreign local client would; the agent handler runs with default configuration and no test hooks.

The harness measures live heap with a counting global allocator, generates a fresh Ed25519 key per request, and speaks the real agent framing (4-byte length prefix) with the server's own 256 KiB frame cap. Set the project up with the commands below (the retained run referenced the russh source checked out at tag v0.64.

1 via a path dependency and built with the GNU toolchain because the machine lacks MSVC's linker; the crates.io russh@0.64.1 release is the same source and any stable toolchain works; on Windows the built binary carries an .exe extension). The full src/main.rs follows.

cargo new poc_agent_confirm_growth
cd poc_agent_confirm_growth
cargo add russh@0.64.1 tokio --features tokio/full futures@0.3 rand@0.10
cat > src/main.rs `c.push(Constraint::Confirm)` inside an unbounded loop, with
//! no cap on the resulting per-key constraint vector and no cap on the number
//! of keys in the keystore.
//!
//! Relationship to GHSA-4wc5-f2rc-q74m (fixed in 0.64.1): that advisory covered
//! the SSH_AGENT_CONSTRAIN_LIFETIME (0x01) record, whose fix (commit 4c30503)
//! deduplicates lifetime records only. The parallel CONFIRM record variant is
//! not covered: each 1-byte 0x02 record retains one 56-byte Constraint enum in
//! the persistent keystore (>=50x amplification, never expires, renewable).
//!
//! Attack model (same as GHSA-4wc5): any local process able to connect to the
//! agent's listening socket. No authentication on the socket by default.
//!
//! The attacker here only uses the socket (tokio duplex); the agent server
//! runs unmodified via the public `russh::keys::agent::server::serve` API.

use std::alloc::{GlobalAlloc, Layout, System};
use std::sync::atomic::{AtomicU64, Ordering};

use futures::stream::once;
use tokio::io::{AsyncReadExt, AsyncWriteExt, DuplexStream};

static LIVE: AtomicU64 = AtomicU64::new(0);

struct Counting;

unsafe impl GlobalAlloc for Counting {
 unsafe fn alloc(&self, layout: Layout) -> *mut u8 {
 let p = System.alloc(layout);
 if !p.is_null() {
 LIVE.fetch_add(layout.size() as u64, Ordering::SeqCst);
 }
 p
 }
 unsafe fn dealloc(&self, p: *mut u8, layout: Layout) {
 LIVE.fetch_sub(layout.size() as u64, Ordering::SeqCst);
 System.dealloc(p, layout)
 }
}

#[global_allocator]
static A: Counting = Counting;

fn live_mb() -> f64 {

Affected package ranges reported by GitHub:
russh: < 0.65.0

Scores and how they were measured

CVSS base severity

3.3

Version 3.1As of

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

Measurement source (opens a new tab)

How bad it is if exploited. Not a prediction of exploitation or proof you are exposed.

EPSS probability

Not available

A model's estimate of exploitation in the next 30 days, not certainty or your own risk.

Related technology

Follow Rust crates: RSS feedAll its recordsAsk your AI assistant

Sources

  1. Primary source

    GitHub-reviewed advisory GHSA-9wfm-jcj8-jfv9 (opens a new tab)

    The public advisory supplies the description, affected package/version ranges, and any listed CVSS metric. GitHub review is not local review.

    Published Checked

  2. Primary source

    GitHub public advisory API page (opens a new tab)

    The API page supplied GHSA-9wfm-jcj8-jfv9, its actual identifiers, source dates, and structured metrics.

    Published Date not suppliedChecked

Cite this record

For factual claims, cite the primary sources above; cite KEVWire for its compilation, dates, and classifications.

APA

KEVWire. (2026, October 30). russh's SSH agent server is susceptible to unbound allocations via repeated SSH_AGENT_CONSTRAIN_CONFIRM messages (CVE-2026-116696). https://kevwire.com/record/CVE-2026-116696

MLA

"russh's SSH agent server is susceptible to unbound allocations via repeated SSH_AGENT_CONSTRAIN_CONFIRM messages (CVE-2026-116696)." KEVWire, 30 Oct. 2026, kevwire.com/record/CVE-2026-116696.

Chicago

KEVWire. "russh's SSH agent server is susceptible to unbound allocations via repeated SSH_AGENT_CONSTRAIN_CONFIRM messages (CVE-2026-116696)." Last modified October 30, 2026. https://kevwire.com/record/CVE-2026-116696.

Evidence summary (plain text)

russh's SSH agent server is susceptible to unbound allocations via repeated SSH_AGENT_CONSTRAIN_CONFIRM messages (Oct 30, 2026).
All evidence, reproduction steps, and scripts in the report were verified against a real running instance. Nothing is fabricated or synthetic; every verdict is backed by captured output from an actual deployment.

The SSH agent server that ships with russh (russh::keys::agent::server::serve) parses client key-addition requests and, for each SSH_AGENT_CONSTRAIN_CONFIRM (0x02) record it finds, pushes one Constraint::Confirm value into a per-key vector inside an unbounded loop, then stores the resulting pair permanently in its keystore (russh/src/keys/agent/server.rs:296-303).
CVSS 3.3 (version 3.1; evidence as of Oct 30, 2026; https://github.com/advisories/GHSA-9wfm-jcj8-jfv9).
Sources:
GitHub-reviewed advisory GHSA-9wfm-jcj8-jfv9: https://github.com/advisories/GHSA-9wfm-jcj8-jfv9
GitHub public advisory API page: https://api.github.com/advisories?type=reviewed&per_page=100&sort=updated&direction=desc
Record ID: CVE-2026-116696.
Record origin: Ingested record.
AI evidence: Not assessed.
Known exploitation: Not assessed.
Zero-day status: Not assessed. KEV membership alone does not establish zero-day status.
About this data

This record was ingested from a data source. Retrieved: Oct 31, 2026, 00:50 UTC. Ingestion is not an independent editorial investigation.

A CISA KEV listing documents known exploitation, not necessarily a zero-day; absence from the catalog does not prove a vulnerability has never been exploited.

Technology tags indicate possible relevance, not verified exposure. Confirm the affected product, version, and configuration against your own inventory; KEVWire does not scan your systems.

A personal reading checklist on this device, not verified remediation.

Record JSON

Your account

Email alerts

Email alerts are coming as part of KEVWire Premium: join the waitlist. To follow your stack today, use its RSS feed, which honors your filters, or connect an AI agent through the API.

Suggest an improvement

Ideas, missing sources, corrections, and bugs are all welcome. No account needed. Suggestions are reviewed by a person before anything changes.

Record details

Record detail