CVE-2026-39832

What it actually does

The flaw is in Go's golang.org/x/crypto SSH agent/keyring handling. When a key with constraint extensions such as restrict-destination-v00@openssh.com is added to a remote or forwarded agent, those extensions are not serialized into the agent request. As a result, destination restrictions that should limit where the private key may be used are silently dropped, and the key can be used from the remote host without the intended destination constraint. The patch changes the client to serialize all constraint extensions and changes the in-memory keyring created by NewKeyring() to reject unsupported constraint extensions instead of silently ignoring them. The practical technical impact is loss of key-use policy enforcement for forwarded SSH credentials, enabling unauthorized authentication to systems that the key was supposed to be prevented from reaching.

Why it matters to the business

Organizations that rely on SSH agent forwarding with destination-restricted keys could have a false sense of protection: a key believed to be limited to approved destinations may be usable more broadly from a remote host. If that remote host is malicious or compromised, attackers may be able to pivot to source-code repositories, production servers, administrative jump paths, or other SSH-accessible systems using the victim's forwarded credential. The CVSS score is critical/high at 9.1, but current exploitation signals are low: EPSS is 0.006, unchanged over 30 days, there is no known CISA KEV listing, no reported ransomware use, and no public exploit maturity indicated. Even so, the issue should be prioritized anywhere SSH agent forwarding and Go-based SSH tooling are used in administrative or developer workflows.

How an attack unfolds

An attacker first needs access to a remote host where a user or automation connects with SSH agent forwarding, or control over software that interacts with a forwarded agent implemented with the vulnerable Go crypto SSH agent behavior. The user adds or forwards a key that was intended to be protected by destination restrictions. Because the vulnerable implementation does not serialize the constraint extension in the add-key request, the remote-side agent receives or stores the key without the restriction. The attacker can then request signatures from the forwarded agent and use the key to authenticate to SSH destinations that should have been blocked by the original constraint. This can enable lateral movement, access to repositories or infrastructure, and actions under the identity associated with the SSH key. The attack is largely silent because the vulnerable behavior strips or ignores constraints rather than failing closed.

How to fix it

Upgrade golang.org/x/crypto to a patched release that includes the fix for SSH agent constraint-extension serialization and NewKeyring() rejection of unsupported constraints. No exact fixed version was provided in the input, so engineering teams should consult the official golang.org/x/crypto advisory, Go module release notes, and dependency scanner output for the first non-vulnerable module version. After upgrading the module, rebuild and redeploy all affected binaries, containers, developer tools, CI/CD utilities, SSH automation, bastion tooling, and products that statically vendor golang.org/x/crypto. If immediate upgrade is not possible, reduce exposure by disabling SSH agent forwarding to untrusted or shared hosts, avoiding destination-restricted-key workflows that depend on vulnerable Go-based agents, using short-lived credentials, isolating administrative SSH keys, and enforcing server-side authorization controls so that possession of a forwarded key alone is not sufficient for broad access.

How to confirm the fix worked

Confirm exposure by inventorying applications and binaries for golang.org/x/crypto usage, including vendored and statically compiled Go binaries. For source projects, review go.mod and go.sum for golang.org/x/crypto and use dependency scanning to determine whether the resolved version contains the fix. For compiled binaries, use Go build metadata where available, for example by inspecting module metadata with tooling such as go version -m. Validate remediation by rebuilding with the patched module and running functional tests that add or forward a key using a constraint extension such as restrict-destination-v00@openssh.com; the extension should be preserved and enforced, and unsupported constraint extensions should be rejected rather than silently ignored. Also verify operationally that SSH agent forwarding is disabled or restricted where it is not explicitly required.

Typical attack path

1. Identify an environment where Go-based SSH tooling or agent/keyring code from golang.org/x/crypto is used with SSH agent forwarding or remote agent operations.
2. Gain access to, compromise, or operate a remote host that users connect to with a forwarded SSH agent.
3. Wait for or induce a user or automation account to forward a destination-restricted SSH key through the vulnerable agent path.
4. Abuse the bug where constraint extensions such as restrict-destination-v00@openssh.com are omitted or ignored, leaving the forwarded key effectively unrestricted on the remote host.
5. Use the forwarded agent to request SSH signatures for connections to systems beyond the originally allowed destination set.
6. Authenticate as the key owner to additional SSH services, then access data, modify systems, or continue lateral movement.

How to detect it

There are no reliable exploit-specific indicators for this issue because exploitation abuses normal SSH agent signing behavior and the vulnerable library silently strips or ignores constraints rather than producing a distinctive error. Detection should focus on behavioral evidence of misuse of forwarded SSH credentials. Review SSH server authentication logs across bastions, internal servers, source-code platforms, and administrative endpoints for successful public-key logins from hosts that should not have been allowed by destination restrictions. Correlate those logins with sessions where SSH agent forwarding was enabled and with user activity on remote hosts. Look for chains where a user authenticates to one host and, shortly afterward, that host initiates SSH authentications as the same user to additional destinations. On endpoints, review shell history, process accounting, EDR telemetry, and audit logs for unexpected ssh or scp processes using a forwarded agent socket. On Unix-like systems, inspect session environments and process metadata for SSH_AUTH_SOCK exposure on shared or compromised hosts. For Go applications, review application logs for agent-add, keyring, or SSH-agent operations around the time of suspicious lateral movement, although the vulnerability itself may not log failures. Because EPSS is currently low and there is no KEV listing or known ransomware use, broad compromise is not indicated by public signals, but environments with heavy agent-forwarding use should still perform targeted hunts.

What your security team should do

• Prioritize upgrading golang.org/x/crypto in all Go-based SSH tooling, bastion software, developer utilities, automation agents, and products that implement SSH agent forwarding or in-memory keyrings.
• Perform a dependency inventory for both source repositories and deployed Go binaries, because Go applications commonly statically compile vulnerable libraries into standalone executables.
• Temporarily restrict or disable SSH agent forwarding to untrusted, shared, internet-facing, or lower-trust hosts until affected tooling is confirmed patched.
• Review SSH access controls for keys that rely on destination restrictions, and assume those restrictions may not have been enforced when used through vulnerable Go-based agent paths.
• Hunt for unusual SSH authentication patterns from bastion hosts, developer workstations, build systems, and other machines where forwarded agents are commonly present.
• Rotate or reissue high-privilege SSH keys if logs indicate unexpected use from remote hosts, use outside approved destinations, or activity during sessions where vulnerable forwarding was active.
• Educate administrators and developers that destination-constrained SSH keys are not a substitute for avoiding agent forwarding to untrusted hosts.
• Track vendor advisories and package manager updates because no fixed version was supplied in the input, and ensure downstream products that embed golang.org/x/crypto are rebuilt rather than only updating source dependencies.