<?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-04T23:17:58.826547+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-116774</id>
    <title>fkie_cve-2026-116774</title>
    <updated>2026-11-04T23:17:58.911127+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>russh is a Rust SSH client and server library that includes an SSH agent protocol implementation. From 0.60.0 until 0.65.0, channel-open parsing accepts a peer-declared maximum_packet_size of zero and passes it into ChannelTx::poll_writable in russh/src/channels/io/tx.rs. The Channel::data, Channel::make_writer, and Channel::into_stream asynchronous write paths then calculate a writable size of zero and remain pending forever because window adjustments cannot satisfy a static zero packet maximum. An authenticated client can strand server writes, and a malicious server can strand client writes, allowing affected tasks, channels, and connections to accumulate without surfacing an error. This issue is fixed in version 0.65.0.</p>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-116774"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-fw5c-8223-6h42</id>
    <title>GHSA-fw5c-8223-6h42 — russh: peer-declared zero maximum packet size permanently stalls channel writes (silent AsyncWrite hang)</title>
    <updated>2026-11-04T23:17:58.911237+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> crates.io: russh</p>
<p>## Summary</p>
<p>A peer can advertise `maximum packet size = 0` in its channel-open message (`CHANNEL_OPEN` when attacking a server, `CHANNEL_OPEN_CONFIRMATION` when attacking a client). russh accepts the value without validation and copies it into the channel write state, where it caps the size of every outgoing data chunk. In the `AsyncWrite` code path (`ChannelTx::poll_writable`, used by `Channel::data()`, `Channel::make_writer()` and `Channel::into_stream()`), a cap of 0 makes every write future stay `Poll::Pending` forever: `writable = max_packet_size.min(window_size).min(buf_len)` is always 0, and no future event can ever raise it (a static maximum packet size of 0 can never be satisfied by any amount of peer-granted window). The write neither completes nor errors, so the application task hangs silently.</p>
<p>Every other write path in russh already treats `max_packet_size == 0` as an error (`Error::Inconsistent`): `Channel::reserve_writable_chunk` (`russh/src/channels/mod.rs:363-365`) and the session packetizers (`russh/src/session.rs:489-492` and `549-552`). The `AsyncWrite` path is the only one that lacks the guard - it contradicts the crate's own invariant.</p>
<p>## Root cause</p>
<p>(1) Peer value accepted without validation:</p>
<p>- `russh/src/parsing.rs:44` (`OpenChannelMessage::parse`): `let maxpacket = map_err!(u32::decode(r))?;` stored as `recipient_maximum_packet_size` (`:25-30`); no range check. Same for `ChannelOpenConfirmation::decode` at `russh/src/parsing.rs:194-207`.
- The only…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-fw5c-8223-6h42"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/rhsa-2026:93904</id>
    <title>RHSA-2026:93904 — Red Hat Security Advisory: Red Hat Hardened Images RPMs Security Update</title>
    <updated>2026-11-04T23:17:58.911319+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>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</p>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/rhsa-2026:93904"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ubuntu-cve-2026-116774</id>
    <title>UBUNTU-CVE-2026-116774</title>
    <updated>2026-11-04T23:17:58.911353+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 that includes an SSH agent protocol implementation. From 0.60.0 until 0.65.0, channel-open parsing accepts a peer-declared maximum_packet_size of zero and passes it into ChannelTx::poll_writable in russh/src/channels/io/tx.rs. The Channel::data, Channel::make_writer, and Channel::into_stream asynchronous write paths then calculate a writable size of zero and remain pending forever because window adjustments cannot satisfy a static zero packet maximum. An authenticated client can strand server writes, and a malicious server can strand client writes, allowing affected tasks, channels, and connections to accumulate without surfacing an error. This issue is fixed in version 0.65.0.</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ubuntu-cve-2026-116774"/>
  </entry>
</feed>
