CVE-2026-39827: Denial of Service via Unbounded Memory Growth in Go SSH (golang.org/x/crypto/ssh)

The vulnerability CVE-2026-39827 represents a critical memory leak flaw in the golang.org/x/crypto/ssh package, which is Go's official implementation of the SSH protocol.

This package is widely used to develop custom SSH daemons, remote administration agents, container orchestration handlers, and secure Git hosting applications. When a server exposes an SSH endpoint using this library, it establishes a multiplexed transport channel structure to manage multiple virtual channels over a single physical TCP connection.

The vulnerability is classified under CWE-401 (Missing Release of Memory after Effective Lifetime). It is triggered when an authenticated client requests a logical channel that the server application rejects, leading to an unbounded memory leak that eventually causes a Denial of Service due to system resource exhaustion.

To understand the root cause of CVE-2026-39827, it is necessary to examine how the Go SSH multiplexer manages connection states. Under normal operation, when a client sends an SSH_MSG_CHANNEL_OPEN packet, the server's multiplexer (mux) assigns a localId to trace the request and registers it in its internal map (mux.chanList). This list acts as a registry to route incoming traffic correctly.

Once registered, the multiplexer delivers a NewChannel object to the server's high-level application handler. The application determines whether to allow the channel based on authorization, resource usage, or requested services. If the application decides to deny the request, it invokes the Reject() function.

The flaw lies in the original implementation of the Reject() function in ssh/channel.go. While the method updated the channel's internal state machine and sent the appropriate rejection packet to the client, it completely omitted any code to clean up the registration record inside the connection's chanList map.

Because the multiplexer maintains a strong reference to the rejected channel throughout the lifetime of the underlying TCP session, the Go garbage collector is unable to reclaim any of the allocated memory. This includes the internal channel structures, input/output packet queues, and synchronization channels, resulting in a persistent memory leak.

The following Mermaid diagram outlines the vulnerable channel setup state vs. the corrected cleanup flow.

In the vulnerable implementation, the Reject() function processed the rejection and returned immediately, leaving the channel registered. Let us analyze the difference introduced in the patch.

// Vulnerable Code Path
func (ch *channel) Reject(reason RejectionReason, message string) error {
	reject := chanOpenConfirmMsg{
		// ... fields mapped ...
	}
	ch.decided = true
	return ch.sendMessage(reject) // Exit without cleaning up chanList
}

// Patched Code Path (6c195c8a97ae3d91a366ebdd7787d5faa64bf42a)
func (ch *channel) Reject(reason RejectionReason, message string) error {
	reject := chanOpenConfirmMsg{
		// ... fields mapped ...
	}
	ch.decided = true
	err := ch.sendMessage(reject)
 
	// Remove the channel from the mux to prevent memory leaks.
	// Do not call ch.close() here: no goroutine holds a reference to a
	// rejected channel's internal channels (msg, incomingRequests), so
	// removing it from chanList is sufficient for GC. Calling close()
	// would race with the mux loop goroutine (handlePacket or dropAll),
	// causing a panic from closing an already-closed channel.
	ch.mux.chanList.remove(ch.localId)
 
	return err
}

As annotated in the fix, the developers deliberately avoided calling ch.close(). Doing so would trigger a severe race condition against the multiplexer's packet handling loops, which would crash the runtime with a panic. Simply deleting the reference from the map allows the garbage collector to safely sweep up the unused allocations.

An attacker must establish an authenticated SSH connection to exploit this vulnerability. No authorization privileges beyond standard authentication are required, meaning any standard user or automated service account with SSH access can perform the attack.

The attack begins when the client issues a loop of consecutive SSH_MSG_CHANNEL_OPEN requests. To trigger the memory leak, the client requests a channel type that the server is configured to reject. Common examples include requesting TCP port forwarding or custom subsystem channels when such features are disabled.

Every rejected attempt allocates a fresh channel context containing memory structures that remain resident in RAM. By scripting a rapid cycle of channel open requests over a single persistent connection, an attacker can leak megabytes of memory per minute. This process eventually causes memory pressure to escalate to the point where the operating system's Out-Of-Memory killer terminates the SSH server process, resulting in a complete Denial of Service.

The vulnerability carries a CVSS base score of 6.5, reflecting a medium-severity threat. The primary security impact is complete loss of Availability for the host application, while Confidentiality and Integrity remain uncompromised.

In real-world environments, this vulnerability is highly critical for multi-user systems. For instance, code hosting platforms like Gitea or enterprise Git-over-SSH servers are exposed to authenticated Denial of Service attacks. A single malicious user account can crash the container or the entire infrastructure hosting the service.

Furthermore, because many container environments use static binaries compiled with Go, updating the system library requires compiling the parent projects from scratch. This introduces significant lag in patching deployment pipelines.

The definitive remediation for CVE-2026-39827 is updating the Go crypto dependency to version 0.52.0 or higher. Developers can upgrade the package by executing the command go get golang.org/x/crypto@v0.52.0 and rebuilding all dependent applications.

For environments where immediate rebuilding is not feasible, security administrators can monitor for signs of active exploitation. Intrusion detection systems should check for an abnormal frequency of SSH_MSG_CHANNEL_OPEN_FAILURE (type 92) messages originating from a single session.

Additionally, host-level metrics should monitor SSH daemon process memory. A linear, continuous rise in RSS memory without a corresponding drop indicates an active leak scenario and should trigger automated session termination or rate limiting.