<?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://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-05T15:57:08.006775+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" 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://cve.radiocsirt.org/vuln/euvd-2026-326679</id>
    <title>EUVD-2026-326679</title>
    <updated>2026-10-05T15:57:08.053602+00:00</updated>
    <content>EUVD-2026-326679</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-326679"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2026-46702</id>
    <title>fkie_cve-2026-46702</title>
    <updated>2026-10-05T15:57:08.053642+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Russh is a Rust SSH client &amp; server library. From version 0.34.0 to before version 0.61.1, when SSH compression is enabled, russh accepted compressed packets whose on-wire size passed the normal transport packet-length checks but whose decompressed size was much larger. This allowed a remote peer to send oversized post-decompression packets that should have been rejected. In current releases, this is a remote denial-of-service / resource-exhaustion issue in the post-decompression receive path. In older releases before 0.58.0, the same remote decompression path used CryptoVec, which appears to make the historical impact worse. This issue has been patched in version 0.61.1.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2026-46702"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-wwx6-x28x-8259</id>
    <title>GHSA-wwx6-x28x-8259 — russh: Post-decompression SSH packet size was not bounded, allowing remote oversized compressed packets</title>
    <updated>2026-10-05T15:57:08.053678+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>When SSH compression is enabled, `russh` accepted compressed packets whose on-wire size passed the normal transport packet-length checks but whose decompressed size was much larger. This allowed a remote peer to send oversized post-decompression packets that should have been rejected.</p>
<p>In current releases, this is a remote denial-of-service / resource-exhaustion issue in the post-decompression receive path.</p>
<p>In older releases before `0.58.0`, the same remote decompression path used `CryptoVec`, which appears to make the historical impact worse.</p>
<p>### Details</p>
<p>The normal SSH transport read path enforces a packet-length limit before the packet body is read:</p>
<p>- `russh/src/cipher/mod.rs`</p>
<p>However, RFC 4253 compression is applied to the SSH `payload` field only. The `packet_length` field and MAC are computed over the compressed payload, so a packet that is reasonably sized on the wire can still expand to a much larger message body after decompression.</p>
<p>In `russh`, compressed packet bodies are later decompressed in:</p>
<p>- `russh/src/compression.rs`
- `russh/src/client/mod.rs`
- `russh/src/server/session.rs`</p>
<p>Before the fix, `Decompress::decompress()` grew its output buffer by repeated doubling and did not enforce a separate post-decompression ceiling. That meant a peer could send a small compressed packet that passed the normal on-wire transport length checks and then inflate it into a much larger packet after decompression.</p>
<p>It was verified that an attacker-crafted compr…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-wwx6-x28x-8259"/>
  </entry>
</feed>
