russh: Agent server never calls `Agent::confirm`, so keys added with the confirm constraint (`ssh-add -c`) sign without confirmation
CVE-2026-116794 · GHSA-vp5q-ff62-jwqv · published 30 Oct 2026
How serious is it
- Severity: high, CVSS score 8.3 out of 10.
- No exploit prediction (EPSS) score yet.
- Not on the CISA list of exploited vulnerabilities.
- No public exploit in Exploit-DB.
Is your app affected by CVE-2026-116794?
Paste this prompt into Claude Code, Cursor or any AI coding tool: it runs a free Shippable scan of your project and fixes what it finds. Built with Lovable, Bolt or v0? Scan your live app. Or upload your package file.
Who is affected
russh(crates.io) < 0.65
How to check
- Run
cargo tree -i russhin your project to see the installed version, including copies pulled in by other packages. - Or paste your lockfile into the checker: it lists every package with a known vulnerability, this one included.
How to fix
Copies a prompt for Claude Code, Cursor or Codex: it checks your lockfiles for this and upgrades it.
- Upgrade
russhto 0.65 or later, commit the lockfile and redeploy. - If a vulnerable version was live, check your logs and rotate the secrets that server could read.
The advisory
### Summary
The agent server in `russh::keys::agent::server` never calls `Agent::confirm` before signing with a key that was added with the confirm constraint. That constraint is `SSH_AGENT_CONSTRAIN_CONFIRM` (RFC 9987 §5.2.7.2), which is what `ssh-add -c` sends.
The call was replaced by a hard-coded `true` in 3e04597 ("Native async traits encore", #455), first released in 0.50.0-beta.12. Every release since, up to and including 0.64.1, signs requests for confirm-constrained keys without asking the `Agent` implementation. A user who added a key with `-c` is therefore never asked to confirm.
### Details
`Connection::try_sign` notes that the key needs confirmation, then awaits a ready future instead of the agent ([server.rs L348-L360 at v0.64.1](https://github.com/Eugeny/russh/blob/e5d80a07dc554480b6ea3b2e14adfc190407b627/russh/src/keys/agent/server.rs#L348-L360)):
```rust
let agent = if needs_confirm {
let (agent, ok) = {
let _pk = key.clone();
Box::new(futures::future::ready((agent, true)))
}
.await;
if !ok {
return Ok((agent, false));
}
agent
} else {
agent
};
```
Before [3e04597](https://github.com/Eugeny/russh/commit/3e04597dc54e36bfc85c21996f7d8d9d224e9826) the first statement was `let (agent, ok) = agent.confirm(key.clone()).await;`.
`try_sign` was checked in the published crates on crates.io:
- Every russh release from 0.50.0-beta.12 to 0.64.1 (52 versions) has the hard-coded `true`.
- russh 0.50.0-beta.8 to beta.11 call `agent.confirm`.
- Earlier russh releases have no agent server. It lived in russh-keys, and no russh-keys release is affected.
Not affected:
- `Agent` implementations that keep the default `confirm`, which returns `true` anyway.
- Checks made in `Agent::confirm_request`, which is still called with `MessageType::Sign` for every sign request ([L158-L159](https://github.com/Eugeny/russh/blob/e5d80a07dc554480b6ea3b2e14adfc190407b627/russh/src/keys/agent/server.rs#L158-L159)).
- The agent client, and the SSH client and server.
### PoC
1. Add this test to `mod test` in `russh/src/keys/mod.rs`. It uses the module's existing `Incoming` helper and `ED25519_KEY`.
2. Run `cargo test -p russh --lib keys::test::test_agent_confirms_keys_added_with_the_confirm_constraint`.
```rust
#[tokio::test]
#[cfg(unix)]
async fn test_agent_confirms_keys_added_with_the_confirm_constraint() {
use std::sync::atomic::{AtomicUsize, Ordering};
// An agent whose user refuses every confirmation prompt.
#[derive(Clone)]
struct Refuse(std::sync::Arc<AtomicUsize>);
impl agent::server::Agent for Refuse {
fn confirm(
self,
_: std::sync::Arc<PrivateKey>,
) -> Box<dyn Future<Output = (Self, bool)> + Send + Unpin> {
self.0.fetch_add(1, Ordering::SeqCst);
Box::new(futures::future::ready((self, false)))
}
}
let prompts = std::sync::Arc::new(AtomicUsize::new(0));
let dir = tempfile::tempdir().unwrap();
let agent_path = dir.path().join("agent");
let mut listener = tokio::net::UnixListener::bind(&agent_path).unwrap();
let agent = Refuse(prompts.clone());
tokio::spawn(async move {
agent::server::serve(
Incoming {
listener: &mut listener,
},
agent,
)
.await
});
let key = decode_secret_key(ED25519_KEY, Some("blabla")).unwrap();
let public = key.public_key().clone();
let stream = tokio::net::UnixStream::connect(&agent_path).await.unwrap();
let mut client = agent::client::AgentClient::connect(stream);
// What `ssh-add -c` sends.
client
.add_identity(&key, &[agent::Constraint::Confirm])
.await
.unwrap();
let signed = client
.sign_request(&AgentIdentity::from(public), None, b"data".to_vec())
.await;
let confirm_calls = prompts.load(Ordering::SeqCst);
assert!(
signed.is_err(),
"the agent signed with a confirm-constrained key without asking: \
Agent::confirm was called {confirm_calls} time(s)"
);
assert_eq!(
confirm_calls, 1,
"Agent::confirm should be asked exactly once"
);
}
```
On v0.64.1 (e5d80a0) the test fails:
```
the agent signed with a confirm-constrained key without asking: Agent::confirm was called 0 time(s)
```
With the fix below it passes, and so do all 46 `keys::` tests.
### Impact
A russh-based agent whose `Agent::confirm` asks the user, or applies any other check, signs every request for a confirm-constrained key without running that check. Anyone who can talk to the agent can then use the key without the user's approval:
- other local processes of the user;
- the remote host, when the agent is forwarded (`ssh -A`).
Preventing exactly this is the purpose of the confirm constraint. RFC 9987 §10 names it as what stops an attacker with access to the agent from "stealing use of those keys".
Because the agent accepts the constraint, `ssh-add -c` reports success and the user believes the key is protected. RFC 9987 §5.2.7 says an agent that does not support a constraint MUST refuse the key instead.
The private key itself is not exposed. The impact is unauthorized use of it for as long as the attacker can reach the agent: logging in to other hosts as the user, or signing data such as git commits.
**Known affected downstream user** (from its public code; not tested): Proton Pass desktop, which uses russh 0.62.7.
- It adds every key with `Constraint::Confirm` ([mod.rs L332](https://github.com/ProtonMail/WebClients/blob/64862561fea883c1b4360b7338a0102eaad5c0fb/applications/pass-desktop/native/napi/src/ssh_agent/mod.rs#L332)).
- It uses `Agent::confirm` as its "Pass is unlocked" check before signing, and defers `MessageType::Sign` from `confirm_request` to it ([L75-L100](https://github.com/ProtonMail/WebClients/blob/64862561fea883c1b4360b7338a0102eaad5c0fb/applications/pass-desktop/native/napi/src/ssh_agent/mod.rs#L75-L1…
Check your whole app
Dependencies are only half of it. Free and read-only: before you push, run npx shippable-dev scan localhost:3000 in your project folder, no account needed. For your live app, you prove it's yours with a one-line tag first.
References
- github.com/Eugeny/russh/security/advisories/GHSA-vp5q-ff62-jwqv
- nvd.nist.gov/vuln/detail/CVE-2026-116794
- github.com/Eugeny/russh/commit/3e04597dc54e36bfc85c21996f7d8d9d224e9826
- github.com/Eugeny/russh/commit/62db6e7defd6d244159da962ccccb029e785ce0f
- github.com/Eugeny/russh/releases/tag/v0.65.0
- github.com/advisories/GHSA-vp5q-ff62-jwqv
- github.com/Eugeny/russh
Merged from GitHub Advisory Database, OSV. Last updated 31 Oct 2026. All vulnerabilities · RSS · JSON