CVE-2026-56855: Prevent DoS on deadlocked established channel in golang.org/x/crypto/ssh
Prevent DoS on deadlocked established channel in golang.org/x/crypto/ssh
Other sources
Previously, after a channel has been established, a malicious peer could send crafted messages that would deadlock the entire connection. Now, we handle all RFC 4254 channel messages; global requests are handled explicitly. Then, treat all other messages as a protocol error and tear the connection down instead of buffering and blocking.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 1.31.0-33 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 1.30.10-30 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 0.14.0-17 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 1.9.5-21 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 2.101.0-1 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 8.7.11-9 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 1.12.15-14 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 1.8.4-2 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 2.27.0-14
Event History
Frequently Asked Questions
Who is exposed to this issue?
Any application using golang.org/x/crypto/ssh that establishes an SSH channel with a malicious peer may be exposed. The crafted messages are sent after the channel has been established.
What does an attacker need to do to trigger the denial of service?
The attacker needs to act as the connected peer and send crafted channel messages after channel establishment. Those messages can deadlock the entire SSH connection.
How is the problematic message handling changed?
RFC 4254 channel messages are handled, and global requests are handled explicitly. Other messages are treated as protocol errors and cause the connection to be torn down rather than buffered and allowed to block.