CVE-2026-39828: Go SSH Server PartialSuccessError Permissions Discard Bypass

The SSH protocol allows for multi-factor and multi-step authentication processes to verify a client's identity before establishing a session. In the Go programming language ecosystem, this protocol state machine is handled by the golang.org/x/crypto/ssh package, specifically within the custom SSH server interfaces. This architecture exposes a significant attack surface in systems that implement customized authentication steps, such as bastion hosts, jumping servers, or complex corporate infrastructure access portals.

The vulnerability is classified under CWE-863 (Incorrect Authorization) and CWE-295 (Improper Certificate Validation). It represents a structural flaw in how authentication state transitions manage session restrictions. Specifically, session constraints such as force-command or IP-source limitations are expressed via the Permissions structure in Go's SSH implementation. When these constraints are generated during intermediate phases of multi-step authentication, they are lost during subsequent authentication iterations.

This security degradation occurs silently, providing no feedback to the server operator or logging mechanisms that restrictions have been completely disabled. Because the final authentication success state is evaluated independently of previous step restrictions, the connection is authorized without the security policies that were bound to the client's initial credentials.

To understand the root cause of this vulnerability, we must examine the internal state machine managed by the serverAuthenticate function in the ssh/server.go file of the golang.org/x/crypto/ssh package. When processing multi-factor authentication, the server framework loops through a series of registered authentication callbacks. If a callback succeeds but requires additional steps, it returns a *PartialSuccessError. This error indicates that the current method is verified, but additional requirements from the PartialSuccessError.Next slice must be fulfilled.

During this iterative evaluation, the permissions variable tracks authorizations and restrictions returned by callbacks (such as VerifiedPublicKeyCallback or PublicKeyCallback). However, in vulnerable versions of the package, this variable is reset, shadowed, or overwritten at the start of each iteration in the authentication loop. When an intermediate authentication callback returned a *PartialSuccessError alongside a populated non-nil *Permissions struct, the Go SSH server failed to persist or merge these credentials into the active loop state.

As a direct result of this state discard, the permissions (including vital certificate extensions and critical restrictions) vanished. When the final factor (such as a TOTP token or a password callback) succeeded, it typically returned nil for permissions, assuming the previously established permissions were still active. The server then completed the handshake with the final nil permissions, granting the client an unconstrained SSH shell.

The critical logic flaw resided within the iterative client authentication handler loop in ssh/server.go. Below is a representation of the vulnerable code path versus the patched logic implemented in Gerrit Change 781621.

// VULNERABLE STATE HANDLING
for {
    // ...
    perms, authErr = authCallback(conn, user, authArgs)
    // ...
    if partialSuccess, ok := authErr.(*PartialSuccessError); ok {
        // BUG: The perms variable is returned by the callback here but is 
        // not preserved or merged for subsequent loop iterations.
        // It is silently dropped on the next loop iteration.
        partialSuccessReturned = true
        // ...
    }
}

The security patch resolves this state mismatch by ensuring that the implementation does not allow ambiguous states where developers attempt to return permissions during intermediate authentication stages. Rather than risking a complex state merge that could introduce further authorization bypass vulnerabilities, the Go security team adopted a fail-closed, strict API check. If any intermediate callback attempts to combine a PartialSuccessError with non-nil Permissions, the connection is immediately terminated with an error:

// PATCHED STATE HANDLING
if partialSuccess, ok := authErr.(*PartialSuccessError); ok {
    // Permissions are not preserved between authentication steps. To
    // avoid confusion about the final state of the connection, we
    // disallow returning non-nil Permissions combined with
    // PartialSuccessError.
    if perms != nil {
        return nil, errors.New("ssh: permissions must be nil when returning PartialSuccessError")
    }
    partialSuccessReturned = true
    // ...
}

This fix is highly complete because it eliminates the structural ambiguity at the API boundary. By throwing an explicit runtime error on misconfiguration, it prevents developers from inadvertently exposing their servers to silent credential degradation.

Exploiting this vulnerability does not require complex cryptographic attacks. It relies entirely on structural path manipulation in custom SSH servers implementing multi-factor authentication. An attacker must possess valid credentials for the initial authentication method (such as an SSH private key matching a signed certificate containing restrictions) and the subsequent factor (such as a password or TOTP code).

To perform the attack, the adversary initiates an SSH connection using their restricted certificate. The custom server callback evaluates the certificate, establishes security permissions (such as force-command="/usr/bin/restricted_shell"), and returns a PartialSuccessError instructing the client to proceed to the next authentication method. Because of the bug, the server discards the force-command constraint. The attacker then provides the required MFA token. The server authenticates the MFA callback, verifies success, and completes the handshake. The attacker is then dropped into a standard interactive shell with unrestricted command execution capabilities, successfully escaping the forced command sandbox.

The impact of CVE-2026-39828 is substantial in enterprise and infrastructure-access contexts. Custom SSH portals, bastion hosts, and network gateways built on top of the Go x/crypto/ssh framework are frequently designed to isolate sensitive environments by mapping strict policies (e.g., preventing port forwarding, or restricting users to narrow administrative commands) directly onto user certificates. Discarding these permissions completely undermines the multi-layered security architecture of these access controls.

While the CVSS v3.1 base score is rated at 6.3 (Medium), the operational impact in customized environments can be critical. The score details point to Network (AV:N) access complexity, Low complexity (AC:L), and Low Privileges (PR:L) since the attacker needs basic credentials. However, because this vulnerability allows the bypass of the security perimeter designed to enforce restricted access control, it effectively transforms a restricted session into an unconstrained session.

Currently, there is no evidence of public exploitation or weaponized proof-of-concept tools. However, because the vulnerability relies entirely on logical code paths rather than memory unsafety, writing an exploit requires minimal effort for an attacker who already possesses initial access.

The definitive remediation for CVE-2026-39828 is to upgrade the golang.org/x/crypto dependency to version v0.52.0 or higher. This upgrade forces the SSH server to abort any connection that returns an invalid combination of a PartialSuccessError and non-nil Permissions, preventing authorization degradation.

If immediate dependency updates are not viable, developers must inspect and modify their SSH server callback implementations. Specifically, ensure that any callback that returns a PartialSuccessError returns a nil pointer for the *Permissions parameter. All session permissions and certificate restrictions must be deferred and returned exclusively during the final, successful authentication callback that finishes the multi-step handshake.

Additionally, automated testing should be incorporated. Implement integrated integration tests that mimic multi-factor authentication sequences to verify that certificate extensions and restrictions are correctly preserved and actively enforced once the SSH session becomes active.