<?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>Thu, 01 Oct 2026 17:58:26 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-102824</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-102824</link>
      <description>&lt;p&gt;Russh is a Rust SSH client and server library. Prior to 0.63.0, the hybrid ML-KEM 768 and X25519 implementation in russh/src/kex/hybrid_mlkem.rs accepts an all-zero 32-byte peer X25519 public key in both server_dh and compute_shared_secret, forcing the X25519 contribution to the combined shared secret to zero. A malicious SSH peer can therefore make the combined secret depend only on ML-KEM, defeating the hybrid exchange&amp;#39;s intended fallback protection if ML-KEM is later weakened. This issue is fixed in version 0.63.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Russh is a Rust SSH client and server library. Prior to 0.63.0, the hybrid ML-KEM 768 and X25519 implementation in russh/src/kex/hybrid_mlkem.rs accepts an all-zero 32-byte peer X25519 public key in both server_dh and compute_shared_secret, forcing the X25519 contribution to the combined shared secret to zero. A malicious SSH peer can therefore make the combined secret depend only on ML-KEM, defeating the hybrid exchange&amp;#39;s intended fallback protection if ML-KEM is later weakened. This issue is fixed in version 0.63.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-102824</guid>
    </item>
    <item>
      <title>GHSA-w3jg-pjxf-73p4 — Russh: Missing X25519 zero-point validation in hybrid ML-KEM key exchange</title>
      <link>https://db.gcve.eu/vuln/ghsa-w3jg-pjxf-73p4</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; crates.io: russh&lt;/p&gt;
&lt;p&gt;## Vulnerability&lt;/p&gt;
&lt;p&gt;The hybrid ML-KEM 768 + X25519 key exchange implementation in `russh/src/kex/hybrid_mlkem.rs` does not validate that the remote peer&amp;#39;s X25519 public key is not the zero point (all-zero 32-byte value). This allows a remote peer to force the X25519 contribution to the combined shared secret to zero, reducing the hybrid KEX to a single-algorithm exchange.&lt;/p&gt;
&lt;p&gt;Affected code at HEAD (v0.62.4, commit 0089c89):&lt;/p&gt;
&lt;p&gt;**Server-side** (`server_dh`, lines 92-93):
```rust
let mut c_pk1 = MontgomeryPoint([0; 32]);
c_pk1.0.copy_from_slice(c_pk1_bytes);
// No zero-point check - proceeds to: let k_cl = s_secret * c_pk1;
```&lt;/p&gt;
&lt;p&gt;**Client-side** (`compute_shared_secret`, lines 154-155):
```rust
let mut s_pk1 = MontgomeryPoint([0; 32]);
s_pk1.0.copy_from_slice(s_pk1_bytes);
// No zero-point check - proceeds to: let k_cl = x25519_secret * s_pk1;
```&lt;/p&gt;
&lt;p&gt;## Root Cause&lt;/p&gt;
&lt;p&gt;Commit a7fc1eb (2026-07-22, &amp;#34;fix mpint encoding and validate curve25519 keys&amp;#34;) added zero-point validation to the standalone Curve25519 KEX in `russh/src/kex/curve25519.rs` at two locations:
- `server_dh` line 77: `if client_pubkey.0 == [0u8; 32] { return Err(crate::Error::Kex); }`
- `compute_shared_secret` line 122: `if remote_pubkey.0 == [0u8; 32] { return Err(crate::Error::Kex); }`&lt;/p&gt;
&lt;p&gt;The same X25519 scalar multiplication pattern appears in `hybrid_mlkem.rs`, but the fix was not applied there.&lt;/p&gt;
&lt;p&gt;## Proof of Concept&lt;/p&gt;
&lt;p&gt;A malicious SSH client negotiating `mlkem768x25519-sha256` can send a KEX_HYBRID_INIT message containing a vali…&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;## Vulnerability&lt;/p&gt;
&lt;p&gt;The hybrid ML-KEM 768 + X25519 key exchange implementation in `russh/src/kex/hybrid_mlkem.rs` does not validate that the remote peer&amp;#39;s X25519 public key is not the zero point (all-zero 32-byte value). This allows a remote peer to force the X25519 contribution to the combined shared secret to zero, reducing the hybrid KEX to a single-algorithm exchange.&lt;/p&gt;
&lt;p&gt;Affected code at HEAD (v0.62.4, commit 0089c89):&lt;/p&gt;
&lt;p&gt;**Server-side** (`server_dh`, lines 92-93):
```rust
let mut c_pk1 = MontgomeryPoint([0; 32]);
c_pk1.0.copy_from_slice(c_pk1_bytes);
// No zero-point check - proceeds to: let k_cl = s_secret * c_pk1;
```&lt;/p&gt;
&lt;p&gt;**Client-side** (`compute_shared_secret`, lines 154-155):
```rust
let mut s_pk1 = MontgomeryPoint([0; 32]);
s_pk1.0.copy_from_slice(s_pk1_bytes);
// No zero-point check - proceeds to: let k_cl = x25519_secret * s_pk1;
```&lt;/p&gt;
&lt;p&gt;## Root Cause&lt;/p&gt;
&lt;p&gt;Commit a7fc1eb (2026-07-22, &amp;#34;fix mpint encoding and validate curve25519 keys&amp;#34;) added zero-point validation to the standalone Curve25519 KEX in `russh/src/kex/curve25519.rs` at two locations:
- `server_dh` line 77: `if client_pubkey.0 == [0u8; 32] { return Err(crate::Error::Kex); }`
- `compute_shared_secret` line 122: `if remote_pubkey.0 == [0u8; 32] { return Err(crate::Error::Kex); }`&lt;/p&gt;
&lt;p&gt;The same X25519 scalar multiplication pattern appears in `hybrid_mlkem.rs`, but the fix was not applied there.&lt;/p&gt;
&lt;p&gt;## Proof of Concept&lt;/p&gt;
&lt;p&gt;A malicious SSH client negotiating `mlkem768x25519-sha256` can send a KEX_HYBRID_INIT message containing a vali…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-w3jg-pjxf-73p4</guid>
    </item>
  </channel>
</rss>
