ansible libssh accepts changed host keys when auto-add is on
Red Hat confirmed CVE-2026-126641 and lifted the embargo on November 12; the post is truncated.
Changed SSH host key accepted in Ansible libssh auto-add
A host-key check flaw in ansible-pylibssh and the ansible.netcommon libssh connection plugin treats a changed key for a host already in known_hosts as a new host when trust-on-first-use is on (host_key_auto_add or AutoAddPolicy). A network attacker who substitutes that host can receive the controller's login, have the play run there, and have the new key stored, exposing connection credentials. Default settings (host_key_checking on, host_key_auto_add unset) are not affected; non-interactive runs fail closed.
What to do: Apply Red Hat's update for CVE-2026-126641 when available. Until then, leave host_key_auto_add unset and keep host_key_checking enabled; do not use AutoAddPolicy.
| Product | Affected |
|---|---|
| Red Hat ansible-pylibssh | — |
| Red Hat ansible.netcommon libssh connection plugin | — |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
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.
Red Hat confirmed CVE-2026-126641 and lifted the embargo on November 12; the post is truncated.
Today 186 readers · 204 views · 45 reads · all time 192K views