A corrective release of OpenSSH 9.9p2 is available, which addresses two vulnerabilities identified by Qualys. An example has been demonstrated using these vulnerabilities for a MITM attack, allowing the traffic from a client connecting to the SSH server to be redirected to a malicious fake server, bypassing host key verification and creating the illusion for the client that it is connected to the desired server (the SSH client will accept the host key from the fake server instead of the legitimate server's key).
The first vulnerability (CVE-2025-26465) is caused by a logical error in the ssh utility, allowing for the bypassing of server authentication and carrying out a MITM attack. The issue manifests starting with release OpenSSH 6.8p1 (December 2014) in configurations where the VerifyHostKeyDNS setting is enabled. In the default OpenSSH installation, this option is turned off, but was enabled in the ssh settings on FreeBSD until March 2023.
The essence of the problem is that in the code of the function verify_host_key_callback(), when calling the function verify_host_key(), only the error code "-1" is checked, while other codes, such as "-2", are ignored. As a result, the function verify_host_key_callback() may return a successful code "0", despite the error code "-2" returned by the function verify_host_key(). The error code "-2" is returned by the function verify_host_key() when there is insufficient memory. If conditions are created that prevent memory allocation in the verify_host_key() function, SSH will consider the host key to be successfully verified. To create such conditions, the attacker's fake SSH server to which the client is redirected returns a host key of the maximum possible size (256KB), while simultaneously exploiting a memory leak on the SSH client side.
The conditions for creating the memory leak are achieved through the second vulnerability (CVE-2025-26466), which affects both the ssh client and the server. server sshd, and exploited without authentication. The vulnerability allows exhausting available memory for the process and creating a high CPU load by sending a large number of SSH2_MSG_PING packets. There is a memory leak in the SSH2_MSG_PING packet handler that manifests starting from the release of OpenSSH 9.5p1 (August 2023). The leak occurs because a 256-byte buffer is allocated for each incoming 16-byte PING packet for response formation, but this buffer is only freed after key negotiation is completed. As a workaround for protection, it is recommended to set limits using the LoginGraceTime, MaxStartups, and PerSourcePenalties directives.
Source: opennet.ru
