---
title: "OpenSSH VerifyHostKeyDNS Bypass: Decade-Old Logic Flaw Enables Server Impersonation"
url: https://radicalnotion.ai/blog/openssh-verifyhostkeydns-bypass-decade-old-logic-flaw-enables-server-impersonation-20260130142348
type: article
description: "A critical authentication bypass in OpenSSH (CVE-2025-26465) has lurked undetected since 2014, allowing attackers to impersonate any SSH server when a rarely-enabled option is configured. The vulnerability affects all releases from 6.8p1 through 9.9p1."
updated: 2026-01-30
source: RadicalNotion.AI
license: CC BY-NC 4.0 (https://creativecommons.org/licenses/by-nc/4.0/)
---

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

By Radical Notion Team, 2026-01-30

*A critical authentication bypass in OpenSSH (CVE-2025-26465) has lurked undetected since 2014, allowing attackers to impersonate any SSH server when a rarely-enabled option is configured. The vulnerability affects all releases from 6.8p1 through 9.9p1.*

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

A security researcher at Qualys has uncovered a vulnerability in OpenSSH that has existed for over a decade, allowing an attacker positioned on the network path to completely bypass SSH host-key verification and impersonate any server. While the flaw requires a specific configuration to exploit, its presence in every OpenSSH release from 6.8p1 (December 2014) through 9.9p1 (January 2025) means millions of SSH installations worldwide have been silently vulnerable. The bug was introduced by commit 5e39a49, which added support for the RevokedHostKeys feature but inadvertently created a logic error in the host-key verification callback that would go unnoticed for 3,864 days.

---

## What Happened

On February 18, 2025, the Qualys Threat Research Unit disclosed two related vulnerabilities in OpenSSH: CVE-2025-26465 (the man-in-the-middle bypass) and CVE-2025-26466 (a pre-authentication denial-of-service). The MITM flaw is a textbook case of incorrect error handling—a single missing check that transforms a routine verification failure into a security catastrophe.

The vulnerability only manifests when the OpenSSH client option `VerifyHostKeyDNS` is set to "yes" or "ask". This option, disabled by default on nearly all Linux distributions, enables DNS-based host-key verification via DNSSEC-signed SSHFP records. When enabled, the client queries DNS for a fingerprint of the server's public key and uses it as an additional trust anchor. However, a logic error in the `verify_host_key_callback()` function causes the client to misinterpret certain error codes as successful verification, allowing an attacker who can manipulate DNS responses—or simply present a forged host key—to bypass the entire SSH authentication handshake.

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.

```plaintext
// Simplified pseudo-code of the vulnerable logic:
int verify_host_key_callback(const char *host_key) {
    int result = verify_host_key(host_key);
    
    // BUG: Only checks for -1; any other error is treated as success
    if (result == -1) {
        return FAILURE;
    }
    return SUCCESS;  // Incorrectly returns success for errors like -2
}
```

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:

```plaintext
┌─────────────────────────────────────────────────────────────┐
│ 1. Attacker gains on-path position (ARP spoof, rogue Wi-Fi, │
│    compromised router, etc.)                                 │
└─────────────────────────────────────────────────────────────┘
                           │
                           ▼
┌─────────────────────────────────────────────────────────────┐
│ 2. Victim SSH client has VerifyHostKeyDNS=yes/ask           │
└─────────────────────────────────────────────────────────────┘
                           │
                           ▼
┌─────────────────────────────────────────────────────────────┐
│ 3. Victim initiates SSH connection to legitimate server      │
└─────────────────────────────────────────────────────────────┘
                           │
                           ▼
┌─────────────────────────────────────────────────────────────┐
│ 4. Attacker's fake SSH server presents forged host key with │
│    large certificate extension                               │
└─────────────────────────────────────────────────────────────┘
                           │
                           ▼
┌─────────────────────────────────────────────────────────────┐
│ 5. Attacker floods client with SSH2_MSG_PING packets during │
│    key exchange (~234 MB), exhausting client memory          │
└─────────────────────────────────────────────────────────────┘
                           │
                           ▼
┌─────────────────────────────────────────────────────────────┐
│ 6. sshkey_from_private() returns SSH_ERR_ALLOC_FAIL (-2)    │
└─────────────────────────────────────────────────────────────┘
                           │
                           ▼
┌─────────────────────────────────────────────────────────────┐
│ 7. verify_host_key_callback() ignores -2 and returns success│
└─────────────────────────────────────────────────────────────┘
                           │
                           ▼
┌─────────────────────────────────────────────────────────────┐
│ 8. Client accepts attacker's host key and completes auth    │
└─────────────────────────────────────────────────────────────┘
                           │
                           ▼
┌─────────────────────────────────────────────────────────────┐
│ 9. Attacker has full MITM access to the SSH session         │
└─────────────────────────────────────────────────────────────┘
```

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

|   |   |   |   |
| --- | --- | --- | --- |
|   |   |   |   |
|   |   |   |   |
|   |   |   |   |
| **OpenSSH (upstream)** | OpenSSH client | 6.8p1 – 9.9p1 (inclusive) | 9.9p2 |
| **Red Hat** | RHEL 8 (all architectures) | All releases shipping OpenSSH ≤9.9p1 | RHSA-2025:16823 |
| **Red Hat** | RHEL 9 / 9.4 EUS / 9.6 EUS | All releases shipping OpenSSH ≤9.9p1 | RHSA-2025:3837, RHSA-2025:6993 |
| **Red Hat** | OpenShift Container Platform 4 (RHCOS) | All RHCOS releases with OpenSSH ≤9.9p1 | RHSA-2025:16823 |
| **Debian** | openssh (Bullseye) | 1:8.4p1-5+deb11u3 and earlier | 1:8.4p1-5+deb11u5 |
| **Debian** | openssh (Bookworm) | 1:9.2p1-2+deb12u5 and earlier | 1:9.9p2-1 |
| **Ubuntu** | openssh-client (24.04 LTS) | 1:9.6p1-3ubuntu13.8 | 1:9.6p1-3ubuntu13.8 (back-port) |
| **Ubuntu** | openssh-client (22.04 LTS) | 1:8.9p1-3ubuntu0.11 | 1:8.9p1-3ubuntu0.11 (back-port) |
| **Ubuntu** | openssh-client (20.04 LTS) | 1:8.2p1-4ubuntu0.12 | 1:8.2p1-4ubuntu0.12 (back-port) |
| **Ubuntu** | openssh-client (18.04 LTS) | 1:7.6p1-4ubuntu0.7+esm4 | 1:7.6p1-4ubuntu0.7+esm4 (ESM) |
| **SUSE** | openssh (SLES 15) | openssh-7.2p2-81.26.1, 8.4p1-8.16.1, 9.6p1-3.1 | openssh-7.2p2-81.26.1+, 8.4p1-8.16.1+, 9.6p1-150600.6.15.2+ |
| **OpenBSD** | OpenSSH (OpenBSD 7.6) | All versions up to 9.9p1 | OpenBSD 7.6 errata 008 |
| **Apple** | macOS Sonoma / Sequoia | OpenSSH ≤9.9p1 (bundled) | macOS Sonoma 14.7.6, macOS Sequoia 15.5 |
| **FreeBSD** | OpenSSH (base system) | All releases where VerifyHostKeyDNS=yes by default (Sep 2013 – Mar 2023) | FreeBSD updates after Mar 2023 |
| **NetApp** | Various appliances | Embedded OpenSSH 6.8p1–9.9p1 | Vendor firmware updates (pending) |

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

```bash
# RHEL 8
sudo dnf update openssh openssh-clients openssh-server

# RHEL 9
sudo dnf update openssh openssh-clients openssh-server
```

#### Debian/Ubuntu

```bash
sudo apt update
sudo apt install --only-upgrade openssh-client openssh-server
```

#### OpenBSD

```bash
# Apply errata patch for OpenBSD 7.6
cd /tmp
ftp https://ftp.openbsd.org/pub/OpenBSD/patches/7.6/common/008_ssh.patch.sig
signify -Vep /etc/signify/openbsd-76-base.pub -x 008_ssh.patch.sig \
    -m - | (cd /usr/src && patch -p0)
cd /usr/src/usr.bin/ssh
make obj
make
make install
```

#### Compile from Source (Upstream)

```bash
wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-9.9p2.tar.gz
wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-9.9p2.tar.gz.asc
# Verify signature (see OpenSSH website for GPG key)
gpg --verify openssh-9.9p2.tar.gz.asc openssh-9.9p2.tar.gz
tar xzf openssh-9.9p2.tar.gz
cd openssh-9.9p2
./configure --prefix=/usr --sysconfdir=/etc/ssh
make
sudo make install
```

### 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`:

```plaintext
# Limit pre-auth connection time
LoginGraceTime 30

# Limit concurrent unauthenticated connections
MaxStartups 10:30:60

# Enable per-source-IP penalties (OpenSSH ≥9.8p1)
PerSourcePenalties yes
PerSourceNetBlockSize 24:64
```

After editing `sshd_config`, restart the SSH daemon:

```bash
sudo systemctl restart sshd
```

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

---

## Sources

- [NVD - CVE-2025-26465](https://nvd.nist.gov/vuln/detail/CVE-2025-26465)
- [Red Hat Security Advisory RHSA-2025:16823](https://access.redhat.com/errata/RHSA-2025:16823)
- [Red Hat Security Advisory RHSA-2025:3837](https://access.redhat.com/errata/RHSA-2025:3837)
- [Red Hat Security Advisory RHSA-2025:6993](https://access.redhat.com/errata/RHSA-2025:6993)
- [Red Hat Bugzilla Bug 2344780](https://bugzilla.redhat.com/show_bug.cgi?id=2344780)
- [Red Hat Solutions Article 7109879](https://access.redhat.com/solutions/7109879)
- [Debian LTS Announcement - openssh](https://lists.debian.org/debian-lts-announce/2025/02/msg00020.html)
- [Debian Security Tracker - CVE-2025-26465](https://security-tracker.debian.org/tracker/CVE-2025-26465)
- [Ubuntu Security Notice - CVE-2025-26465](https://ubuntu.com/security/CVE-2025-26465)
- [SUSE Bugzilla Bug 1237040](https://bugzilla.suse.com/show_bug.cgi?id=1237040)
- [OpenBSD 7.6 Errata 008 - ssh(1) Patch](https://ftp.openbsd.org/pub/OpenBSD/patches/7.6/common/008_ssh.patch.sig)
- [OpenSSH Release Notes - 9.9p2](https://www.openssh.com/releasenotes.html#9.9p2)
- [OpenSSH Mailing List Announcement](https://lists.mindrot.org/pipermail/openssh-unix-announce/2025-February/000161.html)
- [Qualys Security Advisory - OpenSSH CVE-2025-26465/CVE-2025-26466](https://blog.qualys.com/vulnerabilities-threat-research/2025/02/18/qualys-tru-discovers-two-vulnerabilities-in-openssh-cve-2025-26465-cve-2025-26466)
- [OpenWall oss-security Mailing List (Initial Disclosure)](https://www.openwall.com/lists/oss-security/2025/02/18/1)
- [OpenWall oss-security Mailing List (Follow-up)](https://www.openwall.com/lists/oss-security/2025/02/18/4)
- [SecLists oss-sec Mailing List (Proof-of-Concept)](https://seclists.org/oss-sec/2025/q1/144)
- [The Register - OpenSSH Vulnerabilities MITM DoS](https://www.theregister.com/2025/02/18/openssh_vulnerabilities_mitm_dos/)
- [NetApp Security Advisory NTAP-20250228-0003](https://security.netapp.com/advisory/ntap-20250228-0003/)
- [Vicarius vSociety - Detect Vulnerable OpenSSH](https://www.vicarius.io/vsociety/posts/cve-2025-26465-detect-vulnerable-openssh)

Tags: CVE-2025-26465, OpenSSH, man-in-the-middle, authentication-bypass, VerifyHostKeyDNS, Red Hat, Debian, Ubuntu, SUSE, FreeBSD

---

Source: [RadicalNotion.AI](https://radicalnotion.ai/blog/openssh-verifyhostkeydns-bypass-decade-old-logic-flaw-enables-server-impersonation-20260130142348). Licensed CC BY-NC 4.0; attribute RadicalNotion.AI and link the source page when you reuse this data.