OpenSSH CVE-2026-60002: the server gets to shoot first

The mental model most sysadmins carry for SSH security runs something like this: I connect to a server, the server authenticates me (or I authenticate to it), and if I’ve done my key hygiene correctly I’m fine. The server is the thing I’m worried about compromising. My client is the trusted executor.

CVE-2026-60002 breaks that model. Specifically: a malicious SSH server can trigger a use-after-free in your ssh client process during a host key re-exchange.

What actually happens

Key re-exchange (rekeying) is a normal, spec-compliant part of SSH. Long-lived connections periodically renegotiate session keys. During that process, the server can present a new host key.

The bug in OpenSSH before 10.4 is in how the client handles a server-initiated host key change during rekeying. A freed pointer gets dereferenced. That’s a CWE-416 use-after-free on the client side, triggered entirely by server behavior. The server does not need to authenticate to you. It just needs to complete a key exchange and then send a key change during rekeying.

Depending on heap layout, a crash is the floor. Arbitrary code execution on your client machine is the ceiling. The CVE scores it CVSS 7.7.

Who is actually exposed

Three conditions put you in the path of this:

One: you are running OpenSSH client older than 10.4. Check with ssh -V. If you are on any distribution that ships a current stable release, 10.4 came out July 6. If you are still on something older, you have work to do.

Two: you connect to SSH servers you do not control. Your own servers on your own network are not the threat. The threat is connecting to a shared jump host, a third-party bastion, a cloud provider’s managed SSH endpoint, or anything where a compromise upstream gives an attacker server-side control over what you receive during rekeying.

Three: you have StrictHostKeyChecking=no anywhere in your ssh config, or you have a habit of hitting “yes” when prompted about a changed host key. That’s a separate but compounding problem. A server that can change its host key without your client rejecting the connection is also a server that can position itself to exploit this bug.

The known_hosts angle

The first defense is the thing that has always been the first defense: ~/.ssh/known_hosts and StrictHostKeyChecking. If your client has a stored fingerprint for a host and the server presents something different, the connection dies before rekeying ever completes. A strict client never gets to the vulnerable code path.

This does not mean “you’re fine if you’re strict.” A server you’ve never connected to before, a new key you’re trusting for the first time, or a legitimate key rotation you accepted without verifying out-of-band: any of those let you proceed into rekeying with a server that controls the host key presentation.

TOFU (trust on first use) is a real exposure model. The first connection to a bad server is the one that can burn you.

What to do

Upgrade to OpenSSH 10.4 or later. On Debian/Ubuntu, that’s in the current security feeds. On FreeBSD, ports have had 10.4p1 since July. On systems where you cannot upgrade (embedded, legacy, locked-down production), restrict ssh usage to servers you administer and verify host key fingerprints out-of-band before the first connection.

Audit your ~/.ssh/config for StrictHostKeyChecking=no. Every instance of that is a choice you made to trade security for convenience. CVE-2026-60002 is what that trade costs.

The 1,313-CVE Debian kernel batch from yesterday was mostly noise with a few real entries worth front-loading. This one is not noise. It’s a client-side remote exploit vector in one of the most universally deployed tools in Unix administration. Patch it.