{"api_version":"1","generated_at":"2026-11-12T12:53:28+00:00","cve":"CVE-2026-126641","urls":{"html":"https://cve.report/CVE-2026-126641","api":"https://cve.report/api/cve/CVE-2026-126641.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-126641","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-126641"},"summary":{"title":"Ansible-pylibssh: accepts a changed ssh host key when host_key_auto_add is enabled","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.","state":"PUBLISHED","assigner":"redhat","published_at":"2026-11-12 11:17:11","updated_at":"2026-11-12 11:17:11"},"problem_types":["CWE-322","CWE-322 Key Exchange without Entity Authentication"],"metrics":[{"version":"3.1","source":"secalert@redhat.com","type":"Primary","score":"6.5","severity":"MEDIUM","vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N","data":{"version":"3.1","vectorString":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N","baseScore":6.5,"baseSeverity":"MEDIUM","attackVector":"NETWORK","attackComplexity":"HIGH","privilegesRequired":"NONE","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"HIGH","integrityImpact":"LOW","availabilityImpact":"NONE"}},{"version":"3.1","source":"CNA","type":"CVSS","score":"6.5","severity":"MEDIUM","vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N","data":{"attackComplexity":"HIGH","attackVector":"NETWORK","availabilityImpact":"NONE","baseScore":6.5,"baseSeverity":"MEDIUM","confidentialityImpact":"HIGH","integrityImpact":"LOW","privilegesRequired":"NONE","scope":"UNCHANGED","userInteraction":"NONE","vectorString":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N","version":"3.1"}}],"references":[{"url":"https://access.redhat.com/security/cve/CVE-2026-126641","name":"https://access.redhat.com/security/cve/CVE-2026-126641","refsource":"secalert@redhat.com","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2571719","name":"https://bugzilla.redhat.com/show_bug.cgi?id=2571719","refsource":"secalert@redhat.com","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-126641","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-126641","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Red Hat","product":"Red Hat Ansible Automation Platform 2","version":"","platforms":[]},{"source":"CNA","vendor":"Red Hat","product":"Red Hat Ansible Automation Platform 2","version":"","platforms":[]},{"source":"CNA","vendor":"Red Hat","product":"Red Hat Ansible Automation Platform 2","version":"","platforms":[]},{"source":"CNA","vendor":"Red Hat","product":"Red Hat Ansible Automation Platform 2","version":"","platforms":[]},{"source":"CNA","vendor":"Red Hat","product":"Red Hat Ansible Automation Platform 2","version":"","platforms":[]},{"source":"CNA","vendor":"Red Hat","product":"Red Hat Ansible Automation Platform 2","version":"","platforms":[]}],"timeline":[{"source":"CNA","time":"2026-11-11T14:10:25.855Z","lang":"en","value":"Reported to Red Hat."},{"source":"CNA","time":"2026-11-11T14:19:28.279Z","lang":"en","value":"Made public."}],"solutions":[],"workarounds":[{"source":"CNA","title":"","value":"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.","time":"","lang":"en"}],"exploits":[],"credits":[{"source":"CNA","value":"Red Hat would like to thank Satriyo Utomo (aleens-labs) for reporting this issue.","lang":"en"}],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"collectionURL":"https://access.redhat.com/downloads/content/package-browser/","cpes":["cpe:/a:redhat:ansible_automation_platform:2"],"defaultStatus":"affected","packageName":"ansible-automation-platform-26/ee-supported-rhel9","product":"Red Hat Ansible Automation Platform 2","vendor":"Red Hat"},{"collectionURL":"https://access.redhat.com/downloads/content/package-browser/","cpes":["cpe:/a:redhat:ansible_automation_platform:2"],"defaultStatus":"affected","packageName":"ansible-automation-platform-27/ee-supported-rhel9","product":"Red Hat Ansible Automation Platform 2","vendor":"Red Hat"},{"collectionURL":"https://access.redhat.com/downloads/content/package-browser/","cpes":["cpe:/a:redhat:ansible_automation_platform:2"],"defaultStatus":"affected","packageName":"python3.11-ansible-pylibssh","product":"Red Hat Ansible Automation Platform 2","vendor":"Red Hat"},{"collectionURL":"https://access.redhat.com/downloads/content/package-browser/","cpes":["cpe:/a:redhat:ansible_automation_platform:2"],"defaultStatus":"affected","packageName":"python3.12-ansible-pylibssh","product":"Red Hat Ansible Automation Platform 2","vendor":"Red Hat"},{"collectionURL":"https://access.redhat.com/downloads/content/package-browser/","cpes":["cpe:/a:redhat:ansible_automation_platform:2"],"defaultStatus":"affected","packageName":"python3x-ansible-pylibssh","product":"Red Hat Ansible Automation Platform 2","vendor":"Red Hat"},{"collectionURL":"https://access.redhat.com/downloads/content/package-browser/","cpes":["cpe:/a:redhat:ansible_automation_platform:2"],"defaultStatus":"affected","packageName":"python-ansible-pylibssh","product":"Red Hat Ansible Automation Platform 2","vendor":"Red Hat"}],"credits":[{"lang":"en","value":"Red Hat would like to thank Satriyo Utomo (aleens-labs) for reporting this issue."}],"datePublic":"2026-11-11T14:19:28.279Z","descriptions":[{"lang":"en","value":"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."}],"metrics":[{"other":{"content":{"namespace":"https://access.redhat.com/security/updates/classification/","value":"Moderate"},"type":"Red Hat severity rating"}},{"cvssV3_1":{"attackComplexity":"HIGH","attackVector":"NETWORK","availabilityImpact":"NONE","baseScore":6.5,"baseSeverity":"MEDIUM","confidentialityImpact":"HIGH","integrityImpact":"LOW","privilegesRequired":"NONE","scope":"UNCHANGED","userInteraction":"NONE","vectorString":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N","version":"3.1"},"format":"CVSS"}],"problemTypes":[{"descriptions":[{"cweId":"CWE-322","description":"Key Exchange without Entity Authentication","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-11-12T10:47:30.699Z","orgId":"53f830b8-0a3f-465b-8143-3b8a9948e749","shortName":"redhat"},"references":[{"tags":["vdb-entry","x_refsource_REDHAT"],"url":"https://access.redhat.com/security/cve/CVE-2026-126641"},{"name":"RHBZ#2571719","tags":["issue-tracking","x_refsource_REDHAT"],"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2571719"}],"timeline":[{"lang":"en","time":"2026-11-11T14:10:25.855Z","value":"Reported to Red Hat."},{"lang":"en","time":"2026-11-11T14:19:28.279Z","value":"Made public."}],"title":"Ansible-pylibssh: accepts a changed ssh host key when host_key_auto_add is enabled","workarounds":[{"lang":"en","value":"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."}],"x_generator":{"engine":"cvelib 1.8.0"},"x_redhatCweChain":"CWE-322: Key Exchange without Entity Authentication"}},"cveMetadata":{"assignerOrgId":"53f830b8-0a3f-465b-8143-3b8a9948e749","assignerShortName":"redhat","cveId":"CVE-2026-126641","datePublished":"2026-11-12T10:47:30.699Z","dateReserved":"2026-11-11T10:46:47.354Z","dateUpdated":"2026-11-12T10:47:30.699Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-11-12 11:17:11","lastModifiedDate":"2026-11-12 11:17:11","problem_types":["CWE-322","CWE-322 Key Exchange without Entity Authentication"],"metrics":{"cvssMetricV31":[{"source":"secalert@redhat.com","type":"Primary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N","baseScore":6.5,"baseSeverity":"MEDIUM","attackVector":"NETWORK","attackComplexity":"HIGH","privilegesRequired":"NONE","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"HIGH","integrityImpact":"LOW","availabilityImpact":"NONE"},"exploitabilityScore":2.2,"impactScore":4.2}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"126641","Ordinal":"1","Title":"Ansible-pylibssh: accepts a changed ssh host key when host_key_a","CVE":"CVE-2026-126641","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"126641","Ordinal":"1","NoteData":"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.","Type":"Description","Title":"Ansible-pylibssh: accepts a changed ssh host key when host_key_a"}]}}}