CVE-2026-60002

What it actually does

OpenSSH ssh client versions before 10.4 contain a client-side use-after-free condition during SSH key re-exchange when the server changes its host key. A malicious or compromised SSH server, or an attacker able to interpose on an SSH connection under conditions that allow manipulation of the server-side key exchange flow, may be able to trigger memory corruption in the client process. Because this occurs in the SSH client, impact is primarily to the workstation, automation runner, bastion client, or application host initiating outbound SSH connections. Successful exploitation could allow compromise of confidentiality or integrity in the client process context, with possible client crash or limited denial of service. Exploitation is assessed as high complexity and no public exploit maturity is indicated, with low EPSS at this time.

Why it matters to the business

Organizations using vulnerable OpenSSH clients may expose administrator workstations, CI/CD systems, automation jobs, file-transfer processes, and bastion hosts to compromise when they connect to malicious or compromised SSH servers. The most serious business risk is theft or manipulation of data and credentials accessible to the SSH client process, including deployment keys, SSH agent access, terminal session data, or files processed by automation. Operational impact may include failed SSH-based administration, backups, deployments, or transfers if clients crash during exploitation attempts. Although this is not currently listed in CISA KEV and the EPSS score is low, SSH is widely deployed and frequently used in privileged workflows, so patching should be prioritized for systems that initiate SSH connections to third-party, internet-facing, or less-trusted servers.

How an attack unfolds

An attacker first needs a target that runs a vulnerable OpenSSH ssh client and can be induced to connect to an attacker-controlled, compromised, or malicious SSH server. During the SSH session, the server participates in key exchange and later triggers a key re-exchange. The malicious server changes its host key during that re-exchange in a way that exercises the vulnerable client-side state handling path. In vulnerable versions before OpenSSH 10.4, the client may reference memory that has already been freed, causing memory corruption. Depending on allocator behavior, platform hardening, build options, timing, and attacker control over memory layout, this may result in a crash or potentially code execution within the context of the ssh client process. Post-exploitation value depends on what the client process can access, such as local files, forwarded agent material, environment variables, terminal input/output, or automation secrets.

How to fix it

Upgrade OpenSSH clients to version 10.4 or later wherever available. Prioritize endpoints and systems that initiate SSH connections to external, partner-managed, internet-facing, developer-controlled, or otherwise less-trusted servers. Where vendor packages are used, apply the operating system vendor’s fixed OpenSSH client package rather than relying only on upstream version numbers, because distributions may backport the fix. If immediate patching is not possible, reduce exposure by limiting outbound SSH to trusted hosts, disabling or restricting SSH access to untrusted servers, avoiding agent forwarding to untrusted destinations, using separate low-privilege accounts for automation, and monitoring for client crashes or abnormal SSH behavior during rekey events. Rebuild or restart long-running automation images, containers, runners, bastions, and jump hosts after package updates so the fixed ssh binary is actually in use.

How to confirm the fix worked

Confirm that the active ssh client binary reports OpenSSH 10.4 or later, or that the installed operating system package includes the vendor backported fix. Run `ssh -V` on representative endpoints, bastions, CI/CD runners, containers, and automation images that initiate SSH connections. Validate package inventory through endpoint management, vulnerability scanning, software bill of materials, or configuration management data. Confirm that no older statically bundled ssh binaries remain in application directories, container images, portable toolchains, backup agents, deployment tools, or file-transfer utilities. Where possible, test that automated SSH workflows still function after upgrade and that outbound SSH restrictions do not interrupt approved operations.

Typical attack path

1. Identify users, administrators, automation systems, or service accounts that initiate outbound SSH connections using OpenSSH before 10.4.
2. Operate or compromise an SSH server that the target is likely to access, or otherwise position to influence SSH server-side behavior during a connection.
3. Allow the victim client to establish an SSH session and proceed through normal authentication or pre-authentication negotiation as needed.
4. Trigger an SSH key re-exchange from the server side.
5. Change the server host key during the re-exchange to reach the vulnerable OpenSSH client state transition.
6. Trigger the client-side use-after-free condition.
7. Attempt to shape the memory corruption outcome into process crash, information disclosure, or code execution in the ssh client process context.
8. If code execution is achieved, access files, session data, forwarded agent capabilities, or automation secrets available to the client process.

How to detect it

To assess whether this was already exploited, focus on client-side evidence rather than server logs. Review endpoint telemetry, operating system crash logs, EDR process events, shell histories, SSH client logs, terminal session records, CI/CD job logs, and automation runner logs for abnormal ssh process crashes or heap corruption around the time of outbound SSH connections. Correlate crashes with destinations whose SSH host keys changed unexpectedly, with first-time connections to unfamiliar SSH servers, or with connections made shortly before failures in deployment, backup, administration, or file-transfer jobs. On Linux and Unix-like systems, inspect syslog, journald, kernel logs, coredump records, audit logs, and EDR telemetry for `ssh` segmentation faults, aborts, allocator errors, or core dumps. On macOS, review Unified Logs, DiagnosticReports, and crash reports for the ssh process. In CI/CD and automation environments, search job output for abrupt SSH disconnects, non-zero exits, segmentation faults, or host key warnings. Because reliable exploitation-specific network signatures are not generally available from the provided information, detection should be based on a combination of vulnerable client version, suspicious SSH destination, host key change events, and client process crash or memory corruption artifacts.

• ssh: segmentation fault
• segfault at .* in ssh
• kernel: ssh\[.*\]: segfault
• systemd-coredump.*ssh
• coredumpctl.*ssh
• Process: ssh
• Executable Path: /usr/bin/ssh
• Executable Path: /usr/local/bin/ssh
• AddressSanitizer: heap-use-after-free
• heap-use-after-free.*ssh
• free(): invalid pointer
• double free or corruption
• corrupted double-linked list
• malloc(): memory corruption
• malloc_consolidate(): unaligned fastbin chunk detected
• REMOTE HOST IDENTIFICATION HAS CHANGED
• Host key verification failed
• WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED
• Offending .* key in .*known_hosts
• ssh_dispatch_run_fatal
• Connection closed by .* port 22

What your security team should do

• Inventory OpenSSH client versions across workstations, administrator systems, bastions, CI/CD runners, containers, automation hosts, and file-transfer systems.
• Patch or replace OpenSSH clients before 10.4, giving highest priority to systems that connect to third-party, internet-facing, unmanaged, or high-risk SSH servers.
• Review automation images and embedded toolchains for bundled or statically shipped ssh binaries that may not be updated by the operating system package manager.
• Temporarily restrict outbound SSH from sensitive systems to approved destinations until patch coverage is confirmed.
• Disable SSH agent forwarding to untrusted servers and review where deployment keys, private keys, and automation credentials are accessible to SSH client processes.
• Monitor endpoint and system logs for ssh client crashes, heap corruption messages, segmentation faults, or unusual failures during SSH rekey activity.
• Investigate any recent connections from vulnerable clients to newly changed, unknown, or unexpected SSH host keys.
• Do not treat low EPSS or absence from KEV as a reason to defer indefinitely; prioritize based on the privilege level and trust boundary of systems initiating SSH connections.