CVE-2026-39828

What it actually does

This is an authorization bypass in SSH servers built with the affected golang.org/x/crypto/ssh implementation. If an authentication callback returns PartialSuccessError together with non-nil Permissions, the server can silently discard those permissions when a later authentication factor succeeds. In deployments that use multi-factor SSH authentication, SSH certificates, or callback-populated restrictions, this can remove controls such as forced commands, certificate extensions, source restrictions, or other session limitations after the user completes the second factor. Exploitation requires a legitimate authentication path to reach partial success, so this is not unauthenticated remote code execution, but it can turn a restricted SSH session into a less-restricted one.

Why it matters to the business

Organizations using Go-based SSH servers or products that embed golang.org/x/crypto/ssh may unintentionally grant broader access than intended to users or automation identities that were supposed to be tightly constrained. The main operational risk is that a restricted account, certificate, or MFA flow could be used to run unexpected commands, access data, or interact with systems outside the intended workflow. The CVSS score is moderate, EPSS is currently low and flat, and it is not listed in CISA KEV, but the impact can be significant for bastions, Git/CI systems, managed file transfer services, appliance management interfaces, or internal platforms that rely on SSH certificate restrictions for containment.

How an attack unfolds

An attacker first obtains or already possesses credentials, an SSH certificate, or another authentication factor that is valid only for a restricted workflow. They connect to a vulnerable Go-based SSH server where the first authentication step returns PartialSuccessError and includes Permissions containing restrictions such as force-command. Because the vulnerable implementation discards those permissions, the attacker then completes the remaining authentication step, such as a password, keyboard-interactive challenge, or second factor. The server accepts the login but no longer enforces the permissions from the earlier step. The attacker can then request an interactive shell, run a different command than the forced command, or attempt other SSH session actions that should have been blocked by the original certificate or authorization policy.

How to fix it

Upgrade the golang.org/x/crypto/ssh dependency to a release that contains the fix, then rebuild and redeploy all affected Go binaries because Go applications commonly statically link dependencies. No exact fixed package version was provided in the input, so engineering teams should check the upstream golang.org/x/crypto security advisory, module changelog, and product vendor advisories for the fixed version and pin to that version or later. In parallel, audit SSH server authentication callbacks for any flow that returns PartialSuccessError with non-nil Permissions. Ensure permissions from earlier authentication steps are preserved until final authentication succeeds, or fail closed when partial-success permissions are present. Review uses of SSH certificate restrictions such as force-command, source-address, critical options, extensions, and custom Permissions. Where immediate patching is not possible, reduce exposure by limiting network access to the SSH service, disabling affected multi-factor or partial-success flows if feasible, enforcing restrictions outside the vulnerable callback path, and monitoring for unexpected interactive SSH sessions from restricted identities.

How to confirm the fix worked

Confirm remediation by inventorying Go binaries and dependency manifests for golang.org/x/crypto/ssh and verifying they are built with a fixed golang.org/x/crypto version. Use `go version -m <binary>` where available to inspect embedded module versions in compiled Go binaries. Functionally test the affected authorization path by creating or using an SSH identity that is allowed only through a restricted certificate or callback-provided permission, such as a forced command, and then authenticate through the same multi-factor sequence. A fixed server should either reject an invalid PartialSuccessError-with-Permissions flow or continue to enforce the original restrictions after the second factor succeeds. Attempt to request an interactive shell or a command other than the forced command; success indicates continued exposure. Also review CI/CD artifacts, containers, appliances, and downstream products that vendor or statically link golang.org/x/crypto.

Typical attack path

1. Identify a Go-based SSH service or product using the affected golang.org/x/crypto/ssh server implementation.
2. Obtain valid low-privilege, restricted, or certificate-based SSH access that triggers partial authentication success before a second factor is completed.
3. Authenticate using the first factor so the server returns PartialSuccessError with intended Permissions.
4. Complete the remaining authentication factor successfully.
5. Request a shell, command execution, subsystem, port forwarding, or other SSH session capability that should have been restricted.
6. Use the over-broad session to access data, run unauthorized commands, pivot internally, or modify service state within the account’s operating-system privileges.

How to detect it

Post-exploitation detection is behavioral because successful abuse looks like a valid SSH login followed by unauthorized session activity. Collect logs from the Go-based SSH application, SSH authentication/audit logs, command execution logs, MFA logs, certificate authority logs, EDR telemetry, shell history, process creation telemetry, and network flow logs. Focus on identities or SSH certificate key IDs that are supposed to be restricted to a forced command or automation workflow but then request an interactive shell, allocate a TTY, execute different commands, start subsystems, or use port forwarding. Correlate authentication sequences showing partial success followed by second-factor success with subsequent session activity that does not match the expected Permissions. Hunt for unexpected child processes spawned by the SSH service account, anomalous use of shells, scp/sftp where not expected, and deviations from known automation command lines. If threat actors are not known for this issue and no public exploit maturity is reported, prioritize detection around business-critical SSH services and high-value restricted identities rather than broad IOC matching.

• PartialSuccessError
• partial success
• force-command
• SSH_ORIGINAL_COMMAND
• pty-req
• shell request
• exec request
• subsystem request
• direct-tcpip
• tcpip-forward
• keyboard-interactive
• publickey partial success
• session opened for restricted user
• interactive shell for restricted account
• golang.org/x/crypto/ssh

What your security team should do

• Prioritize inventory of Go-based SSH servers, bastions, appliances, developer platforms, CI/CD systems, Git services, and internal tools that embed golang.org/x/crypto/ssh.
• Ask product owners and vendors whether their SSH authentication callbacks use PartialSuccessError, multi-factor authentication, SSH certificates, or callback-supplied Permissions.
• Upgrade golang.org/x/crypto to the fixed upstream version as soon as confirmed, then rebuild and redeploy all dependent binaries and containers.
• Perform targeted functional testing for bypass of force-command and other certificate restrictions after multi-factor authentication.
• Restrict network access to affected SSH services until patched, especially where restricted SSH identities protect sensitive administrative or automation workflows.
• Review recent SSH activity from restricted or certificate-based accounts for interactive shells, unexpected commands, subsystem requests, or port-forwarding attempts.
• Add detection rules for restricted identities performing actions outside their expected command set or session type.
• Because EPSS is low, exploit maturity is reported as none, and the issue is not in KEV, treat this as priority based on exposure and reliance on SSH restrictions rather than as an internet-wide emergency.