ZDF
Sign inSign up

Vulnerabilities

Vulnerability · CVE-2026-46702

russh: Post-decompression SSH packet size was not bounded, allowing remote oversized compressed packets

Published May 29, 2026 · catalog updated Nov 10, 2026 · RustSec Rust

Last checked Nov 12, 2026. A connected source was read within the last 7 days.

Check if you run it

No confirmed exploitation is on record for CVE-2026-46702. EPSS is 0.27%. Act only if a listed version of RustSec Rust is installed.

Gaps on this record

  • No vendor fix or required action is stored. Compare the linked advisory before you change production.

Same product and reporting

Severity
High7.5
Known exploitation
Not in CISA/VulnCheck KEV
EPSS
0.27%
Remediation
Advisory link
Affected products
crates.io russh

### Summary When SSH compression is enabled, 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 , the same remote decompression path used , which appears to make the historical impact worse. ### Details The normal SSH transport read path enforces a packet-length limit before the packet body is read: - However, RFC 4253 compression is applied to the SSH field only. The 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. In , compressed packet bodies are later decompressed in: - - - Before the fix, 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. It was verified that an attacker-crafted compressed payload can stay below the normal implementation transport packet cap while still inflating above the intended post-decompression bound. In other words, this is not only a "large on-wire packet" issue. Version detail: - The underlying post-decompression bounds bug appears to affect as far back as . - In historical releases , the remote decompression path still used . Remote compressed SSH traffic could drive that path, and under constrained memory that historical code path could abort the process. - In current-style releases , non-secret packet/decompression buffers were moved off and onto , but the post-decompression size still remained unbounded. So the bug class remained reachable remotely,

Are you affected?

Enter the version you run. The result uses only the ranges stored on this record.

The check returns affected, not affected, or incomplete. It does not guess a version that is missing from the record.

  • crates.io russh0.34.0 → 0.61.1

How to fix CVE-2026-46702

What to do

Three questions, each answered from this record only. Confirm the vendor advisory before you patch.

Should you patch?

No confirmed exploitation is on record for CVE-2026-46702. EPSS is 0.27%. Act only if a listed version of RustSec Rust is installed.

Which versions are affected?

Compare what you have installed with 0.34.0 → 0.61.1. Compare the installed version with the linked vendor advisory before you change production.

What should an analyst verify?

CWE-770: Allocation of Resources Without Limits or Throttling. EPSS 0.27%. There is no CISA KEV listing. No Exploit-DB or Metasploit reference is linked. Use the source links for the original advisory.

Code

The project this record applies to. Exploit listings stay in References.

Timeline

Detection, updates, and resolution for this record.

  1. May 29, 2026 · GitHub Advisory Database

    Detected

    ### Summary When SSH compression is enabled, 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

  2. Nov 10, 2026 · GitHub Advisory Database

    Fix available

    russh fixed in 0.61.1

  3. Nov 10, 2026 · GitHub Advisory Database

    Fix available

    russh fixed in 0.61.1

  4. Nov 10, 2026 · GitHub Advisory Database

    Updated

    ### Summary When SSH compression is enabled, 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

Sources

  • CVE.orgVulnerability recordCVE-2026-46702

    Official CVE identifier

    cve.org
  • GitHub Advisory DatabasePackage advisoryGHSA-wwx6-x28x-8259

    GitHub Advisory Database record mirrored by OSV.

    github.com
  • OpenSSF OSV / OSV ScannerPackage advisoryGHSA-wwx6-x28x-8259

    russh: Post-decompression SSH packet size was not bounded, allowing remote oversized compressed packets

    osv.dev
  • RustSec Advisory DBVendor advisoryCVE-2026-46702

    With or compression negotiated, the packet length that russh checks applies to the compressed payload only. The decompressor kept growing its output buffer until the whole payload was inflated, with no limit of its own, so a packet that is small on the wire could expand to hundre

    crates.io

References

Freshness

Last verified in this catalog Nov 10, 2026. Significant claims (KEV, EPSS, CVSS, affected ranges) come from the source rows above — open the original publisher for the authoritative advisory.

  • RustSec Advisory DBNov 12, 2026
  • GitHub Advisory DatabaseNov 11, 2026
  • OpenSSF OSV / OSV ScannerNov 11, 2026
  • CVE.orgNov 10, 2026