OpenSSH fixes flaws that enable man-in-the-middle, DoS attacks

OpenSSH, the most widely used tool for remotely managing Linux and BSD systems, received patches for two vulnerabilities. One of the flaws could allow attackers to perform a man-in-the-middle attack against OpenSSH clients with a certain configuration and impersonate a server to intercept sensitive communications. While the second vulnerability can lead to CPU resource exhaustion.

“SSH sessions can be a prime target for attackers aiming to intercept credentials or hijack sessions,” researchers from Qualys who found the flaws wrote in their report. “If compromised, hackers could view or manipulate sensitive data, move across multiple critical servers laterally, and exfiltrate valuable information such as database credentials. Such breaches can lead to reputational damage, violate compliance mandates (e.g., GDPR, HIPAA, PCI-DSS), and potentially disrupt critical operations by forcing system downtime to contain the threat.”

The man-in-the-middle vulnerability, tracked as CVE-2025-26465, was introduced in the code over 10 years ago in December 2014. As such it impacts all OpenSSH versions from 6.8p1 through 9.9p1.

The second vulnerability is tracked as CVE-2025-26466 and impacts versions 9.5p1 through 9.9p1. Users are advised to upgrade to the newly released OpenSSH 9.9p2 as soon as it becomes available in their Linux distribution.

DNS-based key verification is broken

OpenSSH is the most popular implementation of the SSH (Secure Shell) protocol and is developed by the OpenBSD Project, which maintains the OpenBSD operating system. OpenBSD is known for the quality and security of its code in general and OpenSSH is no different.

Serious vulnerabilities in OpenSSH are a rare occurrence and given its importance as the primary remote administration tool for BSD and Linux servers, it has been the subject of many code reviews and security assessments over the years.

The way the SSH protocol works is by first establishing an encrypted connection before exchanging credentials. This is similar to TLS, where the client first verifies the identity of the server by looking at their public key. If the key has already been trusted, the handshake continues. If the key fingerprint differs from the one already stored on the client’s known_hosts file for that server, the client will issue a warning that a man-in-the-middle attack might be in progress.

But how does known_hosts get populated with server identities? This typically happens when the client connects to a server for the very first time and the user is prompted if they want to accept and trust the key presented by the server, thus creating a record for it locally.

But not all SSH users are human. SSH is also used for a lot of machine-to-machine interaction via automated scripts that perform various tasks automatically. So how do these automated scripts trust newly provisioned servers? The answer is a feature called VerifyHostKeyDNS that allows a client to automatically trust a server’s key by checking that it matches the SSHFP DNS record for the server’s hostname.

The VerifyHostKeyDNS is turned off by default in most deployments, but users who want to make use of it can turn it on in the configuration. The option was also enabled by default in the OpenSSH package shipped with FreeBSD from September 2013 until March 2023.

The Qualys researchers discovered a logic error in the function that checks the server’s key when VerifyHostKeyDNS is enabled and set to either “ask” or “yes”, where any error value other than -1 (SSH_ERR_INTERNAL_ERROR) is not actually treated as an error and is considered a success.

When they tried to exploit this by trying different error codes, they found that it only worked with -2 (SSH_ERR_ALLOC_FAIL), an out-of-memory error.

The second vulnerability is needed for a successful attack

But how to trigger this memory error on the client in a real-world scenario. One option was to put a very long key on the fake server, but they were limited by the maximum size of the packet that is exchanged during the handshake which is around 256KB and this is not nearly enough to consume all of the client’s memory.

This meant the researchers needed another vulnerability that could be triggered before authentication and would consume as much of the client process’ memory before serving the rogue server key in an attempt to trigger an out-of-memory SSH_ERR_ALLOC_FAIL error.

“As yet another testimony to OpenSSH’s code quality, we actually failed to find a pre-authentication memory leak,” the researchers wrote in their advisory. “Instead, we found an unlimited allocation of memory that is not freed until the very end of the initial key exchange.”

This is the second vulnerability, CVE-2025-26466, which impacts both client and server deployments of OpenSSH. And while it can lead to denial-of-service on both clients and servers, on the client it can also be used to set up the ground for exploiting the other vulnerability and make the man-in-the-middle attack possible.

“If fake-server does implement the out-of-memory attack discussed previously (by allocating a 1024-bit RSA key and a ~140KB certificate extension, plus ~234MB of PONG packets — but many other combinations work), then the client’s call to sshkey_from_private() returns SSH_ERR_ALLOC_FAIL, and its checks of the real-server’s host key are completely bypassed, thus allowing the fake-server to successfully impersonate the real-server,” the researchers explained in their proof-of-concept exploit scenario.