CVE-2026-60002

A flaw was found in OpenSSH. A remote attacker could exploit a use-after-free vulnerability on the client side when a server changes its host key during a key re-exchange. This could lead to high impact on confidentiality and integrity, and low impact on availability. Mitigation To mitigate this...

CVE-2026-60002

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...

CVE-2026-60002

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...

EUVD-2026-42146

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...

CVE-2026-60002

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...

CVE-2026-60002

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...

PT-2026-56293

Name of the Vulnerable Software and Affected Versions OpenSSH versions prior to 10.4 Description A use-after-free issue exists in the ssh client. This occurs when a server changes its host key during a key re-exchange, which is a process where the client and server negotiate new session keys to...

Unity Linux 20.1060e / 20.1070e Security Update: libssh (UTSA-2026-017426)

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2026-017426 advisory. A flaw has been found in libssh in versions prior to 0.9.6. The SSH protocol keeps track of two shared secrets during the lifetime of the session. One of them is...

A flaw has been found in libssh in versions prior to 0.9.6. The SSH protocol keeps track of two shared secrets during the lifetime of the session. One of them is called secret_hash and the other session_id. Initially, both of them are the same, but after key re-exchange, previous session_id is kept and used as an input to new secret_hash. Historically, both of these buffers had shared length variable, which worked as long as these buffers were same. But the key re-exchange operation can also change the key exchange method, which can be based on hash of different size, eventually creating "secret_hash" of different size than the session_id has. This becomes an issue when the session_id memory is zeroed or when it is used again during second key re-exchange.

...