russh's SSH client is susceptible to unbounded allocations via EXT_INFO packets

Summary 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::processpacket handling handleextinfo) in a live client session with attacker-supplied packet bodies in the pre-authentication state; the captured output below is from that real execution. russh's client stores every extension name it parses out of an EXTINFO 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'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…

curl https://cve.zerocrew.in/api/cve/CVE-2026-116773