The One Guarantee Hardware Keys Make
FIDO/U2F hardware security keys exist for a single, non-negotiable reason: they require physical human touch to sign an authentication challenge. You press the button. The key signs. No press, no signature. Every security model built on hardware keys — from SSH access to production servers to zero-trust enterprise gates — depends on this one property holding.
CVE-2026-39831 broke that guarantee in Go’s widely used SSH library. The Verify() method for FIDO/U2F key types ([email protected] and [email protected]) in golang.org/x/crypto/ssh never inspected the User Presence flag in incoming signatures. A signature generated without physical touch was accepted as valid.
How the Bypass Works
The FIDO/U2F protocol embeds a User Presence (UP) flag in every signature. When a hardware key signs with the button pressed, UP is set to true. When the signing happens without touch — which some tokens permit through their low-level API — UP is false. The SSH server receiving the signature is supposed to reject any authentication attempt where UP is false. Go’s implementation never checked.
An attacker who has achieved logical access to a user’s environment — through a compromised SSH agent, a forwarded socket, or malware on the workstation — can interact with the hardware token’s interface to request a signature with user presence set to false. Because the Go SSH library accepted this signature without inspecting the flag, the connection was authorized silently, with no physical interaction from the legitimate user.
Why This Matters Beyond Go
Go is the implementation language for a significant share of cloud infrastructure: Kubernetes, Docker, Terraform, Vault, Consul, and dozens of service meshes and orchestration tools. Many of these use golang.org/x/crypto/ssh for internal communication, bastion host access, or automated deployment. The module is not a niche library — it underpins production SSH connections across the industry.
Organizations that upgraded their authentication from password-based or certificate-based SSH to FIDO hardware keys did so specifically to prevent the scenario this vulnerability enables: unattended, software-only authentication. The upgrade was supposed to add a physical verification layer. CVE-2026-39831 meant that layer was cosmetic — present in the protocol specification, absent in the code that enforced it.
The Fix and Its Deliberate Breaking Change
The patch in v0.52.0, contributed after discovery by NCC Group Cryptography Services (sponsored by Teleport), introduces a deliberate breaking change. Go SSH servers must now explicitly return a "no-touch-required" extension in Permissions.Extensions from their PublicKeyCallback to opt into the previous behavior. The default flips to enforcing the User Presence check — meaning existing deployments that upgrade will reject touchless signatures unless they explicitly opt out.
This is the correct design: secure by default, with an explicit escape hatch for deployments that have a legitimate reason to accept unattended hardware key signatures. But it also means that any Go SSH server upgrading to v0.52.0 without adjusting its callback may break automated workflows that were unknowingly relying on the missing check.
What This Means for Security Teams
If your infrastructure runs Go-based SSH servers or uses FIDO hardware keys for SSH authentication through Go libraries, verify that you are running golang.org/x/crypto v0.52.0 or later. If you upgraded to hardware keys as a security hardening measure, this vulnerability means the hardening was not enforced at the protocol level until the patch. Audit logs from the vulnerable period cannot distinguish between legitimate (touched) and illegitimate (untouched) authentications — both looked identical to the server.
