<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-11-11T22:39:37.724512+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://db.gcve.eu/vuln/fkie_cve-2026-111062</id>
    <title>fkie_cve-2026-111062</title>
    <updated>2026-11-11T22:39:37.726558+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>russh is a Rust SSH client and server library. From version 0.34.0-beta.1 until version 0.64.0, its SSH server does not require the signature algorithm in a public-key authentication signature to match the algorithm named in the authentication request. A client possessing an authorized RSA private key can announce  rsa-sha2-512  while supplying a valid  ssh-rsa  SHA-1 signature, bypassing restrictions or producing misleading audit records when applications rely on the requested algorithm. A valid private-key signature remains required, and russh clients are not affected. This issue is fixed in version 0.64.0.</p>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-111062"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-j7h2-66j4-ghjf</id>
    <title>GHSA-j7h2-66j4-ghjf — A russh SSH server accepts a publickey authentication whose signature uses a different algorithm than the one named in…</title>
    <updated>2026-11-11T22:39:37.726654+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> crates.io: russh</p>
<p>### Details</p>
<p>In `russh/src/server/encrypted.rs`, `server_read_auth_request_pk` (0.63.3, around lines 880-990):</p>
<p>* The requested algorithm name (`pubkey_algo`) is read and only used to decode the key: `PublicKeyOrCertificate::decode(&amp;pubkey_algo, &amp;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(&amp;pubkey, &amp;buf, &amp;sig)`. `ssh-key` picks the hash from **the signature's own algorithm** (`sig.algorithm()`).
* `pubkey_algo` and `sig.algorithm()` are never compared.</p>
<p>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.</p>
<p>**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.</p>
<p>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.</p>
<p>* **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.</p>
<p>Confirmed by running…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-j7h2-66j4-ghjf"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ubuntu-cve-2026-111062</id>
    <title>UBUNTU-CVE-2026-111062</title>
    <updated>2026-11-11T22:39:37.726763+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Ubuntu:26.10: rust-russh</p>
<p>russh is a Rust SSH client and server library. From version 0.34.0-beta.1 until version 0.64.0, its SSH server does not require the signature algorithm in a public-key authentication signature to match the algorithm named in the authentication request. A client possessing an authorized RSA private key can announce  rsa-sha2-512  while supplying a valid  ssh-rsa SHA-1 signature, bypassing restrictions or producing misleading audit records when applications rely on the requested algorithm. A valid private-key signature remains required, and russh clients are not affected. This issue is fixed in version 0.64.0.</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ubuntu-cve-2026-111062"/>
  </entry>
</feed>
