CVE-2026-39830

What it actually does

Applications using the Go SSH implementation in golang.org/x/crypto/ssh can be forced into a per-connection resource leak by a malicious SSH peer. The peer sends unsolicited global request response messages that are not expected by the local side; these responses fill an internal buffer and block the SSH connection read loop. Once blocked, the goroutine handling the connection may not be released even when Close() is called, causing goroutines, memory, file descriptors, and connection-related state to accumulate. The primary impact is denial of service through resource exhaustion. Although the assigned score indicates potential confidentiality impact, the described vulnerability is most directly a network-reachable availability issue in SSH clients, servers, proxies, bastions, automation systems, or embedded services built with the affected Go crypto SSH package.

Why it matters to the business

A remote party that can establish or interact with SSH sessions to software built on the affected Go package could gradually exhaust service resources, causing SSH-dependent applications to slow down, stop accepting connections, crash, or require restarts. This can disrupt administrative access, file transfer, automation, CI/CD workflows, remote management, and SSH gateway services. The issue is not currently listed in CISA KEV, has no known public exploit maturity in the provided data, and has a low, flat EPSS score, but the vulnerability is unauthenticated, network-reachable, and high severity, so internet-facing or high-volume SSH services should still be prioritized.

How an attack unfolds

An attacker positions as an SSH peer to an affected application. This may mean connecting to an SSH server implemented with golang.org/x/crypto/ssh, or operating a malicious SSH server that an affected Go-based client connects to. After the SSH transport is established, the attacker sends unsolicited global request response packets, such as success or failure responses that do not correspond to a legitimate outstanding global request. In vulnerable versions, these unexpected responses are queued into an internal response buffer instead of being discarded. By repeatedly sending them, the attacker fills the buffer and causes the connection read loop goroutine to block. Because the blocked goroutine cannot be reliably released through Close(), each malicious connection can leave behind unreclaimed resources. Repeating the pattern across many connections, or sustaining it over time, can exhaust memory, goroutine capacity, file descriptors, or connection limits and degrade or deny service.

How to fix it

Upgrade golang.org/x/crypto/ssh to a version that discards unsolicited global request responses. No exact fixed version was provided in the input, so engineering teams should consult the upstream Go x/crypto advisory and pin to the first patched release or later once identified. Rebuild and redeploy all statically linked Go binaries that vendor or compile this dependency, because updating a shared package alone will not patch already-built executables. If immediate upgrading is not possible, reduce exposure by limiting inbound SSH access to trusted networks, enforcing connection limits and rate limits, using aggressive idle/session timeouts, isolating SSH-facing components, monitoring goroutine and memory growth, and restarting affected services on abnormal resource accumulation. For client-side use cases, restrict which SSH servers clients are allowed to connect to and avoid connecting automation or agents to untrusted SSH endpoints.

How to confirm the fix worked

Confirm exposure by inventorying Go applications that import golang.org/x/crypto/ssh directly or transitively. Review go.mod, go.sum, vendored modules, SBOMs, and build manifests for golang.org/x/crypto and determine whether the version is patched according to the upstream advisory. Because Go binaries are commonly statically linked, validate the deployed binary build version, not only the source repository. After patching, run dependency scanning again and verify the binary was rebuilt and redeployed. Functional validation should include regression testing with an SSH peer that sends unsolicited global request success/failure responses and confirming the connection discards them without blocking goroutines or leaking resources. Operational validation should confirm that goroutine count, memory, file descriptors, and active connection counts remain stable during malformed SSH traffic tests.

Typical attack path

1. Identify an application, service, agent, proxy, or automation component that uses golang.org/x/crypto/ssh and accepts or initiates SSH connections.
2. Establish an SSH session as an unauthenticated or minimally interactive peer, depending on the application’s SSH role and configuration.
3. Send unsolicited SSH global request response messages that are not tied to any legitimate outstanding global request.
4. Repeat the unexpected responses until the implementation’s internal response buffer fills.
5. Cause the connection read loop goroutine to block and remain unreleased even if the application attempts to close the connection.
6. Open additional sessions or repeat the behavior to accumulate leaked goroutines and associated resources.
7. Trigger service degradation, connection handling failures, crashes, or operational outages due to resource exhaustion.

How to detect it

Look for evidence of resource-exhaustion behavior rather than a single definitive exploit artifact. Useful sources include application logs, SSH service logs, reverse proxy or firewall connection logs, endpoint telemetry, Go runtime metrics, pprof goroutine dumps, container metrics, systemd/journald logs, and cloud load balancer flow logs. Investigate spikes in SSH connections followed by rising goroutine counts, heap memory, file descriptor use, or connection counts that do not fall after sessions close. In server-side scenarios, correlate repeated SSH connections from the same source IPs or networks with degraded service health, timeouts, or restarts. In client-side scenarios, identify outbound connections to unfamiliar or newly introduced SSH servers followed by stuck processes or resource growth. If pprof or goroutine dumps are available, search for large numbers of goroutines blocked in golang.org/x/crypto/ssh connection or mux read-loop code. Packet-level detection is difficult after SSH encryption is established, so network IDS generally cannot inspect the unsolicited global response messages unless visibility exists inside the SSH implementation or test harness. There are no known threat actors, ransomware campaigns, or public exploit artifacts provided for this vulnerability.

• golang.org/x/crypto/ssh
• SSH_MSG_REQUEST_SUCCESS
• SSH_MSG_REQUEST_FAILURE
• unsolicited global request response
• unsolicited global responses
• global request response
• resource leak per connection
• blocked goroutine
• goroutine dump
• pprof/goroutine
• golang.org/x/crypto/ssh.(*mux).loop
• golang.org/x/crypto/ssh.(*connection).Close

What your security team should do

• Inventory all products, services, agents, CLIs, bastions, gateways, automation tools, and embedded components built in Go that use golang.org/x/crypto/ssh.
• Prioritize internet-facing SSH services, SSH proxies, bastion-like systems, file-transfer services, and automation clients that connect to untrusted SSH servers.
• Track the upstream golang.org/x/crypto fixed release and upgrade to the patched version as soon as available; rebuild and redeploy all affected Go binaries.
• Apply compensating controls immediately for exposed services: network allowlisting, connection throttling, per-IP limits, idle timeouts, resource limits, and service-level restart safeguards.
• Add monitoring for abnormal increases in goroutine count, heap usage, open file descriptors, stuck SSH sessions, and connection handling errors.
• Review logs and telemetry for repeated short-lived or stalled SSH sessions from the same source, especially where resource usage rises without corresponding authenticated activity.
• Because this is not currently KEV-listed and EPSS is low and flat, balance urgency against exposure, but do not defer patching for externally reachable or mission-critical SSH components.