Client-side use-after-free during host-key re-exchange in OpenBSD OpenSSH

ssh in OpenSSH before 10.4 can have a use-after-free when a server changes its host key during a key re-exchange. (This outcome occurs only on the client side.)

• OpenBSD OpenSSH: versions before 10.4 are marked affected in the structured data; the product's default status is recorded as unaffected.
• The upstream release notes identify the client-side use-after-free fix in OpenSSH 10.4.
• The available data does not enumerate all parallel branches or vendor backports. OpenSSH packages supplied by other operating systems must be checked against the relevant vendor advisory and fix status.

OpenBSD OpenSSH can enter a use-after-free path in the ssh(1) client when a connected server changes its host key during a key re-exchange. The affected operation is client-side; the available evidence does not identify the freed object, specific function, or precise memory state transition. An attacker-controlled server would need to induce this protocol condition while a vulnerable client is connected, but that is an inference from the trigger description rather than a fully documented exploit sequence. The record characterizes the issue as network reachable, requiring no attacker privileges and no user interaction. The supplied scoring data contains conflicting attack-complexity assessments, so the conditions for reliable exploitation remain incompletely characterized.

The flaw can be triggered remotely through an SSH connection to a server that can change its host key during key re-exchange. The attack characteristics in the record indicate that the attacker does not need prior privileges and that no additional user interaction is required. The record contains inconsistent assessments of attack complexity, so it should not be assumed that every connection is equally easy to exploit. The available data does not confirm a public exploit or exploitation in the wild; the absence of a listed exploit is not proof that systems are safe.

The direct technical consequence is that the ssh(1) client may use memory after it has been freed. If successfully triggered, the flaw could crash the client or cause other memory-corruption effects; the supplied impact fields indicate potentially significant confidentiality and integrity consequences and a lower availability consequence. Because the source explicitly limits the outcome to the client side, remediation should focus on systems that initiate SSH connections rather than treating every sshd deployment as directly affected by this specific flaw. The available evidence does not confirm code execution, persistence, or a server-compromise path.

Systems using the OpenBSD OpenSSH client could experience disruption if the SSH process encounters the flaw during a connection or key re-exchange. This may affect remote administration, automation, file transfer, or deployment workflows that depend on SSH, although the record does not quantify the outage scope. If the memory-safety flaw can be converted into more than process disruption, data accessible to the SSH process could potentially be disclosed or modified; this is a possible consequence, not a confirmed exploitation result. The record limits the specific outcome to the client side, so deployments that only run an SSH server should not automatically be treated as directly exposed to this particular client-side issue.

1. Upgrade affected OpenSSH clients to OpenSSH 10.4, the release whose upstream notes document the fix for this issue.
2. For operating-system or vendor-maintained packages, verify the fix through the vendor advisory or changelog. Do not infer safety from the package version alone when the vendor backports fixes.
3. Prioritize systems that frequently connect to untrusted or externally managed SSH servers.
4. The supplied record does not provide a specific workaround. Do not rely on an unconfirmed mitigation instead of updating the client.

• Inventory OpenSSH client installations on systems that initiate SSH connections, including operating-system and vendor-maintained packages.
• Compare deployed versions with the fixed release identified in remediation, and check vendor backport information rather than relying only on the package version.
• Identify clients that connect to servers outside the organization's full control and prioritize those systems for review.
• If protocol-level debug telemetry is available, review unexpected host-key changes during key re-exchange as a precaution. This is not a confirmed indicator of compromise.
• The available evidence does not define a specific log signature or intrusion indicator. Absence of related log evidence does not prove that a client is unaffected.