Insufficiently trusted PKCS#11 search path enables remote code execution in OpenBSD OpenSSH ssh-agent

The PKCS#11 feature in ssh-agent in OpenSSH before 9.3p2 has an insufficiently trustworthy search path, leading to remote code execution if an agent is forwarded to an attacker-controlled system. (Code in /usr/lib is not necessarily safe for loading into ssh-agent.) NOTE: this issue exists because of an incomplete fix for CVE-2016-10009.

• OpenBSD OpenSSH: versions before 9.3p2 are affected. The supplied affected facts explicitly mark 9.3 and 9.3p1 as affected; 9.3p2 is the upstream fixed release.
• Fedora: the normalized record marks Fedora 37 and 38 as affected. It does not provide an exact fixed package boundary for those branches, so the Fedora security update must be used to determine the installed package status.
• Gentoo: the Gentoo advisory identifies net-misc/openssh on all architectures as affected below 9.3_p2 and unaffected at 9.3_p2 and above.
• Qualys demonstrated exploitability on Ubuntu Desktop environments, but that research is not a complete affected-product list. Downstream packages may backport the fix, so an upstream version alone is not sufficient to determine the status of every operating-system package.

The flaw is in the ssh-agent PKCS#11 provider-loading path, where the library search path is not sufficiently trustworthy. When an agent is forwarded to an attacker-controlled host, remote PKCS#11 requests can cause libraries from /usr/lib* on the victim system to be opened with dlopen() and then closed with dlclose(). OpenSSH performs this loading in the separate ssh-pkcs11-helper process rather than in the main agent address space, but library-loader side effects, including constructors and destructors, still execute in a security-sensitive process. Qualys demonstrated that these side effects can be chained to turn the library-loading primitive into reliable remote code execution despite ASLR, PIE, and NX. Exploitation requires specific libraries to be present on the victim system and requires the agent socket to be forwarded to an attacker-controlled system. The exploitable library set depends on the operating system and installed packages, and the public research does not establish identical exploitability across all distributions.

The vulnerability is reachable over the network through a forwarded agent socket. The attacker must have access to the remote system receiving the agent socket, but once that condition exists, the normalized record characterizes the attack as requiring no additional privileges, no further user interaction, and low complexity. The presence of suitable libraries on the victim system and enabled agent forwarding are material preconditions. Public exploit material exists, and the Qualys Security Advisory team published technical analysis and demonstrated remote code execution. The record does not establish whether exploitation has been observed in the wild.

Successful exploitation allows attacker-controlled code to execute in the context of the affected agent or PKCS#11 helper process. This can compromise the confidentiality, integrity, and availability of the workstation or user session within the privileges available to the agent process. Because agent forwarding makes a local agent reachable from a remote host, a compromised destination host can become a starting point for follow-on activity against the user's system. The downstream effect depends on account privileges, keys loaded into the agent, host authorization, and network segmentation. The presence of suitable libraries and a forwarded agent socket are important limits; not every OpenSSH installation is automatically exploitable.

• Administrator and developer workstations, along with automation hosts that forward agents, may be exposed to code execution with the privileges of the agent process, affecting data, development tools, and build or deployment workflows.
• Control of the host receiving the forwarded agent socket can provide a starting point for activity on the workstation or in the user's session. Further access depends on loaded keys, account permissions, network segmentation, and local controls.
• Environments that do not forward agents to untrusted systems have materially different exposure from environments that rely heavily on agent forwarding.
• The reviewed evidence does not identify a specific campaign, victim, or breach, so each organization's practical impact must be assessed from its forwarding configuration and installed package state.

1. Upgrade upstream OpenBSD OpenSSH to 9.3p2. For Gentoo, use net-misc/openssh at 9.3_p2 or the applicable advisory-supported version. For Fedora 37 and 38, install the Fedora security update; do not infer an exact package version where the available evidence does not provide one.
2. If an update cannot be applied immediately, start ssh-agent with an empty PKCS#11/FIDO allowlist using ssh-agent -P '', or configure an allowlist containing only specifically approved provider libraries. This may disrupt legitimate provider use.
3. Do not forward an agent to untrusted servers. Where appropriate, use a jump host instead of exposing the local agent socket directly to the destination system.
4. If remote provider loading must remain available, note that the fixed behavior rejects remote PKCS#11 loading by default. Do not restore the previous behavior with -Oallow-remote-pkcs11 unless the need is explicitly assessed and controlled.
5. Review non-OpenSSH tools that forward agent sockets, because remote-client detection may be bypassed when the socket is forwarded through other tooling.

• Inventory OpenSSH, ssh-agent, and operating-system packages, and verify that security updates are applied rather than relying only on an upstream version string.
• Identify configurations or commands that enable agent forwarding, especially ForwardAgent and -A, then list the hosts that can access the forwarded agent socket.
• Inspect ssh-agent launch options to determine whether the PKCS#11/FIDO allowlist is empty or restricted to approved provider libraries.
• Determine whether the deployment uses ssh-pkcs11-helper and whether the client can identify remote requests. Non-OpenSSH tools used to forward the socket may weaken or bypass this control.
• As a precaution, monitor unusual ssh-pkcs11-helper activity and unexpected shared-library loading during forwarded-agent sessions. The available evidence does not define a CVE-specific IOC or log signature.
• Do not treat the absence of suspicious logs as proof of safety; correlate inventory, forwarding configuration, and package update state.