Um problema na arquitetura de comunicação entre a biblioteca libssh e os plugins de conexão do Ansible abriu uma brecha para ataques de interceptação em infraestruturas de automação. A vulnerabilidade, identificada como CVE-2026-126641, afeta o processo de verificação de chaves SSH no pacote ansible-pylibssh e no plugin ansible.netcommon. Quando configurações de aceitação automática estão ativadas, o sistema falha em reconhecer alertas de segurança e aceita conexões com servidores falsos.
O problema foi catalogado com risco moderado pela Red Hat e registrado no National Vulnerability Database (NVD), banco de dados mantido pelo laboratório de tecnologia da informação do NIST (Instituto Nacional de Padrões e Tecnologia dos Estados Unidos). A exposição atinge componentes frequentemente utilizados na automação de equipamentos de rede. O comportamento padrão do Ansible, no entanto, não é afetado. Instalações que operam com as configurações de fábrica rejeitam a conexão divergente e protegem a infraestrutura.
O mecanismo de confiança no primeiro uso e o risco na rede
O protocolo SSH utiliza o arquivo known_hosts para registrar a assinatura criptográfica de um servidor no momento do contato inicial. Nas conexões seguintes, o cliente compara a chave apresentada pelo host com a chave salva no registro. Se as assinaturas forem diferentes, a conexão deve ser bloqueada imediatamente. Essa divergência indica que um atacante pode estar interceptando o tráfego de rede para se passar pelo destino original.
O risco da CVE-2026-126641 ocorre exatamente na etapa de verificação. Quando o administrador habilita a opção de confiança automática nos componentes afetados do Ansible, a ferramenta perde a capacidade de diferenciar um servidor inédito de um servidor conhecido cuja chave foi alterada de forma ilegítima.
Em caso de interceptação, o controlador do Ansible autentica o acesso no servidor do atacante. O invasor recebe as senhas em texto claro, consegue capturar dados enviados em métodos interativos de login e ganha a capacidade de ler ou adulterar os comandos e configurações direcionados ao dispositivo final. Como o Ansible salva a chave do atacante no arquivo known_hosts, as execuções futuras continuam confiando na identidade maliciosa.
A origem do problema no código do pylibssh
A falha técnica nasce de uma conversão inadequada de estados de conexão dentro do pacote pylibssh, responsável por conectar a biblioteca escrita em linguagem C (libssh) ao ambiente Python do Ansible.
O protocolo libssh possui três alertas distintos para a identidade de um host: chave alterada (SSH_KNOWN_HOSTS_CHANGED), tipo de chave diferente (SSH_KNOWN_HOSTS_OTHER) e host desconhecido (SSH_KNOWN_HOSTS_UNKNOWN). No entanto, o código do pylibssh consolida esses três estados e os envia para a política de validação utilizando apenas uma mensagem de texto, omitindo o código técnico original da biblioteca libssh.
A política de validação do plugin ansible.netcommon foi desenhada originalmente para lidar apenas com hosts desconhecidos, baseada em uma arquitetura herdada do Paramiko (uma biblioteca SSH mais antiga e agora preterida em favor do libssh). Como a política recebe apenas um aviso em texto em vez do estado específico, ela trata a chave alterada como se fosse um host novo e autoriza a adição ao arquivo known_hosts de forma silenciosa.
O comportamento diverge das práticas estabelecidas de segurança. A documentação da própria libssh recomenda interromper a conexão diante de chaves alteradas. Ferramentas como o OpenSSH, mesmo quando configuradas com a diretiva accept-new para aceitar novos hosts automaticamente, recusam conexões com servidores conhecidos que apresentam chaves divergentes.
O erro de validação no prompt interativo
A pesquisa de segurança, conduzida por Satriyo Utomo, revelou uma falha secundária no modo interativo do Ansible. Quando a ferramenta é executada manualmente com as configurações padrão e exibe o prompt avisando sobre a mudança de chave do servidor, pressionar a tecla Enter resulta em uma resposta vazia. O sistema interpreta essa ausência de caractere como uma confirmação positiva (equivalente a digitar “yes”), aceitando a nova chave em vez de abortar o processo.
Como verificar a exposição e mitigar o risco
Até o momento da divulgação pública do CVE (12 de novembro de 2026), não existiam atualizações de software com a correção definitiva. A plataforma Ansible Automation Platform 2 e os pacotes python-ansible-pylibssh estão listados como vulneráveis. A segurança da infraestrutura depende de ajustes manuais por parte dos administradores.
A exposição exige condições específicas. O controlador só está vulnerável se a variável de ambiente ANSIBLE_LIBSSH_HOST_KEY_AUTO_ADD estiver configurada como verdadeira, se a diretiva host_key_auto_add estiver habilitada na seção libssh_connection, ou se a classe AutoAddPolicy for utilizada diretamente no pylibssh.
As recomendações de segurança incluem:
- Desabilitar a confiança automática: Remover qualquer configuração que ative a adição autônoma de chaves no plugin libssh (host_key_auto_add e AutoAddPolicy).
- Manter a verificação ativa: Garantir que o parâmetro host_key_checking permaneça ativado no ambiente.
- Popular o known_hosts externamente: Em vez de delegar o registro ao Ansible, utilizar o utilitário ssh-keyscan a partir de um segmento de rede seguro para pré-configurar as identidades dos servidores.
- Atenção ao terminal: Não utilizar a tecla Enter para responder a prompts de verificação de chave SSH em execuções interativas.
