RUSTSEC-2026-0495

See a problem?
Please try reporting it to the source first.

Source

https://rustsec.org/advisories/RUSTSEC-2026-0495

Import Source

https://github.com/rustsec/advisory-db/blob/osv/crates/RUSTSEC-2026-0495.json

JSON Data

https://api.osv.dev/v1/vulns/RUSTSEC-2026-0495

Aliases

Published

2026-10-30T12:00:00Z

Modified

2026-11-12T08:00:04Z

Summary

Agent server signs with confirm-constrained keys without calling `Agent::confirm`

Details

A key added to an SSH agent with the confirm constraint (what ssh-add -c sends) must not be used to sign until the user approves each use. russh's agent server (russh::keys::agent::server) accepted the constraint, but when a sign request arrived for such a key it used a fixed true in place of the result of Agent::confirm, so the application's confirmation step never ran. This started in 0.50.0-beta.12; 0.50.0-beta.8 to beta.11 still called confirm, and earlier russh releases have no agent server.

Any process that can reach the agent, including a remote host when the agent is forwarded, can then sign with the protected key without the user's approval, for example to log in elsewhere as the user. The private key itself is not disclosed. Agents whose Agent::confirm keeps the default, which always returns true, behave the same before and after the fix.

From 0.65.0 the agent server calls Agent::confirm for confirm-constrained keys and refuses to sign when it returns false. Implementations that left confirm unimplemented (for example as todo!()) will now reach that code.

Database specific

{
    "license": "CC0-1.0"
}

References

Affected packages

crates.io / russh

Package

Name: russh; View open source insights on deps.dev
Purl: pkg:cargo/russh

Affected ranges

Type: SEMVER
Events: Introduced

0.50.0-beta.12

Fixed

0.65.0

Ecosystem specific

{
    "affected_functions": null,
    "affects": {
        "arch": [],
        "functions": [],
        "os": []
    }
}