Go x/crypto ssh/agent: destination restrictions silently dropped when adding keys to a remote agent

Impact

When the client added a key to a remote agent, constraint extensions such as restrict-destination-v00@openssh.com were not serialized into the request. The key arrived unrestricted while the operator believed it was pinned to a single destination — a silent failure, with no error to notice. This matters wherever Go-based tooling forwards operator keys through a bastion into a fleet: a compromised or multi-tenant jump host can reuse the forwarded key against any host it can reach, not just the one it was meant for. The in-memory keyring from NewKeyring() had the mirror-image problem, silently ignoring unsupported constraint extensions; it now rejects them. Only deployments that actually rely on destination restrictions are worse off than they knew.

Who can reach it

Whoever controls the host holding the forwarded agent connection, or anyone who can reach that agent socket on it. The victim is the operator forwarding a key they believed was restricted.

What to do

Rebuild and redeploy every Go binary that vendors golang.org/x/crypto with the fixed module version; see the Go vulnerability entry GO-2026-5006 for the exact version. Red Hat ships affected builds in RHEL 8, 9, and 10 — take the vendor errata for those. Practically this is a package update and a restart of the affected service, not node maintenance. Until rebuilt, treat forwarded agent keys as unrestricted and avoid forwarding to hosts you do not fully trust.

References