GHSA-qpg5-fx6p-8cq3

net-ssh's host-certificate verifier (`Net::SSH::HostKeyEntries::CertAuthority#matches_key?`) checks exactly two things when a server presents an OpenSSH certificate (`*[email protected]`) under a `@cert-authority` trusted-CA entry: (1) the cert is self-consistently signed (signature_valid).

net-ssh's transport packet reader trusts the 4-byte wire packet length without capping it against RFC 4253 §6.1 (35000 bytes). Pre-KEX (plaintext), a malicious server can declare an arbitrarily large packet length and stream data, causing unbounded client memory growth before authentication.

Net::SSH::Transport::ServerVersion#read! appends each received byte to @version until a newline, then copies to @header, with no maximum line length or total byte cap enforced. A malicious server sending a long identification line without LF causes unbounded memory growth.

When a crafted ed25519 private key containing an insane number of rounds is loaded, net-ssh enters an infinite CPU-time consuming loop for a very long time trying to load the key. The fact that the key is not a real SSH key does not matter in this regard.

Shell command injection is possible in Net::SSH::Proxy::Command and Net::SSH::Proxy::Jump. When an application configures a proxy and passes attacker-influenced host, port, or remote_user values to Net::SSH.start (or a jump string to Proxy::Jump.new), shell metacharacters in those values may be interpreted.

Net::SSH::Transport::Session#poll_message pushes every packet received during key exchange that is not on the "allowed during KEX" list into an unbounded @queue (Array) with no size cap. A malicious server that completes KEXINIT (putting net-ssh into pending KEX) and then floods non-allowed packets can cause unbounded memory growth.