OpenSSH VerifyHostKeyDNS Bypass: Decade-Old Logic Flaw Enables Server Impersonation

Qualys researchers demonstrated that the bug could be reliably triggered by exhausting the client's memory during the key-exchange phase, forcing the verification routine to return an allocation-failure error code that the callback incorrectly treats as success. The attack requires an on-path position (classic man-in-the-middle) but no user interaction, making it particularly dangerous for environments that have intentionally enabled DNS-based verification or for platforms like FreeBSD, which enabled VerifyHostKeyDNS by default for nearly a decade (September 2013 to March 2023).

Understanding the Vulnerability

The core of the vulnerability lies in how OpenSSH handles return codes from the host-key verification routine. When VerifyHostKeyDNS is enabled, the client performs an additional verification step:

1. The client initiates an SSH connection and receives the server's public host key during the key-exchange phase.
2. If VerifyHostKeyDNS=yes, the client queries DNS for SSHFP records (RFC 4255) that contain fingerprints of the server's key.
3. The client calls verify_host_key(), which in turn calls sshkey_from_private() to load the server's key from memory.
4. The result is passed to verify_host_key_callback(), which checks the return value.

Here's where the bug occurs. The callback function only checks for a return value of -1 (representing a generic failure, such as SSH_ERR_SIGNATURE_INVALID). Any other error code—including -2 (SSH_ERR_ALLOC_FAIL, returned when memory allocation fails)—is ignored, and the function returns success.

An attacker can force sshkey_from_private() to return -2 by exhausting the client's memory. The Qualys proof-of-concept achieves this by:

1. Running a malicious SSH server that presents a large (≈140 KB) RSA certificate extension.
2. Flooding the client with thousands of SSH2_MSG_PING packets during the initial key exchange (≈234 MB total).
3. The client attempts to allocate memory for each PING packet's response (PONG buffer), eventually running out of memory.
4. sshkey_from_private() fails with SSH_ERR_ALLOC_FAIL (-2).
5. verify_host_key_callback() treats -2 as success and accepts the attacker's host key.
6. The client proceeds to authenticate to the attacker's server, believing it is the legitimate host.

This is a classic "goto-out" error-handling pattern gone wrong. When the RevokedHostKeys feature was added in 2014, the developer forgot to reset the error code before jumping to the cleanup label, causing downstream callers to misinterpret the result.

Attack Chain

A successful exploitation follows this sequence:

The memory-exhaustion component (CVE-2025-26466) is optional; the core bypass (CVE-2025-26465) can theoretically be triggered by any condition that causes sshkey_from_private() to return an error other than -1. However, the PING-flood technique provides a reliable, repeatable exploitation path.

Who Is Affected

The vulnerability affects any system running OpenSSH 6.8p1 or later where VerifyHostKeyDNS is enabled. While the option is disabled by default on most platforms, there are notable exceptions:

• FreeBSD enabled it by default from September 2013 until March 2023, covering FreeBSD 9.2 through FreeBSD 13.1.
• Custom enterprise SSH configurations that rely on DNSSEC-validated SSHFP records.
• Security-hardened environments that mistakenly believe DNS-based verification adds a layer of protection.

Given OpenSSH's ubiquity—it is the de facto standard for remote administration on Linux, BSD, macOS, and increasingly Windows—the potential attack surface is enormous. However, the requirement for VerifyHostKeyDNS to be enabled means the practical exposure is limited to a subset of deployments. Administrators who have explicitly enabled the option (or are running vulnerable FreeBSD releases) should treat this as a critical, drop-everything-and-patch issue.

Real-World Risk

Exploitation Complexity

The Qualys team successfully demonstrated a working proof-of-concept that reliably triggers the bypass. The attack requires:

1. Network position: The attacker must be on the path between client and server (classic MITM). This is achievable via:
2. Client configuration: The victim must have VerifyHostKeyDNS=yes or VerifyHostKeyDNS=ask. On most platforms this is off by default, but:
3. Memory exhaustion: The attacker must be able to send a large volume of SSH2_MSG_PING packets during the key exchange. This is trivial to automate and requires no special resources—a typical broadband connection is more than sufficient.

Known Exploitation

As of January 30, 2026, there are no confirmed reports of in-the-wild exploitation of CVE-2025-26465. However:

• A public proof-of-concept was released on February 18, 2025, on the oss-security mailing list and mirrored on SecLists.
• The PoC includes a fully functional fake SSH server and client-side attack script.
• Qualys researchers confirmed the attack works reliably against unpatched OpenSSH installations.

The lack of observed exploitation is likely due to:

1. The default-off configuration: Most systems are not vulnerable unless an administrator has explicitly enabled VerifyHostKeyDNS.
2. The attack's visibility: A successful MITM requires active network manipulation, which is more likely to be detected than passive exploitation.
3. The short window: The vulnerability was disclosed and patched on the same day (February 18, 2025), giving attackers limited opportunity to weaponize it before defenders could respond.

That said, the threat model is severe for affected systems:

• An attacker who successfully impersonates an SSH server can capture credentials (passwords or private keys), exfiltrate data, and execute arbitrary commands on the compromised host.
• SSH is the primary remote administration tool for Linux/Unix systems, meaning a successful MITM can lead to full system compromise, lateral movement, and persistence.
• For cloud environments, CI/CD pipelines, and DevOps workflows that rely on SSH for automation, the impact could be catastrophic—an attacker could inject malicious code into software builds, steal API keys from configuration files, or pivot into production infrastructure.

Threat Actor Interest

While no threat actors have been publicly attributed to exploiting this vulnerability, the profile of the flaw makes it attractive to:

• Nation-state actors conducting targeted espionage (the ability to silently intercept SSH sessions is a high-value capability for intelligence gathering).
• Ransomware operators seeking to pivot from initial access to domain-wide compromise (SSH credentials are a common escalation path).
• Advanced persistent threat (APT) groups looking for stealthy, long-lived access to critical infrastructure.

The fact that the bug existed for over 10 years undetected raises the question: could it have been exploited in the past without anyone knowing? The answer is almost certainly yes—MITM attacks are notoriously difficult to detect retroactively, and a sophisticated attacker who knew about the bug could have used it to compromise high-value targets without leaving forensic evidence.

What You Should Do

Immediate Actions

1. Verify VerifyHostKeyDNS is disabled on all client systems:If the option is set to yes or ask, disable it immediately by adding or changing the line to:
2. Audit FreeBSD systems: If you are running FreeBSD releases from September 2013 through March 2023, assume VerifyHostKeyDNS was enabled by default and treat all SSH clients as vulnerable until patched.
3. Apply patches as soon as possible:

Patching Instructions

Red Hat Enterprise Linux

Debian/Ubuntu

OpenBSD

Compile from Source (Upstream)

Workarounds (If Patching Is Not Immediately Possible)

If you cannot patch immediately, the following workarounds provide full mitigation for CVE-2025-26465:

1. Disable VerifyHostKeyDNS globally:This is the recommended temporary mitigation. It has no side effects beyond disabling DNS-based host-key verification, which is a rarely-used feature.
2. Use StrictHostKeyChecking with a known_hosts file: Ensure all clients are configured with StrictHostKeyChecking yes and maintain an accurate ~/.ssh/known_hosts file. This does not mitigate the vulnerability directly, but it reduces the attack surface by requiring manual verification of host keys.
3. For FreeBSD systems (if running a vulnerable release):

Server-Side Mitigations (For CVE-2025-26466 DoS Component)

While the MITM bypass (CVE-2025-26465) is a client-side issue, the related memory-exhaustion DoS (CVE-2025-26466) affects SSH servers. To limit the impact of PING-flood attacks, configure the following in /etc/ssh/sshd_config:

After editing sshd_config, restart the SSH daemon:

Detection Recommendations

To detect potential exploitation attempts or successful attacks:

1. Monitor SSH client logs for anomalies:
2. Network-level detection (IDS/IPS):
3. Audit SSH client configurations for VerifyHostKeyDNS:
4. SIEM correlation: Look for SSH authentication events where:

The Bigger Picture

CVE-2025-26465 is a sobering reminder that even the most battle-tested, security-critical codebases can harbor subtle, high-impact bugs for years. OpenSSH is maintained by some of the most skilled developers in the world, undergoes regular audits, and is deployed on hundreds of millions of systems. Yet a single missing error-code check—introduced by a seemingly innocuous refactoring in 2014—created a critical authentication bypass that went undetected for over a decade.

Several lessons emerge from this incident:

1. Default-Secure Configuration Matters

The fact that VerifyHostKeyDNS is disabled by default on most platforms is the single biggest reason this vulnerability has not caused widespread compromise. If the option had been enabled by default—as it was on FreeBSD for nearly 10 years—the impact would have been catastrophic. This reinforces the principle that security-sensitive features should default to off unless there is a compelling reason to enable them.

2. DNS-Based Authentication Is a Double-Edged Sword

The VerifyHostKeyDNS feature was designed to leverage DNSSEC to provide an additional trust anchor for SSH host keys. In theory, this is a good idea: if DNS is properly secured with DNSSEC, SSHFP records can provide automatic, cryptographically-verified host-key validation. In practice, however:

• DNSSEC adoption is low: As of 2025, fewer than 5% of domains use DNSSEC, and even fewer have correctly-configured SSHFP records.
• DNS is inherently fragile: Even with DNSSEC, DNS is vulnerable to cache poisoning, resolver hijacking, and other attacks that can undermine trust.
• The complexity adds attack surface: As this vulnerability demonstrates, the additional code paths required to support DNS-based verification introduce new failure modes that can be exploited.

The takeaway: DNS-based authentication should be treated as a convenience feature, not a security enhancement. Administrators who enable VerifyHostKeyDNS should understand they are trading a small usability improvement for a significant increase in attack surface.

3. Error Handling Is Hard (And Critical)

The root cause of CVE-2025-26465 is a textbook example of incorrect error handling. The developer who wrote the original code assumed that verify_host_key() would only return -1 on failure, but the function can actually return multiple different error codes depending on the failure mode. By only checking for -1, the code silently ignored all other errors—including allocation failures, format errors, and signature validation failures.

This pattern is disturbingly common in C codebases, where functions often return 0 for success and negative values for various error conditions. Developers must be vigilant about checking all possible error codes, not just the most common one. Modern static analysis tools (e.g., Coverity, Clang Static Analyzer) can catch many of these bugs, but they are not foolproof—code review and comprehensive testing remain essential.

4. Memory Exhaustion as an Exploitation Primitive

The Qualys proof-of-concept cleverly leverages a memory-exhaustion attack (CVE-2025-26466) to reliably trigger the error-code path that bypasses verification. This technique—forcing an application into an out-of-memory condition to induce unexpected behavior—is not new, but it is often overlooked by developers who assume that memory allocation will "just work" in normal operation.

The broader lesson: resource exhaustion attacks are not just denial-of-service attacks. They can also be used to trigger logic errors, bypass security checks, or escalate privileges. Developers should:

• Implement strict limits on unbounded allocations (e.g., the PING/PONG buffering issue in CVE-2025-26466)
• Gracefully handle allocation failures rather than assuming they will never occur
• Use memory-safe languages (Rust, Go) for new code where possible

Related Vulnerabilities to Watch

The disclosure of CVE-2025-26465 and CVE-2025-26466 has prompted renewed scrutiny of OpenSSH's codebase. Security researchers are now actively auditing other areas of the code for similar error-handling bugs. Key areas of concern include:

• Certificate validation: OpenSSH supports SSH certificates (RFC 6187), which involve complex parsing and validation logic. Any errors in this code could lead to authentication bypasses similar to CVE-2025-26465.
• Agent forwarding: SSH agent forwarding (ssh -A) is a frequent source of vulnerabilities due to its complexity and the sensitive nature of forwarded credentials.
• ProxyJump and ProxyCommand: These features allow SSH clients to tunnel connections through intermediate hosts, creating additional attack surface for MITM attacks.

Administrators should stay vigilant for future OpenSSH security updates and consider subscribing to the OpenSSH security mailing list for early notification of new vulnerabilities.

The Broader SSH Ecosystem

OpenSSH is not the only SSH implementation in wide use. Other implementations, including:

• Dropbear (lightweight SSH server for embedded systems)
• libssh (SSH library used by many applications)
• PuTTY (Windows SSH client)
• Bitvise SSH Server (Windows SSH server)

...may have similar vulnerabilities. The disclosure of CVE-2025-26465 should prompt security teams to audit all SSH implementations in their environment, not just OpenSSH.

Final Thoughts

The OpenSSH VerifyHostKeyDNS bypass is a stark reminder that security is a process, not a destination. Even the most mature, well-audited software can harbor critical bugs. Organizations must maintain a culture of continuous improvement, where:

• Security patches are applied promptly (within days, not weeks)
• Default configurations are regularly reviewed and hardened
• Third-party security research is welcomed and acted upon
• Incident response plans are tested and updated

The fact that this vulnerability existed for 10 years without causing widespread damage is partly luck, partly good default configuration, and partly the result of a security community that rapidly coordinated a response once the bug was discovered. We should not count on being so fortunate next time.

Patch your OpenSSH installations now. Verify that VerifyHostKeyDNS is disabled. And remember: the next critical bug is probably already hiding in plain sight, waiting to be discovered.