OpenSSH 10.4 Locking Flaw Lets Remote Agents Use Local Keys Until Fixed in 10.5

OpenSSH 10.4 Locking Flaw Exposes Local‑Only Keys Until Patched in 10.5

What Happened – In OpenSSH 10.4 the ssh‑agent lock feature unintentionally disabled the check that distinguishes a local key request from one arriving via agent‑forwarding. A locked agent could therefore sign operations that originated on a remote host, effectively exposing decrypted private keys. OpenSSH 10.5 restores the missing check and adds several unrelated hardening fixes.

Why It Matters for Compliance & Audit Readiness

• Demonstrates the need for documented key‑management controls (SOC 2 CC6.1) and evidence that privileged credentials are protected when idle.
• Highlights the importance of continuous patch‑management and verifiable change‑control logs to satisfy SOC 2 change‑management requirements.
• Provides a concrete audit‑ready data point: logs of agent lock/unlock events and remote‑forwarding attempts must be retained and reviewed.

Who Is Affected – Organizations that rely on OpenSSH for server administration, CI/CD pipelines, or remote development—including SaaS providers, cloud‑infrastructure teams, and internal IT operations.

Recommended Actions

• Upgrade all OpenSSH deployments to version 10.5 or later immediately.
• Enable detailed logging of ssh‑agent lock/unlock state and any agent‑forwarding requests; retain logs for SOC 2 audit evidence.
• Review authorized_keys files to ensure the restrict keyword and other key‑restriction options are correctly applied.

Technical Notes – The flaw stemmed from the loss of the session‑bind@openssh.com verification when the agent was locked, allowing remote forwarded requests to be treated as local. OpenSSH 10.5 also patches a use‑after‑free in the client and corrects the restrict keyword’s handling of tunnel forwarding. Source: Help Net Security