CVE-2026-126641: Ansible-pylibssh: accepts a changed ssh host key when host_key_auto_add is enabled
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 (hostkeyautoadd on the libssh connection plugin, or AutoAddPolicy in ansible-pylibssh), a host that is already present in knownhosts but now presents a different key is accepted without warning. The pylibssh Session.verifyknownhost() method passes the SSHKNOWNHOSTSCHANGED and SSHKNOWNHOSTSOTHER states to the same missinghostkey() 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 knownhosts, which can disclose connection credentials to an attacker performing a machine-in-the-middle attack. Default configurations (hostkeychecking enabled, hostkeyautoadd unset) are not affected; non-interactive runs fail closed.
Other sources
When trust-on-first-use is enabled (hostkeyautoadd on the libssh plugin, or AutoAddPolicy in pylibssh), a host that is already in knownhosts but now presents a different key is accepted without warning: the controller authenticates to it, runs the play there, and appends the new key to knownhosts. Defaults are not affected - with hostkeychecking on and hostkeyautoadd unset, non-interactive runs fail closed. Root cause: pylibssh Session.verifyknownhost() passes SSHKNOWNHOSTSCHANGED and SSHKNOWNHOSTSOTHER to the same missinghostkey() policy hook used for unknown hosts. The hook name and the bundled AutoAddPolicy/RejectPolicy classes follow paramiko, where that hook is consulted only for absent hosts and a mismatched key raises BadHostKeyException. ansible.netcommon's MyAddPolicy, documented as "Based on AutoAddPolicy in paramiko", therefore adds changed keys as well. libssh's own tutorial stops the connection on both states. Verified on ansible-pylibssh 1.4.0 / libssh 0.12.0; ansible-core 2.21.5, ansible.netcommon 8.7.1 (ansible 14.5.0); ansible.netcommon.libssh and networkcli with sshtype=libssh. Reporter: Satriyo Utomo (aleens-labs).
— Red Hat
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Leave host_key_auto_add unset and keep host_key_checking enabled; non-interactive runs then fail closed for changed host keys.
ansible-pylibssh and ansible.netcommon libssh connection plugin host_key_auto_add = unset
Event History
Frequently Asked Questions
Which configurations are affected?
Affected configurations enable trust-on-first-use: host_key_auto_add on the libssh connection plugin or AutoAddPolicy in ansible-pylibssh. Default configurations with host_key_checking enabled and host_key_auto_add unset are not affected.
What does an attacker need to exploit this?
An attacker needs to perform a machine-in-the-middle attack against a host already recorded in known_hosts and present a different SSH host key. No prior privileges or user interaction are required by the vector shown.
What is the practical impact of a successful attack?
The controller can authenticate to the substitute host and run the play there. Connection credentials may be disclosed to the attacker, and the substitute host key is appended to known_hosts.
What can be done if patching is not immediately possible?
Do not enable trust-on-first-use for these connections. Keep host_key_checking enabled and leave host_key_auto_add unset; non-interactive runs in the default configuration fail closed.
How can I identify potentially exposed automation?
Review Ansible and connection-plugin settings for host_key_auto_add, and review ansible-pylibssh usage for AutoAddPolicy. Systems using either setting for libssh-based connections should be treated as potentially exposed.