russh agent signs with protected keys without asking the user

A flaw in the Rust SSH library russh means an SSH agent built with it will sign with keys that were meant to require explicit user approval, according to a GitHub security advisory published on 30 October 2026. The issue is tracked as CVE-2026-116794 and affects every russh release from 0.50.0-beta.12 up to and including 0.64.1, which the advisory says is 52 versions.

An SSH agent holds private keys in memory and signs authentication challenges on request, so the user does not have to type a passphrase each time. The confirm constraint, sent by the ssh-add -c command and defined as SSH_AGENT_CONSTRAIN_CONFIRM in RFC 9987, tells the agent to ask the user before each use of a key. In russh's agent server, the advisory says, that check was replaced by a hard-coded true. The code still notes that the key needs confirmation, then awaits an already-resolved future instead of calling the Agent::confirm method supplied by the application.

The advisory traces the change to commit 3e04597, titled "Native async traits encore", first released in 0.50.0-beta.12. Releases 0.50.0-beta.8 through beta.11 do call agent.confirm. Earlier russh versions contained no agent server at all; it lived in the separate russh-keys crate, and the advisory says no russh-keys release is affected. The agent client, and russh's SSH client and server, are also unaffected.

The practical consequence, according to the advisory, is that any party able to talk to the agent can use a confirm-constrained key without the owner's approval. That includes other local processes running as the same user, and the remote host when the agent is forwarded with ssh -A. The private key material itself is not exposed. The advisory describes the impact as unauthorised use of the key for as long as the attacker can reach the agent, including logging in to other hosts as the user or signing data such as git commits.

The advisory also notes a second problem. Because the agent accepts the constraint without implementing it, ssh-add -c reports success and the user believes the key is protected. RFC 9987 section 5.2.7 states that an agent which does not support a constraint must refuse the key instead. The advisory quotes section 10 of the same document, which names the confirm constraint as the mechanism that stops an attacker with access to the agent from "stealing use of those keys".

Not every russh user is exposed. Applications that keep the default confirm implementation, which returns true anyway, see no change in behaviour. Checks placed in Agent::confirm_request also still run, because that method continues to be called with MessageType::Sign for every signing request.

The advisory includes a proof of concept: a test that creates an agent whose confirmation handler refuses every prompt, adds a key with the confirm constraint, and then requests a signature. On version 0.64.1 the signature succeeds and the confirmation handler is called zero times.

The advisory names one downstream user it believes is affected, based on public code and not on testing: Proton Pass desktop, which uses russh 0.62.7. According to the advisory, that application adds every key with the confirm constraint and uses Agent::confirm as its check that Pass is unlocked before signing.