<?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, 05 Nov 2026 04:44:34 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-116773</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-116773</link>
      <description>&lt;p&gt;russh is a Rust SSH client and server library that includes an SSH agent protocol implementation. Prior to 0.65.0, the client Session::process_packet path in russh/src/client/encrypted.rs accepts repeated packets encoded with russh&amp;#39;s private msg::EXT_INFO = 7 before authentication, while the standards-compliant EXT_INFO message number 82 does not reach the affected handler. The handle_ext_info function appends every parsed extension name to received_extensions without clearing, deduplicating, or bounding the vector. A malicious SSH server that deliberately sends private message number 7 can therefore retain an unbounded number of attacker-controlled extension names for the session lifetime, causing progressive client memory exhaustion. This issue is fixed in version 0.65.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;russh is a Rust SSH client and server library that includes an SSH agent protocol implementation. Prior to 0.65.0, the client Session::process_packet path in russh/src/client/encrypted.rs accepts repeated packets encoded with russh&amp;#39;s private msg::EXT_INFO = 7 before authentication, while the standards-compliant EXT_INFO message number 82 does not reach the affected handler. The handle_ext_info function appends every parsed extension name to received_extensions without clearing, deduplicating, or bounding the vector. A malicious SSH server that deliberately sends private message number 7 can therefore retain an unbounded number of attacker-controlled extension names for the session lifetime, causing progressive client memory exhaustion. This issue is fixed in version 0.65.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-116773</guid>
    </item>
    <item>
      <title>GHSA-4p9f-7p9m-5vfg — russh's SSH client is susceptible to unbounded allocations via EXT_INFO packets</title>
      <link>https://db.gcve.eu/vuln/ghsa-4p9f-7p9m-5vfg</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; crates.io: russh&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;**All evidence, reproduction steps, and scripts in the report were verified against a real running instance. Nothing is fabricated or synthetic; every verdict is backed by captured output from an actual deployment.** Concretely, the evidence comes from executing the real russh v0.64.1 client packet parser (`Session::process_packet` handling `handle_ext_info`) in a live client session with attacker-supplied packet bodies in the pre-authentication state; the captured output below is from that real execution.&lt;/p&gt;
&lt;p&gt;russh&amp;#39;s client stores every extension name it parses out of an `EXT_INFO` packet into a per-session vector and never clears, caps, or deduplicates it (`russh/src/client/encrypted.rs:433`, field declared at `russh/src/session.rs:60`). The packet is accepted without limit in the pre-authentication states, so a server - which is exactly the attacker position for a client library, and remains one even after the client has verified its host key - can send an unbounded sequence of these packets and grow the client&amp;#39;s memory for as long as the session lives: 400 packets of about 26 KB each, carrying 3000 extension names apiece, retained 49.1 MiB (about 4.8 times the wire bytes) with the vector reaching 1,200,000 entries, while an equal volume of banner packets retained nothing. Two details make this reachable in practice: russh accepts `EXT_INFO` in its pre-auth states with no budget of any kind (its automatic rekey read-limit only engages after authentication), and…&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;### Summary&lt;/p&gt;
&lt;p&gt;**All evidence, reproduction steps, and scripts in the report were verified against a real running instance. Nothing is fabricated or synthetic; every verdict is backed by captured output from an actual deployment.** Concretely, the evidence comes from executing the real russh v0.64.1 client packet parser (`Session::process_packet` handling `handle_ext_info`) in a live client session with attacker-supplied packet bodies in the pre-authentication state; the captured output below is from that real execution.&lt;/p&gt;
&lt;p&gt;russh&amp;#39;s client stores every extension name it parses out of an `EXT_INFO` packet into a per-session vector and never clears, caps, or deduplicates it (`russh/src/client/encrypted.rs:433`, field declared at `russh/src/session.rs:60`). The packet is accepted without limit in the pre-authentication states, so a server - which is exactly the attacker position for a client library, and remains one even after the client has verified its host key - can send an unbounded sequence of these packets and grow the client&amp;#39;s memory for as long as the session lives: 400 packets of about 26 KB each, carrying 3000 extension names apiece, retained 49.1 MiB (about 4.8 times the wire bytes) with the vector reaching 1,200,000 entries, while an equal volume of banner packets retained nothing. Two details make this reachable in practice: russh accepts `EXT_INFO` in its pre-auth states with no budget of any kind (its automatic rekey read-limit only engages after authentication), and…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-4p9f-7p9m-5vfg</guid>
    </item>
    <item>
      <title>RHSA-2026:93904 — Red Hat Security Advisory: Red Hat Hardened Images RPMs Security Update</title>
      <link>https://db.gcve.eu/vuln/rhsa-2026:93904</link>
      <description>&lt;p&gt;russh: russh: Denial of Service via resource exhaustion in SSH agent russh: russh: Denial of Service via uncontrolled memory consumption in SSH agent russh: russh: Denial of Service via unbounded memory allocation in extension handling russh: russh: Denial of service via zero maximum packet size russh: russh: Unauthorized key signing via SSH agent confirmation bypass&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;russh: russh: Denial of Service via resource exhaustion in SSH agent russh: russh: Denial of Service via uncontrolled memory consumption in SSH agent russh: russh: Denial of Service via unbounded memory allocation in extension handling russh: russh: Denial of service via zero maximum packet size russh: russh: Unauthorized key signing via SSH agent confirmation bypass&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/rhsa-2026:93904</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-116773</title>
      <link>https://db.gcve.eu/vuln/ubuntu-cve-2026-116773</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 that includes an SSH agent protocol implementation. Prior to 0.65.0, the client Session::process_packet path in russh/src/client/encrypted.rs accepts repeated packets encoded with russh&amp;#39;s private msg::EXT_INFO = 7 before authentication, while the standards-compliant EXT_INFO message number 82 does not reach the affected handler. The handle_ext_info function appends every parsed extension name to received_extensions without clearing, deduplicating, or bounding the vector. A malicious SSH server that deliberately sends private message number 7 can therefore retain an unbounded number of attacker-controlled extension names for the session lifetime, causing progressive client memory exhaustion. This issue is fixed in version 0.65.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 that includes an SSH agent protocol implementation. Prior to 0.65.0, the client Session::process_packet path in russh/src/client/encrypted.rs accepts repeated packets encoded with russh&amp;#39;s private msg::EXT_INFO = 7 before authentication, while the standards-compliant EXT_INFO message number 82 does not reach the affected handler. The handle_ext_info function appends every parsed extension name to received_extensions without clearing, deduplicating, or bounding the vector. A malicious SSH server that deliberately sends private message number 7 can therefore retain an unbounded number of attacker-controlled extension names for the session lifetime, causing progressive client memory exhaustion. This issue is fixed in version 0.65.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ubuntu-cve-2026-116773</guid>
    </item>
  </channel>
</rss>
