CVE-2026-39831

What it actually does

This is an authorization bypass in Go's SSH/FIDO security-key signature verification logic. For OpenSSH security-key algorithms such as sk-ecdsa-sha2-nistp256@openssh.com and sk-ssh-ed25519@openssh.com, the Verify() method accepted signatures without enforcing the FIDO/U2F User Presence flag. As a result, software using the affected golang.org/x/crypto SSH implementation could treat a hardware-backed SSH authentication as valid even when the security key was not physically touched, weakening a core possession-plus-presence control. The flaw does not by itself expose private key material, but it allows unattended signing if an attacker can access or trigger use of the security key through malware, a compromised host, a forwarding agent, a remote signing workflow, or another path to the authenticator.

Why it matters to the business

Organizations that rely on FIDO/U2F-backed SSH keys for administrator or developer access may have a false sense of protection: accounts can potentially be used without the expected human touch confirmation. The operational consequence is increased risk of unauthorized SSH access to servers, build systems, source-code infrastructure, deployment tooling, and other systems protected by Go-based SSH implementations. The CVSS score is high, but current public exploit maturity and EPSS are low, it is not listed in CISA KEV, and no ransomware use is indicated; prioritization should focus on internet-accessible, privileged, or automation-sensitive services that use Go's crypto SSH library and accept security-key authentication.

How an attack unfolds

An attacker first needs a way to cause a valid security-key signature to be produced without the legitimate user's physical interaction. Common prerequisites could include malware on a workstation with an inserted hardware key, access to an SSH agent or forwarding path, compromise of software that brokers security-key operations, or another unattended signing mechanism. The attacker then initiates SSH public-key authentication against a service implemented with the affected Go crypto SSH verification logic, presenting a signature for one of the OpenSSH security-key algorithms. Because the vulnerable Verify() path does not require the User Presence flag, the server accepts the signature as if the key had been touched. If the corresponding public key is authorized for the account, authentication succeeds without the intended physical confirmation step. The attacker can then operate with the permissions of that account. No named threat actors or public exploitation campaigns are currently indicated in the provided data.

How to fix it

Upgrade golang.org/x/crypto and rebuild all affected applications as soon as a patched version is available from the Go project or your software vendor. No exact fixed version was provided in the input, so teams should track upstream Go security advisories and vendor release notes for the first version that restores User Presence enforcement for SSH security-key verification. After upgrading libraries, redeploy binaries; Go applications statically link dependencies, so updating a module cache alone is not sufficient. If immediate patching is not possible, consider temporarily disabling FIDO/U2F SSH security-key algorithms in affected Go-based SSH servers, limiting access to trusted networks or VPNs, enforcing additional MFA or bastion controls outside the affected SSH verification path, and reviewing whether any application intentionally permits no-touch behavior. Where no-touch behavior is intentionally required, implement it explicitly and narrowly according to the corrected API behavior, including the no-touch-required extension in Permissions.Extensions only for authorized keys and accounts where unattended signing is acceptable.

How to confirm the fix worked

Confirm exposure by identifying Go applications that import or vendor golang.org/x/crypto/ssh and accept SSH public-key authentication using sk-ecdsa-sha2-nistp256@openssh.com or sk-ssh-ed25519@openssh.com. Validate remediation by confirming the rebuilt binary uses a patched golang.org/x/crypto version once available, not just an updated source tree. Functional testing should include an authentication attempt using a security-key signature that lacks the User Presence flag: patched software should reject it unless the application explicitly authorizes no-touch behavior through the corrected no-touch-required permission extension. Also verify that legitimate touch-required security-key logins still succeed after a physical touch and that any intentionally no-touch accounts are documented, minimized, and monitored.

Typical attack path

1. Identify a Go-based SSH service or application that uses golang.org/x/crypto SSH verification and permits FIDO/U2F security-key authentication.
2. Obtain a way to trigger or relay signing operations for an authorized security key without the owner's physical touch, such as through malware, agent misuse, or an unattended key path.
3. Start an SSH public-key authentication attempt using sk-ecdsa-sha2-nistp256@openssh.com or sk-ssh-ed25519@openssh.com.
4. Submit a valid signature where the FIDO/U2F User Presence flag is not set.
5. Rely on the vulnerable verification logic to accept the signature despite the missing touch confirmation.
6. Gain access as the authorized user and perform actions permitted to that account.

How to detect it

Post-exploitation detection is difficult because the vulnerable server may log a successful public-key login but not whether the FIDO/U2F User Presence flag was set. Security teams should review SSH authentication logs from Go-based SSH services for successful logins using sk-ecdsa-sha2-nistp256@openssh.com or sk-ssh-ed25519@openssh.com, especially to privileged accounts, from new IP addresses, unusual geographies, unexpected automation hosts, or outside the user's normal activity window. Correlate these events with endpoint telemetry from the user's workstation: look for inserted security keys being accessed while the user was absent, suspicious processes interacting with SSH agents or security-key middleware, unexpected ssh-agent forwarding, remote desktop activity, malware alerts, or command execution immediately before the login. Application logs may need to be increased or customized because many SSH implementations do not record the key algorithm or FIDO flags by default. Also inspect source code and configuration for explicit use of no-touch-required behavior, as this may distinguish intended unattended authentication from suspicious use.

• sk-ecdsa-sha2-nistp256@openssh.com
• sk-ssh-ed25519@openssh.com
• no-touch-required
• golang.org/x/crypto/ssh
• Accepted publickey

What your security team should do

• Inventory Go-based SSH servers, bastions, embedded SSH services, CI/CD tooling, administrative appliances, and internal developer tools that use golang.org/x/crypto/ssh.
• Prioritize systems where FIDO/U2F SSH keys protect privileged, production, source-code, or deployment access.
• Track the upstream Go/x/crypto advisory and upgrade to the first patched version as soon as it is released, then rebuild and redeploy all dependent binaries.
• Until patched, disable or restrict sk-ecdsa-sha2-nistp256@openssh.com and sk-ssh-ed25519@openssh.com authentication where feasible, especially on externally reachable services.
• Review authorized SSH keys and application logic for any intentional no-touch-required behavior; remove it unless there is a documented operational need.
• Increase monitoring for unusual public-key SSH logins using security-key algorithms, especially outside normal user hours, from new source addresses, or into privileged accounts.
• Investigate endpoints that hold or access hardware security keys for malware, unauthorized SSH agent forwarding, or unattended signing services.
• Document compensating controls and residual risk for services that cannot be rapidly rebuilt because Go applications commonly bundle vulnerable library code into static binaries.