CVE-2026-39829: Denial of Service in Go SSH Parser

The Go SSH implementation inside the golang.org/x/crypto/ssh package prior to version 0.52.0 is vulnerable to an unauthenticated remote Denial of Service (DoS) vulnerability. During the public key authentication phase of an SSH handshake, a client can send public keys with pathologically large parameters. The library attempts to parse these keys and perform expensive mathematical computations before validating the key parameters.\n\nAn attacker does not need to possess valid credentials to trigger this vulnerability. The parsing and subsequent validation attempt occurs during the initial authentication phase (SSH_MSG_USERAUTH_REQUEST), which is accessible to any network-connected client. This flaw exposes any server utilizing the Go SSH library, such as container runtimes, Kubernetes components, and custom SSH bastions.

The root cause of this vulnerability lies in the missing range and size verification of incoming cryptographic parameters within the RSA and DSA public key parsers in ssh/keys.go. When an SSH client requests public key authentication, it transmits key parameters as raw byte arrays, which the server parses into Go's arbitrary-precision big.Int structures.\n\nIn the case of RSA, the parser extracted the modulus $N$ and public exponent $E$ using Unmarshal, but did not check the bit length of the modulus $N$. In the case of DSA, the parser failed to verify the sub-prime $Q$, the generator $G$, and the public value $Y$ against standard boundaries.\n\nBecause signature verification involves modular exponentiation (such as $g^{u_1} \cdot y^{u_2} \pmod p$), processing pathologically large values of $N$, $Q$, or $Y$ causes the underlying arbitrary-precision arithmetic operations to consume massive CPU resources. The execution time of these operations scales quadratically or cubically with the bit length, allowing an attacker to exhaust the host's CPU cycles with a single crafted key.

The vulnerability was mitigated in golang.org/x/crypto version 0.52.0 by enforcing strict constraints on parameter sizes during deserialization.\n\nIn the RSA parser (parseRSA in ssh/keys.go), a boundary check was introduced to reject keys with a modulus exceeding 8192 bits. This limit aligns with the threshold enforced by the Go standard library's crypto/tls package.\n\ngo\n// ssh/keys.go\nif w.N.BitLen() > 8192 {\n\treturn nil, nil, errors.New(\"ssh: rsa modulus too large\")\n}\n\n\nFor DSA public keys, the patch introduced validations in both checkDSAParams and parseDSA. It restricts the subprime $Q$ to exactly 160 bits (in accordance with FIPS 186-2) and validates that the generator $G$ and public value $Y$ reside within the finite group boundaries ($0 < G < P$, $0 < Y < P$).\n\ngo\n// ssh/keys.go\nif l := param.Q.BitLen(); l != 160 {\n\treturn fmt.Errorf(\"ssh: unsupported DSA sub-prime size %d\", l)\n}\nif param.G.Cmp(param.P) >= 0 {\n\treturn errors.New(\"ssh: DSA generator larger than modulus\")\n}\nif param.G.Sign() <= 0 {\n\treturn errors.New(\"ssh: DSA generator must be positive\")\n}\nif w.Y.Sign() <= 0 || w.Y.Cmp(w.P) >= 0 {\n\treturn nil, nil, errors.New(\"ssh: DSA public value Y out of range\")\n}\n\n\nThese checks ensure that the mathematical operations performed during signature verification are bounded by safe complexity limits.

An attacker can exploit this vulnerability by initiating an SSH handshake and sending a crafted public key. During the SSH_MSG_USERAUTH_REQUEST phase, the attacker submits an RSA public key containing a modulus $N$ with a length of several hundred thousand bits, or a DSA public key containing an oversized sub-prime $Q$ or public value $Y$.\n\nThe SSH server reads the packet and unmarshals the parameters into memory as big.Int structures. When the server attempts to verify the signature associated with the public key, the cryptographic package executes modular exponentiations using these arbitrary-precision integers.\n\nBecause the CPU overhead of multi-precision division and multiplication scales exponentially with the input size, a single authentication attempt can lock a CPU core for several minutes. A threat actor can send multiple parallel authentication requests, quickly exhausting all available CPU cores on the host and resulting in a complete Denial of Service for legitimate connections.

This vulnerability has a high CVSS v3.1 base score of 7.5. The impact is categorized as a high availability loss because successful exploitation halts the target service. The vulnerability can be exploited remotely, does not require authentication, and does not require user interaction.\n\nDue to Go's dominance in cloud-native infrastructure, the downstream impact is extensive. Vulnerable versions of the SSH library are embedded within critical technologies, including Docker, containerd, Kubernetes-related components, HashiCorp Vault, and various Linux distribution utilities.\n\nIf these management agents or container daemons expose SSH endpoints or parse untrusted keys, they can be targeted to disrupt host operations and infrastructure orchestration. High-priority deployments must immediately scan their binaries to detect compiled dependencies on older versions of golang.org/x/crypto.

The primary remediation strategy is upgrading the golang.org/x/crypto dependency to version 0.52.0 or higher and recompiling all dependent Go applications.\n\nTo identify vulnerable binaries, security teams should use static analysis utilities such as govulncheck. This tool parses the embedded build metadata of Go binaries to verify import versions:\n\nbash\ngovulncheck ./...\n\n\nTo update the dependency within a Go module, run the following commands:\n\nbash\ngo get golang.org/x/crypto@v0.52.0\ngo mod tidy\n\n\nIn environments where immediate updating is not possible, access to SSH interfaces should be restricted to trusted networks using firewall rules and network access control lists (ACLs).