russh try_sign: asynchronous confirmation can sign after agent lock
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | ||||||
|---|---|---|---|---|---|---|---|---|---|
| Eugeny | russh | affected |
|
No data.
No data.
No data available yet.
| Source | ID | Title |
|---|---|---|
Github GHSA |
GHSA-736f-c93q-9fwx | russh try_sign: asynchronous confirmation can sign after agent lock |
No CVSS v4.0
No CVSS v3.0
No CVSS v2
This CVE is not in the KEV list.
No EPSS score available.
Key SSVC decision points have not yet been added.
| Type | Values Removed | Values Added |
|---|---|---|
| Description | russh is a Rust SSH client and server library that includes an SSH agent protocol implementation. Prior to version 0.65.1, try_sign() captures an Arc<PrivateKey> before awaiting Agent::confirm() and does not revalidate the shared lock state or key presence after the await. This is a distinct residual defect in the remediation for CVE-2026-116794. A peer, including a remote SSH server using agent forwarding, can begin a confirmation-constrained signature request while the agent is unlocked and receive the signature after another connection locks the agent if the stale confirmation returns true. New post-lock requests are rejected and private key material is not disclosed, but the pending operation bypasses the current lock state. This issue is fixed in version 0.65.1. | |
| Title | russh try_sign: asynchronous confirmation can sign after agent lock | |
| Weaknesses | CWE-367 CWE-863 |
|
| References |
| |
| Metrics |
cvssV3_1
|
No data.