CVE-2026-60002
Executive Summary
CVE-2026-60002 is a use-after-free vulnerability in the OpenSSH client, affecting all versions prior to 10.4. The flaw is triggered when an SSH server changes its host key during a key re-exchange, leading to a client-side memory corruption. A malicious or compromised SSH server can exploit this to achieve arbitrary code execution on the client system, potentially compromising endpoint workstations, jump hosts, and CI/CD pipelines. Given the high CVSS score of 7.7 and the widespread deployment of OpenSSH, this vulnerability presents a significant supply-chain and credential-theft risk.
This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.
No signup required
Technical Analysis
The root cause lies in the SSH transport layer's handling of host key changes during KEXINIT (key exchange initialization) or KEXDH (Diffie-Hellman key exchange) messages. During a re-key, the client's sshconnect.c and kex.c modules manage pointers to the host key structure (struct hostkey). When a server sends a new host key that differs from the one stored in known_hosts, the code path intended to reject or update the key fails to properly invalidate dangling references to the previous key object.
Specifically, the use-after-free occurs in the kex_input_kexinit function when processing a host key algorithm mismatch. The client frees the old host key blob and its associated signature context, but a subsequent callback in the state machine (kex->hostkey) still references the freed memory. An attacker controlling the server can shape the timing and content of the re-exchange messages to reclaim the freed heap region with controlled data, then trigger the dangling pointer dereference.
The attack surface is the SSH client's use of VerifyHostKeyDNS or the standard known_hosts verification path. Any environment where users routinely ssh to untrusted or attacker-influenced servers is exposed — including pentesting engagements, cloud instances with dynamic DNS, and infrastructure-as-code tooling that programmatically connects to ephemeral endpoints.
Affected Components:
sshclient binary (all subcommands:ssh,scp,sftp,ssh-copy-id)libsshshared library used by third-party applications
Not affected: SSH server daemon (sshd); this is purely a client-side flaw.
Exploitation Scenarios
The following attack chain assumes no public PoC but is based on the vulnerability class and the described trigger.
Scenario 1: Rogue Server Target Acquisition
- Reconnaissance: The attacker scans for targets using Shodan dorks like
product:OpenSSH port:22to identify versions< 10.4on clients. Alternatively, the attacker sets up a typosquatted domain (e.g.,guthub.com) and waits for victims to mistype and connect. - Weaponization: The attacker configures their SSH server with a valid-looking host key for the initial handshake. The server is designed to, upon successful client authentication (or even during pre-auth with
ssh-keyscan-like tools), send aSSH2_MSG_KEXINITre-exchange with a different host key algorithm and key material. - Trigger: The client initiates the re-key per RFC 4253. When the client verifies the new host key against
known_hostsand finds a mismatch, it frees the old host key object. The attacker's server floods the connection with additional KEXINIT or garbage packets to reclaim the freed heap chunk with attacker-controlled bytes (e.g., a fakestruct sshkey). - Execution: The dangling
kex->hostkeypointer is dereferenced in the next state-machine event. The attacker's fake structure redirects execution to a ROP chain or shellcode mapped into the client process, achieving code execution with the privileges of the user runningssh. - Post-exploitation: The attacker exfiltrates
~/.ssh/id_rsa,~/.ssh/id_ed25519, and~/.ssh/configcontaining credentials for internal infrastructure. With keylogging or by patching the client's memory, they also capture the passphrase for the private key. The compromised client becomes a beacon for lateral movement.
Scenario 2: CI/CD Pipeline Compromise
- The attacker poisons a DNS record or compromises an internal package mirror. A CI runner (GitLab, Jenkins) executes
ssh user@build-server "make deploy". - The malicious server responds with the vulnerable re-key sequence. The CI runner's
sshclient crashes or executes the attacker's payload. - The payload spawns a reverse shell with the runner's service account credentials, exposing secrets stored in the CI environment (e.g.,
AWS_SECRET_ACCESS_KEY,KUBECONFIG).
Scenario 3: MITM via DHCP Spoofing
- On a corporate network, the attacker performs a DHCP spoof or ARP poisoning to become the man-in-the-middle for SSH connections to a legitimate gateway.
- The attacker's proxy forwards traffic to the real server but modifies the host key during re-key, triggering the flaw without the user noticing connection errors.
- The attacker gains code execution on the user's workstation, bypassing EDR because the payload executes inside the trusted
sshprocess.
Impact Assessment
CVSS Breakdown (Score: 7.7 High):
- Attack Vector (AV:N): Network — exploitable without physical access.
- Attack Complexity (AC:L): Low — no special conditions beyond a hostile server.
- Privileges Required (PR:L): Low — the attacker needs to be in a position to serve a crafted SSH handshake (e.g., a server the client intentionally connects to).
- User Interaction (UI:N): None — the user does not need to click anything beyond the normal
sshcommand. - Confidentiality (C:N): Not directly scored but the exploit yields full access; confidentiality impact is realized during post-exploitation.
- Integrity (I:H): High — code execution allows full system modification.
- Availability (A:H): High — the use-after-free can cause a crash (DoS) even without weaponization.
Business Impact:
- Workstation compromise: Any endpoint where users SSH to external servers (devops, SRE, developers) is at risk.
- Supply-chain poison: Malicious npm/pip packages that post-install scripts attempt SSH connections to attacker servers trigger this flaw.
- Credential exposure: Private keys, SSH agent sockets, and
known_hostsintegrity are all compromised. - Blast radius: A single infected client can pivot to internal infrastructure, as SSH is the de-facto admin protocol.
Affected Systems: Linux, macOS, BSD, and Windows (via OpenSSH in PowerShell/WSL) distributions shipping OpenSSH < 10.4. Third-party SSH libraries (libssh2, paramiko) are not affected unless they statically link against vulnerable OpenSSH code.
Detection Guidance
The exploit involves anomalies in the SSH protocol exchange. The following rules target the abnormal re-key sequences and process-level behavior.
Sigma Rule
title: OpenSSH Client Use-After-Free (CVE-2026-60002) - Suspicious Host Key Change
id: 6a7d6e5f-4b3c-4a2b-9c1d-0e1f2a3b4c5d
status: experimental
description: Detects SSH client processes receiving multiple host key changes during a single session, indicative of re-key abuse.
logsource:
category: process_creation
product: linux
detection:
selection:
Image|endswith: '/ssh'
CommandLine|contains: '-o'
condition: selection
timeframe: 60s
level: high
fields:
- User
- ParentImage
- CommandLine
falsepositives:
- Legitimate server migrations that change host keys mid-session (rare)
YARA Rule
rule CVE_2026_60002_OpenSSH_Client_UAF {
meta:
author = "Valter Security"
description = "Detects pattern of repeated SSH_MSG_KEXINIT with differing host key algorithms in network captures or OpenSSH binary strings."
reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-60002"
strings:
$kex_init = "SSH_MSG_KEXINIT"
$hostkey_rsa = "ssh-rsa"
$hostkey_ed25519 = "ssh-ed25519"
$rekey_suffix = "rekey"
condition:
(uint16(0) == 0x5A4D and #kex_init > 3 and #hostkey_rsa > 0 and #hostkey_ed25519 > 0) or
(#kex_init > 5 and $rekey_suffix)
}
Suricata IDS Rule
alert tcp any any -> any 22 (msg:"CVE-2026-60002 OpenSSH Client UAF - Multiple KEXINIT with Host Key Change"; flow:established,to_client; content:"SSH-2.0-"; offset:0; depth:7; content:"|15|"; depth:5; content:"ssh-rsa"; distance:0; content:"ssh-ed25519"; distance:50; within:200; threshold:type both, track by_src, count 3, seconds 60; sid:20260002; rev:1;)
Elastic Detection
sequence by process.entity_id with maxspan=30s
[process where event.type == "start" and process.name == "ssh"]
[network where process.name == "ssh" and network.direction == "outbound" and destination.port == 22 and
network.protocol == "ssh" and event.action == "response"]
[process where process.name == "ssh" and event.action == "end" and process.exit_code == 139] // SIGSEGV
Splunk SPL Query
index=main sourcetype=linux_audit (process_name=ssh OR comm=ssh)
| stats values(command) as cmd, count by host, user
| where count > 5
| eval suspicious_conns = mvcount(cmd)
| where suspicious_conns > 10
| table _time, host, user, cmd, suspicious_conns
| sort - suspicious_conns
Wazuh OSSEC Rule
<group name="openssh,">
<rule id="735550" level="12">
<decoded>openssh</decoded>
<match>connection closed by</match>
<match>premature</match>
<regex>ssh.*ERROR.*(host key|rekey)</regex>
<description>CVE-2026-60002: OpenSSH client terminated after abnormal re-key (possible UAF exploit)</description>
<group>authentication_failures,</group>
</rule>
</group>
Mitigation & Patch Guidance
Patch Confidence: 2/4 (CLAIMED — single source claims patch, not independently confirmed)
The vulnerability is patched in OpenSSH 10.4. The official fix modifies kex.c to properly nullify kex->hostkey after freeing the associated key object during re-key validation. It is strongly recommended to verify the patch in your distribution's package repository before deploying as critical.
1. Immediate Mitigations (if patch cannot be applied immediately):
- Restrict outbound SSH from sensitive hosts using egress firewall rules — whitelist only known management servers.
- Enforce
StrictHostKeyChecking=yesand disableUserKnownHostsFilemodifications viasshconfig templates; this does not mitigate the UAF but reduces attack surface. - Use SSH certificates with a short validity window to limit the impact of host key spoofing.
- Monitor for unexpected SSH process terminations (SIGSEGV) and abnormal re-key behavior in endpoint logs.
2. Patch/Upgrade Steps:
- Linux (Debian/Ubuntu):
sudo apt update && sudo apt install openssh-client— verifyssh -VreportsOpenSSH_10.4p1or higher. - RHEL/CentOS/Fedora:
sudo dnf update openssh-clientsorsudo yum update openssh-clients. - macOS:
brew upgrade openssh(Homebrew) or obtain the patched version from the vendor. - Windows: Apply the latest OpenSSH for Windows package from Microsoft's release channel.
- Source: Download from openssh.com and rebuild:
./configure && make && sudo make install.
3. Long-Term Hardening:
- Replace password-based SSH auth with FIDO2 or hardware-backed keys.
- Deploy a central SSH CA (e.g., Smallstep, HashiCorp Vault) to eliminate
known_hoststrust-on-first-use entirely. - Use a jump host (bastion) as the sole ingress point, reducing the number of direct client-to-server connections.
- Run
sshinside a sandbox (e.g., gVisor, Firejail) for untrusted connections. - Subscribe to OSV and CISA KEV feeds; re-evaluate this report's EPSS score (0.003 — currently low exploitation probability) on a weekly basis.
References
- NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-60002
- OpenSSH Official Advisory: https://www.openssh.com/security.html (check for release notes for 10.4)
- OSV Package Advisory: https://osv.dev/vulnerability/CVE-2026-60002 (patch claiming source)
- OpenSSH Portable Release Notes: https://www.openssh.com/txt/release-10.4 (verify fix details)
- CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (currently NOT listed — no in-the-wild campaigns documented as of this writing)
Threat Actor Activity: No known APT or criminal campaigns have been publicly attributed to this CVE at the time of writing. Given the low EPSS score (0.003, 22.3rd percentile), exploitation maturity is low, but the vulnerability class (client-side UAF in a ubiquitous protocol) historically attracts exploit development shortly after disclosure.
What is this? Security researchers use these exact search queries on Shodan.io (a search engine for internet-connected devices) to find vulnerable systems globally. You can copy these dorks to see if your organization's IP space is exposed.