CVE-2026-39827

What it actually does

This is a denial-of-service flaw in SSH servers built with the affected Go crypto SSH implementation. An authenticated SSH client can repeatedly request new channels that the server rejects; due to improper cleanup, those rejected channels remain in the connection’s internal state instead of being released for garbage collection. Over time, memory usage grows without bound until the SSH server process becomes unstable or crashes, terminating active sessions and preventing new users from connecting.

Why it matters to the business

A low-privileged authenticated user or compromised SSH account can cause an outage of services that rely on the affected SSH server implementation. The main risk is availability loss: disconnected administrators, failed automation, interrupted file transfers, failed remote job execution, or degraded operations for systems using Go-based SSH services. EPSS is currently low, there is no known KEV listing, no ransomware association, and no public exploit maturity reported, but the attack is simple once an attacker has valid SSH credentials.

How an attack unfolds

An attacker first obtains valid SSH credentials for a service using the vulnerable Go SSH server implementation. After authenticating, the attacker repeatedly sends SSH channel-open requests for channel types or actions that the server rejects. Each rejected channel should be removed from the connection’s state, but vulnerable versions retain internal references, causing memory to accumulate. The attacker continues this loop until the process consumes excessive memory, is killed by the operating system, crashes, or becomes unresponsive. Because the issue affects the server process, all users connected to that process may be disconnected and new connections may fail until the service is restarted or otherwise recovered.

How to fix it

Upgrade the affected Go crypto SSH dependency to a version that contains the fix once available from the upstream package or vendor, then rebuild and redeploy all applications that statically include the vulnerable library. Because Go dependencies are commonly compiled into application binaries, updating the module alone is not sufficient; every affected binary must be rebuilt and replaced. If an immediate upgrade is not possible, reduce exposure by limiting SSH access to trusted networks, enforcing strong authentication and account hygiene, disabling unnecessary SSH functionality, applying per-user and per-connection resource limits where supported, setting process memory limits, rate-limiting repeated failed channel opens if the application exposes such controls, and monitoring for abnormal memory growth. Restarting the service may temporarily recover availability but does not fix the underlying issue.

How to confirm the fix worked

Confirm that all deployed SSH server binaries are built with a fixed version of the Go crypto SSH dependency once a fixed version is available. Review dependency manifests, SBOMs, build metadata, and module lock files for golang.org/x/crypto or equivalent vendored copies, then verify that running binaries were rebuilt after the dependency update. Test by authenticating to a non-production instance and repeatedly attempting rejected channel opens while monitoring process memory; fixed versions should release rejected channel state and show stable memory usage. Also confirm operational controls such as network restrictions, memory limits, and alerting on abnormal SSH process memory growth are in place.

Typical attack path

1. Identify an exposed SSH service implemented with the affected Go crypto SSH library.
2. Authenticate using valid credentials, a compromised account, or another low-privileged SSH identity.
3. Repeatedly request SSH channels that the server rejects.
4. Maintain the loop to force accumulation of unreleased channel state in server memory.
5. Cause the SSH server process to consume excessive memory, crash, or be killed by the operating system.
6. Disrupt active sessions and prevent reliable access until the service is restarted and remediated.

How to detect it

To assess prior exploitation, examine SSH service logs, application logs, authentication logs, process supervision logs, kernel logs, and memory telemetry. Look for a pattern where a successfully authenticated SSH user or source IP is followed by a high volume of rejected channel-open attempts, rising memory consumption for the SSH server process, degraded responsiveness, abrupt disconnects, process restarts, out-of-memory kills, or crash messages. Correlate timestamps across authentication events, channel rejection messages, memory alerts, container or system OOM events, and service restart records. Because this flaw can be exploited using protocol-compliant authenticated SSH traffic, network indicators may be limited; focus on authenticated session behavior and resource exhaustion artifacts rather than payload signatures.

• fatal error: runtime: out of memory
• runtime: out of memory
• signal: killed
• Out of memory: Killed process
• Killed process
• oom-kill
• OOMKilled
• SSH_MSG_CHANNEL_OPEN
• channel open failed
• open failed
• administratively prohibited
• resource shortage
• connection reset by peer
• broken pipe

What your security team should do

• Inventory Go-based SSH servers and applications that include the affected Go crypto SSH implementation, including statically linked binaries and vendored dependencies.
• Prioritize remediation for internet-facing SSH services, bastion-like services, automation endpoints, file-transfer services, and systems where SSH availability is operationally critical.
• Upgrade to a fixed upstream or vendor-provided version as soon as available, then rebuild and redeploy all affected binaries.
• Until patched, restrict SSH access to trusted source networks and remove unused or stale SSH accounts and keys.
• Add monitoring for sustained memory growth, repeated rejected channel activity, abnormal disconnects, and SSH service crashes.
• Review logs for authenticated accounts or source IPs that generated large numbers of rejected channel-open attempts before process instability.
• Prepare a recovery runbook for safe SSH service restart while ensuring restart is treated only as temporary mitigation, not remediation.