golang.org/x/crypto/ssh EUVD-2026-31400

The vulnerable application must perform a single Write call larger than 4GB (2^32 bytes) on an SSH channel using golang.org/x/crypto/ssh prior to 0.52.0; smaller writes, or large transfers broken into multiple sub-4GB Write calls, do not trigger the overflow. Limiting factors: the trigger depends on the calling application's I/O pattern rather than purely attacker-controlled SSH frames, so an attacker generally needs to operate against a service that legitimately accepts or transfers very large payloads in one syscall (bulk SFTP, large blob streaming) and must either be the peer of the SSH connection or coerce the application into such a write. CVSS PR:N indicates no SSH authentication is enumerated as required by the metric, but in practice most SSH services require authentication before a channel is open and writable.

Signals diverge significantly here: CVSS v3.1 9.1 (AV:N/AC:L/PR:N/UI:N/C:N/I:H/A:H) reflects high integrity and availability impact reachable over the network without authentication, while EPSS is only 0.02% (5th percentile), SSVC reports Exploitation:none with Technical Impact:partial, and the issue is not on the CISA KEV list. The CVSS integrity:high rating is questionable given the bug only causes a stuck loop sending empty packets - this is fundamentally an availability/DoS condition, not an integrity compromise, so the score likely overstates real-world impact. Exploitation also requires the application to legitimately attempt a single Write of more than 4GB on an SSH channel, which is uncommon in typical SSH usage patterns and depends entirely on application behavior rather than attacker-controlled SSH protocol input. Realistic priority is moderate: patch in standard maintenance cycles for any Go service handling large transfers (e.g., SFTP servers, backup tooling), but this is not an emergency.

An attacker controlling one side of an SSH session (e.g., a malicious SFTP client uploading to a vulnerable Go-based SFTP server, or a malicious server responding to a Go SSH client) induces or waits for the peer application to issue a single Write of more than 4GB on an SSH channel, after which the writer goroutine locks into an infinite loop emitting empty packets and consuming CPU while making no progress. No public exploit is identified at time of analysis, and successful triggering depends on the victim application's write patterns rather than attacker-supplied SSH protocol data alone.