CVE-2026-116794 in russh
Summary
by MITRE • 10/28/2026
russh is a Rust SSH client and server library that includes an SSH agent protocol implementation. From 0.50.0-beta.12 until 0.65.0, the agent server's Connection::try_sign path in russh/src/keys/agent/server.rs recognizes SSH_AGENT_CONSTRAIN_CONFIRM but returns a hard-coded successful result instead of calling Agent::confirm. In applications that override Agent::confirm to require user approval or another policy check, a process that can reach the agent socket, including the remote side of a forwarded agent, can use a key added through ssh-add -c without that check and can authenticate or sign data as the user while the key remains loaded. The separate Agent::confirm_request hook still runs for every signing request, so checks implemented there remain effective, and implementations that retain the default always-successful Agent::confirm do not lose an approval check through this regression. This issue is fixed in version 0.65.0.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/28/2026
The russh library, a Rust-based implementation of SSH client and server protocols including support for the SSH agent protocol, contained a significant logic error within its agent server component that undermined security controls designed to enforce user interaction during cryptographic operations. Specifically, in versions ranging from 0.50.0-beta.12 through 0.65.0, the Connection::try_sign path failed to properly handle the SSH_AGENT_CONSTRAIN_CONFIRM constraint flag. When a client requested signing with this constraint set, indicating that explicit confirmation was required before proceeding, the server incorrectly returned a hard-coded success response rather than invoking the Agent::confirm method. This deviation from the standard protocol behavior effectively bypassed any custom policy checks or user approval mechanisms implemented by overriding the confirm function in applications utilizing russh as their underlying agent infrastructure.
This vulnerability represents a classic case of improper input validation leading to authorization bypass, where the presence of a security constraint is acknowledged but not enforced. The operational impact allows any process with access to the SSH agent socket, including those connected via remote port forwarding, to sign data or authenticate using keys that were added with the confirm flag enabled. For instance, if an administrator adds a key using ssh-add -c, expecting interactive approval for each signing operation, this flaw permits automated scripts or malicious processes on compromised hosts to perform these operations silently without user intervention. This undermines the primary security benefit of constrained SSH agents, which is to prevent unauthorized use of private keys even when they are loaded in memory and accessible via socket IPC mechanisms.
From a classification perspective, this issue aligns with CWE-287, Improper Authentication, as it allows an actor to bypass authentication controls by exploiting a failure in the enforcement logic rather than breaking cryptographic primitives directly. It also relates to CWE-693, Protection Mechanism Failure, because the security mechanism intended to protect the private key usage was rendered ineffective due to incorrect implementation of protocol constraints. In terms of adversary tactics, this flaw facilitates lateral movement and privilege escalation within environments where SSH agent forwarding is employed, as attackers can leverage forwarded agents to sign certificates or authenticate to other systems without triggering user alerts associated with interactive confirmation prompts.
The vulnerability highlights the critical importance of correctly implementing all aspects of cryptographic protocols, particularly those involving human-in-the-loop security controls like confirmations. While the separate Agent::confirm_request hook remained functional and effective for checks implemented there, relying on this distinction creates a fragile security posture where different code paths have inconsistent behavior regarding user consent. The regression occurred because the specific path handling constrained signing requests did not delegate to the standard confirmation workflow, creating an inconsistency that attackers could exploit. This issue was resolved in version 0.65.0 by ensuring that the SSH_AGENT_CONSTRAIN_CONFIRM flag correctly triggers the necessary approval checks before allowing signature generation.
To mitigate this risk and prevent similar issues in future implementations, developers must ensure that all protocol constraints are fully respected within every code path involved in cryptographic operations. It is essential to verify that custom overrides of agent methods do not inadvertently bypass standard security flows defined by the SSH specification. Organizations relying on russh or similar libraries should upgrade immediately to version 0.65.0 or later where this logic error has been corrected. Additionally, defense-in-depth strategies such as restricting socket access permissions and monitoring for unusual signing patterns can provide additional layers of protection against exploitation of agent-related vulnerabilities in distributed environments.