Bug 2571719 (CVE-2026-126641)

Summary: CVE-2026-126641 ansible-pylibssh: accepts a changed SSH host key when host_key_auto_add is enabled
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: jlanda, kshier, rbobbitt, simaishi, stcannon, yguenane
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
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.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2572305, 2572306, 2572307    
Bug Blocks:    

Description OSIDB Bzimport 2026-11-11 14:20:07 UTC 
When trust-on-first-use is enabled (host_key_auto_add on the libssh plugin, or AutoAddPolicy in pylibssh), a host that is already in known_hosts 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 known_hosts. Defaults are not affected - with host_key_checking on and host_key_auto_add unset, non-interactive runs fail closed. Root cause: pylibssh Session.verify_knownhost() passes SSH_KNOWN_HOSTS_CHANGED and SSH_KNOWN_HOSTS_OTHER to the same missing_host_key() 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 network_cli with ssh_type=libssh. Reporter: Satriyo Utomo (aleens-labs).