CVE-2026-126641

Description

A host key verification flaw was found in ansible-pylibssh and in the ansible.netcommon libssh connection plugin. When trust-on-first-use is enabled (host_key_auto_add on the libssh connection plugin, or AutoAddPolicy in ansible-pylibssh), a host that is already present in known_hosts but now presents a different key is accepted without warning. The pylibssh Session.verify_knownhost() method passes the SSH_KNOWN_HOSTS_CHANGED and SSH_KNOWN_HOSTS_OTHER states to the same missing_host_key() policy hook used for unknown hosts, and the bundled AutoAddPolicy/RejectPolicy classes (as well as ansible.netcommon's MyAddPolicy, which is modeled on paramiko's AutoAddPolicy) therefore add the changed key and continue the connection rather than aborting as paramiko's BadHostKeyException path would. As a result the controller authenticates to the substitute host, runs the play there, and appends the new key to known_hosts, which can disclose connection credentials to an attacker performing a machine-in-the-middle attack. Default configurations (host_key_checking enabled, host_key_auto_add unset) are not affected; non-interactive runs fail closed.

Statement

This flaw requires a non-default configuration in which trust-on-first-use is explicitly enabled (host_key_auto_add on the ansible.netcommon libssh connection plugin, or AutoAddPolicy when using ansible-pylibssh directly). Exploitation additionally requires an attacker already positioned to intercept the connection and a prior known_hosts entry for the target host. Because these preconditions substantially raise attack complexity and default deployments fail closed, Red Hat rates the impact of this flaw as Moderate.

Mitigation

Do not enable host_key_auto_add (ansible.netcommon libssh) or AutoAddPolicy (ansible-pylibssh). Keep host_key_checking enabled and pre-populate known_hosts with verified host keys so that a changed key causes the connection to fail closed.

Common Vulnerability Scoring System (CVSS) Score Details

Info alert:Important note

CVSS scores for open source components depend on vendor-specific factors (e.g. version or build chain). Therefore, Red Hat's score and impact rating can be different from NVD and other vendors. Red Hat remains the authoritative CVE Naming Authority (CNA) source for its products and services (see Red Hat classifications).

The following CVSS metrics and score provided are preliminary and subject to review.

CVSS v3 Score Breakdown

Red HatNVDcve.org
Base Score6.5N/AN/A
Attack VectorNetworkN/AN/A
Attack ComplexityHighN/AN/A
Privileges RequiredNoneN/AN/A
User InteractionNoneN/AN/A
ScopeUnchangedN/AN/A
ConfidentialityHighN/AN/A
Integrity ImpactLowN/AN/A
Availability ImpactNoneN/AN/A

Vector

Red Hat: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N

Understanding the Weakness (CWE)

Access Control

Technical Impact: Bypass Protection Mechanism

No authentication takes place in the key exchange process itself, bypassing an assumed protection of encryption. This may enable an attacker to impersonate an actor by modifying traffic between the two entities. Typically, this involves a victim client that contacts a malicious server that is impersonating a trusted server. If the client skips authentication or ignores an authentication failure, the malicious server may request authentication information from the user. The malicious server can then use this authentication information to log in to the trusted server using the victim's credentials, sniff traffic between the victim and trusted server, etc.

Confidentiality

Technical Impact: Read Application Data

The encrypted communication between a user and a trusted host may be subject to sniffing by any actor in the communication path.

Acknowledgements

Red Hat would like to thank Satriyo Utomo (aleens-labs) for reporting this issue.

Frequently Asked Questions

Want to get errata notifications? Sign up here.