OpenSSH: no maximum packet length check when decompressing highly compressed data

CVSS 6.5CVE-2026-106585Kernel, userspace & hypervisorcurated

Impact

sshd and ssh before 10.6 do not enforce the maximum packet length while decompressing, so a peer can hand over a small compressed payload that expands far beyond the intended limit. The record scores this as partial integrity and availability impact, reachable over the network with no authentication, which makes it the most exposed of the 10.6 set: sshd is the one daemon that is listening on every management interface, bastion host and GPU node in the fleet. On a GPU cluster the practical worry is memory pressure or an sshd that stops answering on nodes that are only reachable by SSH, which turns a routine job into a console or BMC recovery. No code execution is claimed in the record.

Who can reach it

Anyone who can open a TCP connection to sshd, before authentication. The client side is also affected when connecting to a hostile or compromised server.

What to do

Upgrade OpenSSH to 10.6 (or the distribution backport) and restart sshd. Existing sessions survive an sshd restart, so this is a package update plus daemon restart with no node drain or reboot; schedule it fleet-wide rather than per node.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-106585 https://www.openssh.com/releasenotes.html#10.6

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.