russh EUVD-2026-112267

Exploitation requires ALL of the following concrete prerequisites: (1) the application embeds russh in the affected range 0.50.0-beta.12 to 0.64.1 and acts as an SSH agent server via russh::keys::agent::server; (2) the application OVERRIDES Agent::confirm to implement a real approval or policy check - the default always-true implementation is NOT affected, and checks placed in Agent::confirm_request are NOT bypassed because that hook still runs for every sign request; (3) a key was loaded with the SSH_AGENT_CONSTRAIN_CONFIRM constraint, i.e. via 'ssh-add -c', and remains loaded; and (4) the attacker can reach the agent socket, meaning either another local process running as the same user or the remote host when the agent is forwarded with 'ssh -A'. Limiting factors: the private key is never exposed (abuse lasts only while the attacker can reach the agent), and unaffected configurations (default confirm, confirm_request-based checks, non-forwarded agents with no hostile local processes) remove the risk entirely.

This is a genuine but conditional authorization-bypass (CWE-862) in russh's SSH agent server, not an inflated high-CVSS issue - though its real-world blast radius is narrower than the 8.3 score alone suggests. The supplied CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:L/UI:N) correctly reflects that exploitation requires reaching the agent's local Unix socket (or the remote end of a forwarded agent), low privileges, no user interaction and no special attack conditions, with high integrity impact on both the vulnerable system (VI:H) and subsequent systems (SI:H/SC:H) because the agent can be driven to authenticate or sign as the user. No EPSS probability and no CISA KEV status were provided in the input, so there is no signal of active or widespread exploitation; the vuln.today decision label is 'this_week' (not act_now/emergency). The GHSA advisory ships a working reproducer test demonstrating the regression, so a public PoC reference exists; it is not verified in the input as a packaged weaponized exploit, and PoC availability must not be conflated with active exploitation. The crucial limiting signal, stated explicitly by the vendor, is that only applications that OVERRIDE Agent::confirm to enforce an approval/policy check are affected - implementations keeping the default always-true confirm, and any checks placed in Agent::confirm_request (still invoked for every sign request), are unaffected. Net: a real priority for the specific downstream applications that rely on ssh-add -c confirmation (e.g. the reporter names Proton Pass desktop, untested), but low urgency for the general russh population.

A user runs a russh-based agent application that overrides Agent::confirm to prompt for approval, and loads a key with 'ssh-add -c' expecting per-use confirmation. An attacker who can reach the agent socket - another local process running as that user, or the remote host when the agent is forwarded with 'ssh -A' - issues a signature request for that key; the agent returns a hard-coded success and signs without the confirmation prompt ever firing, letting the attacker authenticate to other hosts or sign data (e.g. git commits) as the user while the key stays loaded. The GHSA advisory includes a reproducer test confirming the confirm callback is never invoked.