<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://db.gcve.eu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Wed, 11 Nov 2026 22:39:37 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-111062</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-111062</link>
      <description>&lt;p&gt;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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-111062</guid>
    </item>
    <item>
      <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>
      <link>https://db.gcve.eu/vuln/ghsa-j7h2-66j4-ghjf</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; crates.io: russh&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;In `russh/src/server/encrypted.rs`, `server_read_auth_request_pk` (0.63.3, around lines 880-990):&lt;/p&gt;
&lt;p&gt;* The requested algorithm name (`pubkey_algo`) is read and only used to decode the key: `PublicKeyOrCertificate::decode(&amp;amp;pubkey_algo, &amp;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;amp;pubkey, &amp;amp;buf, &amp;amp;sig)`. `ssh-key` picks the hash from **the signature&amp;#39;s own algorithm** (`sig.algorithm()`).
* `pubkey_algo` and `sig.algorithm()` are never compared.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;**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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;* **Up to 0.46:** after reading the algorithm name inside the signature blob, russh overwrites the key&amp;#39;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.&lt;/p&gt;
&lt;p&gt;Confirmed by running…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; crates.io: russh&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;In `russh/src/server/encrypted.rs`, `server_read_auth_request_pk` (0.63.3, around lines 880-990):&lt;/p&gt;
&lt;p&gt;* The requested algorithm name (`pubkey_algo`) is read and only used to decode the key: `PublicKeyOrCertificate::decode(&amp;amp;pubkey_algo, &amp;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;amp;pubkey, &amp;amp;buf, &amp;amp;sig)`. `ssh-key` picks the hash from **the signature&amp;#39;s own algorithm** (`sig.algorithm()`).
* `pubkey_algo` and `sig.algorithm()` are never compared.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;**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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;* **Up to 0.46:** after reading the algorithm name inside the signature blob, russh overwrites the key&amp;#39;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.&lt;/p&gt;
&lt;p&gt;Confirmed by running…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-j7h2-66j4-ghjf</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-111062</title>
      <link>https://db.gcve.eu/vuln/ubuntu-cve-2026-111062</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:26.10: rust-russh&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:26.10: rust-russh&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ubuntu-cve-2026-111062</guid>
    </item>
  </channel>
</rss>
