CVE-2026-39834

What it actually does

Applications using the Go SSH implementation in golang.org/x/crypto/ssh can enter an infinite write loop when a single SSH channel Write call is given more than 4 GiB of data. An internal payload-size calculation truncates due to integer overflow, causing the loop to repeatedly send empty SSH packets without advancing the write offset. The practical impact is availability loss through CPU, goroutine, connection, and network resource exhaustion; affected processes may hang, stop servicing legitimate SSH channel traffic, or require restart. Exploitability depends on whether an exposed application allows an unauthenticated or low-friction remote party to cause a single channel write larger than 4 GiB.

Why it matters to the business

A vulnerable SSH-based service, proxy, transfer tool, or automation component can be made to stall or consume resources, interrupting file transfers, remote administration, CI/CD jobs, backups, tunnels, or other workflows that rely on SSH channels. Although public exploitation is not currently reported, the high CVSS score means internet-facing or multi-tenant services using this library should treat remediation as important, especially where large file transfer or tunneling functionality is exposed.

How an attack unfolds

An attacker first identifies a service or client component built with golang.org/x/crypto/ssh that exposes SSH channel functionality, such as file transfer, port forwarding, remote command execution, or custom SSH-based messaging. The attacker then supplies, requests, or induces a data flow that causes the vulnerable application to call Channel.Write with a single buffer larger than 4 GiB. When the write path calculates the payload size, integer truncation causes the loop state to become inconsistent. Instead of progressing through the buffer, the process repeatedly emits empty SSH channel packets and remains stuck. Repeating this against one or more sessions can tie up goroutines, file descriptors, CPU, bandwidth, and application-level workers, resulting in denial of service. No known public exploit or known exploited-in-the-wild status is reported, and the EPSS value is currently low and flat, but exploitability can rise sharply in products that expose large attacker-controlled writes.

How to fix it

Upgrade the affected Go SSH dependency to a version of golang.org/x/crypto/ssh that contains the int64 payload-size calculation fix. Because exact fixed versions were not provided in the input, confirm the corrected version from the upstream golang.org/x/crypto release notes, Go module advisory database, or vendor advisory, then rebuild and redeploy all statically linked Go binaries that include the vulnerable module. If immediate upgrade is not possible, add defensive limits so no untrusted request can cause a single SSH channel Write call larger than 4 GiB, split large writes into bounded chunks well below 4 GiB, enforce per-session data quotas and timeouts, and restrict access to SSH-channel features to trusted users or networks. Restart affected long-running services after patching to clear any stuck goroutines or sessions.

How to confirm the fix worked

Confirm exposure by inventorying Go binaries and source repositories for golang.org/x/crypto/ssh usage and checking the resolved module version with tooling such as `go list -m all`, `go version -m <binary>`, SBOM scanners, or dependency vulnerability scanners. Validate remediation by confirming the deployed binary was rebuilt against a fixed golang.org/x/crypto version and by reviewing the patched code path for int64-based payload-size comparisons. In a controlled test environment only, exercise large-write behavior with chunking and request-size limits enabled to verify the application rejects, streams, or safely segments data above 4 GiB rather than passing it as one Write call. Operationally, verify that no process enters sustained high CPU or long-lived SSH sessions with zero-byte channel traffic during large-transfer tests.

Typical attack path

1. Identify an application, appliance, service, or tool using golang.org/x/crypto/ssh for SSH channel communication.
2. Find functionality that accepts or relays very large attacker-controlled data over an SSH channel, such as upload, download, tunnel, proxy, or command-output forwarding.
3. Establish an SSH channel or trigger the vulnerable component to establish one.
4. Cause the application to perform a single Channel.Write call with more than 4 GiB of data.
5. The vulnerable write loop overflows its internal payload-size calculation and repeatedly sends empty packets without making progress.
6. Keep the session open or repeat the action across sessions to exhaust application resources and disrupt service availability.

How to detect it

Look for evidence of denial-of-service behavior rather than a unique payload signature. Useful sources include application logs from SSH-based services, reverse proxy or load balancer telemetry around large upload/download requests, SSH server/client debug logs, process metrics, goroutine dumps, packet captures, and EDR telemetry showing process resource exhaustion. Investigate long-lived SSH sessions that coincide with very large transfer attempts, high CPU usage, growing goroutine counts, stuck worker pools, repeated zero-length SSH channel data packets, or network traffic that continues without corresponding application-layer progress. For Go services, collect goroutine dumps during suspected incidents and look for many goroutines blocked or looping in golang.org/x/crypto/ssh channel write paths. Review logs for failed or incomplete transfers around the 4 GiB boundary, abrupt restarts, watchdog kills, out-of-memory events, or operator-initiated restarts after service hangs. There are no known public threat actors or KEV exploitation reports for this issue, so detection should focus on behavioral anomalies and correlation with vulnerable dependency exposure.

What your security team should do

• Prioritize inventory of internet-facing, partner-facing, and multi-tenant services that use golang.org/x/crypto/ssh, especially file-transfer, tunneling, bastion, automation, and proxy components.
• Upgrade golang.org/x/crypto/ssh to a fixed upstream release and rebuild all affected Go binaries; static linking means updating the host package alone is usually insufficient.
• Add application-layer guardrails that prevent a single SSH channel Write call from receiving more than 4 GiB of data, even after patching.
• Apply compensating controls where patching is delayed: authentication, network allowlisting, request-size caps, rate limits, idle/write timeouts, and worker/session quotas.
• Monitor for abnormal SSH channel behavior, including long-lived sessions, repeated empty packets, unusually large transfer attempts, goroutine growth, and sustained CPU/network activity without successful throughput.
• Because this issue is not in CISA KEV, has no reported ransomware use, and has a low flat EPSS trend, prioritize based on exposure and whether attackers can influence large SSH writes rather than treating all internal uses equally.