CVE-2026-39832: Invoking agent constraints dropped when forwarding keys in golang.org/x/crypto/ssh/agent
When adding a key to a remote agent constraint extensions such as restrict-destination-v00@openssh.com were not serialized in the request. Destination restrictions were silently stripped when forwarding keys, allowing unrestricted use of the key on the remote host. The client now serializes all constraint extensions. Additionally, the in-memory keyring returned by NewKeyring() now rejects keys with unsupported constraint extensions instead of silently ignoring them.
Security readout for executives and security teams
Plain-English summary
A flaw in the Go SSH agent library let key restrictions quietly disappear when a user forwarded an SSH key to a remote agent. Executives should read this as: security limits your teams thought they had placed on SSH keys may not have been enforced, letting a key be used more broadly than intended if a remote host was compromised.
Executive priority
Treat as a high-priority patch cycle item, not an emergency. Business impact is scoped to SSH key trust boundaries in Go-based automation and Red Hat platforms; schedule remediation in the next standard maintenance window and rotate any keys that relied on destination restrictions for compensating control.
Technical view
In golang.org/x/crypto/ssh/agent, the client did not serialize constraint extensions such as restrict-destination-v00@openssh.com when adding a key to a remote agent. Destination restrictions were silently stripped during key forwarding, allowing unrestricted use on the remote host. The fix serializes all constraint extensions, and NewKeyring() now rejects keys with unsupported constraint extensions instead of ignoring them.
Likely exposure
Any Go-based tooling that uses golang.org/x/crypto/ssh/agent to forward or add keys to a remote SSH agent, especially bastion, CI, and developer workflows that rely on destination-restricted keys. Environments not using agent forwarding or constraint extensions are effectively unexposed. Red Hat has shipped multiple RHSA advisories, indicating downstream Go and OpenShift components are affected.
Exploitation context
Not listed in CISA KEV, and no public reports of active exploitation are cited in the bundle. CVSS 9.1 (AV:N/AC:L/PR:N/UI:N/C:H/I:H) reflects worst-case misuse: if an attacker controls a remote host that receives a forwarded, supposedly-restricted key, they could reuse it against unintended destinations because the restriction was never transmitted.
Researcher notes
CWE-281 (improper preservation of permissions) fits: constraint extensions were dropped during serialization in ssh/agent client code. Fix is in Go change list CL 778642 and tracked as GO-2026-5006. Note the secondary hardening in NewKeyring(), which now fails closed on unsupported constraint extensions instead of accepting keys under weaker-than-expected restrictions. No KEV entry as of the 2026-07-10 update.
Mitigation direction
Upgrade golang.org/x/crypto to the fixed version referenced by GO-2026-5006 and rebuild affected Go binaries.
Apply Red Hat RHSA-2026:36199, 36796, 37072, and related errata to impacted RHEL and OpenShift systems.
Inventory internal Go tools that call ssh/agent.Add or forward keys and prioritize their rebuilds.
Temporarily avoid forwarding destination-restricted SSH keys through untrusted hosts until libraries are patched.
Rotate SSH keys previously forwarded with assumed destination restrictions to remove residual trust.
Validation and detection
Run govulncheck against Go binaries and services to confirm GO-2026-5006 is no longer reported.
Query SBOMs and go.mod files for golang.org/x/crypto versions below the fixed release.
On RHEL/OpenShift hosts, verify installed package versions match the RHSA errata listed in the advisory.
Test that adding a key with restrict-destination-v00@openssh.com to a remote agent now preserves the constraint.
Confirm NewKeyring() rejects keys with unsupported constraint extensions in updated builds.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-281: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
2CVSS vectors
5Timeline events
2ADP providers
21Source links
SSVC decision data
CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: yesTechnical Impact: total
CVSS vector scores
2 official scores
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-281 · source CWE mapping
Improper Preservation of Permissions
Improper Preservation of Permissions represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.