OpenSSH forwarded ssh-agent RCE (CVE-2023-38408)

A critical flaw in OpenSSH's agent-forwarding logic, tracked as CVE-2023-38408, allows a malicious or compromised SSH server to achieve remote code execution on a client machine that has forwarded its ssh-agent connection to that server. The bug does not require the attacker to guess a password, steal a private key, or exploit memory corruption in the traditional sense — it abuses a legitimate agent feature (PKCS#11 provider loading) to make the victim's own ssh-agent process load and execute code from libraries that are already sitting on disk. For any organization that relies on jump hosts, CI runners, or engineers hopping between environments with ssh -A, this vulnerability turns a routine, "trusted" workflow into a remote code execution primitive.

What's actually vulnerable

ssh-agent supports loading PKCS#11 provider modules — shared libraries that talk to hardware security tokens and smart cards — so that private keys never have to leave dedicated hardware. Researchers at Qualys' security advisory team found that this same request path was reachable from a forwarded agent connection, not just from local ssh-add calls. In other words, a remote peer who merely holds the other end of a forwarded agent socket could instruct the victim's local ssh-agent to dlopen() an arbitrary library path and invoke functions in it.

By itself, dlopen()-ing an attacker-chosen path sounds like it would require dropping a malicious file onto the victim's disk first. The trick is that it doesn't: attackers can point at libraries that are already installed on most Linux/Unix systems — common PKCS#11 provider shared objects (from packages like OpenSC or p11-kit), or other loaded libraries with side-effect-laden static constructors — and chain their existing code paths into unintended behavior, up to and including code execution. No local file drop, no privilege escalation bug, no user interaction beyond having agent forwarding enabled. The victim only has to run ssh -A (or ForwardAgent yes) to a server the attacker controls, or to a legitimate server that has since been compromised.

Affected versions and components

• Component: ssh-agent, bundled with OpenSSH
• Affected versions: All OpenSSH releases prior to 9.3p2 that include agent-side PKCS#11 support with forwarding enabled — this covers a wide swath of long-term-support distributions still shipping 8.x and early 9.x builds in mid-2023
• Fixed version: OpenSSH 9.3p2, released July 19, 2023
• Trigger conditions: ForwardAgent yes or ssh -A used against a server the attacker controls (or has compromised), combined with the presence of exploitable PKCS#11-capable libraries on the client's filesystem
• Downstream impact: Debian, Ubuntu, RHEL/CentOS/Rocky, SUSE, Alpine, and most other distributions shipped their own OpenSSH packages carrying this flaw and issued backported fixes shortly after upstream disclosure; container base images and golden AMIs built before mid-to-late July 2023 are commonly still affected if not rebuilt

It's worth stressing the precondition that matters most for real-world risk triage: this is only exploitable when agent forwarding is in use. Environments that forward agents into ephemeral build containers, bastion hosts, or third-party-managed servers carry materially higher exposure than those that never enable ForwardAgent.

Severity, exploit probability, and known exploitation

NVD scored CVE-2023-38408 as CVSS v3.1 9.8 (Critical) — network vector, low attack complexity, no privileges or user interaction required for the remote code execution outcome once the forwarding precondition is met. That headline score reflects worst-case impact; actual exploitability in a given environment is gated by whether agent forwarding is enabled and whether a suitable gadget-chain library happens to be installed, so risk should be assessed per-fleet rather than treated as universally "critical everywhere OpenSSH runs."

EPSS scoring for this CVE moved into the moderate-to-elevated range in the weeks following disclosure, consistent with the heavy security-press coverage and the release of public proof-of-concept exploitation chains — but EPSS is time-decaying and worth pulling fresh from a live feed rather than quoting a static number in a blog post. As of this writing, CVE-2023-38408 does not appear on CISA's Known Exploited Vulnerabilities (KEV) catalog; teams using KEV presence as a sole patch-prioritization gate should not rely on that signal alone here, given the severity and public exploit code already in circulation.

Timeline

• Mid-2023: Qualys' security research team privately reports the ssh-agent forwarded PKCS#11 loading issue to the OpenSSH maintainers, alongside other findings from the same audit effort.
• July 19, 2023: OpenSSH releases 9.3p2, closing the forwarded-agent PKCS#11 loading path and correcting the underlying flaw.
• Late July 2023: Qualys publishes its technical advisory detailing the vulnerability class and proof-of-concept exploitation chain, drawing broad security community attention.
• Late July–August 2023: Major Linux distributions (Debian, Ubuntu, RHEL and derivatives, SUSE, Alpine) ship backported patches to their OpenSSH packages; cloud providers and container base image maintainers follow with updated builds.
• Ongoing: Legacy systems, unpatched golden images, and long-lived containers built before the fix continue to surface in vulnerability scans well after the patch's release — a pattern typical of infrastructure-layer CVEs that don't get the same forced-upgrade urgency as application dependencies.

Remediation steps

1. Upgrade OpenSSH to 9.3p2 or later, or apply your distribution's backported fix. Confirm the installed package version, not just the upstream OpenSSH release notes — many LTS distros carry patched point-releases with version strings that don't match "9.3p2" verbatim.
2. Rebuild and redeploy affected images. Golden AMIs, container base images, and VM templates built before the patch was backported need to be rebuilt; simply patching running instances misses the next auto-scaled deployment cycle.
3. Restrict ForwardAgent usage. Set ForwardAgent no as the client-side default and enable it only per-Host stanza for specific, trusted destinations rather than globally. Avoid ad hoc ssh -A to any host outside your direct control, including third-party SaaS shells and shared jump boxes.
4. Audit which hosts actually receive forwarded agents. If a bastion or CI runner doesn't need your personal agent forwarded through it, don't forward it — use per-session, scoped credentials (short-lived certificates, ProxyJump with dedicated keys) instead.
5. Inventory PKCS#11-capable libraries on client systems. Packages like OpenSC and p11-kit modules widen the exploitation surface even after the ssh-agent fix, since related library-loading issues have surfaced elsewhere; remove them from hosts that don't use hardware security tokens.
6. Prefer FIDO2/hardware-resident keys or short-lived certificates over long-lived forwarded agents where your workflow allows it, reducing how often agent forwarding is needed at all.
7. Verify the fix with a version check across the fleet (ssh -V / package manager query) rather than trusting a single sample host — OpenSSH client versions are notoriously inconsistent across mixed on-prem and cloud estates.

How Safeguard Helps

Patching OpenSSH everywhere it appears is straightforward in theory and messy in practice, because the binary is buried inside base images, golden AMIs, and third-party containers your team didn't build. Safeguard's SBOM generation and ingest pipeline surfaces every instance of vulnerable OpenSSH — including nested inside container layers and infrastructure images — so CVE-2023-38408 exposure is visible fleet-wide instead of host-by-host. Griffin AI, Safeguard's reasoning engine, layers reachability analysis on top of that inventory to distinguish hosts where ForwardAgent is actually enabled and exploitable PKCS#11 libraries are present from hosts running the vulnerable binary in a configuration that never triggers the flaw, cutting noisy "critical everywhere" alerts down to the handful of systems with real exposure. For the confirmed-exploitable set, Safeguard can open auto-fix pull requests that bump the OpenSSH package version or tighten ForwardAgent defaults in configuration management, turning triage directly into a merge-ready remediation. The result is prioritized, evidence-backed patching instead of a fleet-wide scramble every time an infrastructure-layer CVE like this one makes headlines.