Falha no OpenSSH que libera acesso sem senha a servidores Linux já é explorada por hackers
Vulnerabilidade SSHole atinge sistemas com a biblioteca musl e sem PAM, como o Alpine; correção saiu em 5 de novembro e empresas de segurança já relatam invasões.
Uma falha no OpenSSH, o programa mais usado no mundo para acesso remoto seguro a servidores Linux, passou a ser explorada por criminosos poucas horas depois de se tornar pública. Batizada de SSHole e registrada como CVE-2026-123158, a vulnerabilidade permite entrar sem senha em contas que deveriam estar bloqueadas para login por senha, inclusive a de administrador (root), em parte dos sistemas Linux. A correção já existe desde quinta-feira (5), mas empresas de segurança relatam ataques bem-sucedidos e, nesta segunda-feira (9), a GreyNoise descreveu invasões que considera "maduras" contra servidores-isca que mantém no Sudeste Asiático.
Quem está exposto
O problema não atinge qualquer servidor com OpenSSH. Ele aparece quando o programa roda sobre a musl, uma biblioteca alternativa à glibc, mais comum, e sem o PAM, o módulo que costuma cuidar da autenticação no Linux. Essa combinação é o padrão do pacote de servidor SSH do Alpine Linux, distribuição enxuta muito usada em contêineres Docker e máquinas na nuvem. O pesquisador que descobriu a falha, Özgün Kültekin, da Wakefield, também recomenda verificar sistemas embarcados construídos com OpenWrt, Buildroot e Yocto, além de imagens de contêiner baseadas em musl.
A falha mira contas que têm um asterisco no lugar do hash de senha no arquivo /etc/shadow, configuração comum para impedir login por senha. Ao receber uma senha gigante, entre 257 e 1.024 caracteres, a função de hash da musl dá erro e devolve justamente um asterisco. O OpenSSH interpretava esse retorno como uma senha correta e liberava o acesso. Contas com senha válida não são afetadas, e a gravidade foi classificada em 8,1 de 10 na escala CVSS.
Exploração em poucas horas
O projeto OpenSSH publicou a versão 10.6p2 com a correção em 5 de novembro. Segundo relatos de empresas de segurança, um código de ataque de demonstração circulou cerca de quatro horas depois, e as primeiras tentativas surgiram no mesmo dia. A Previdian afirma ter confirmado acesso de root a um servidor-isca com Alpine e contabilizou, até domingo (8), 20 tentativas vindas de 13 endereços IP em nove países. A watchTowr disse ter visto a falha sendo usada por redes de máquinas infectadas (botnets) e por mineradores de criptomoedas.
A GreyNoise registrou a primeira exploração bem-sucedida em 7 de novembro, às 0h46 UTC (20h46 de 6 de novembro no horário de Cuiabá), cerca de 40 horas após a correção, e diz ter observado 16 cadeias de ataque completas a partir de seis endereços. Nessas invasões, os atacantes vasculharam o sistema e os contêineres, consultaram serviços de metadados da nuvem, tentaram ler hashes de senhas e chaves SSH do root e alteraram o arquivo authorized_keys para manter acesso. Em um caso, instalaram um programa de controle remoto em Python chamado TAC Agent, que não conseguiu falar com seu servidor de comando.
A empresa atribui parte da atividade a um grupo que identifica como GT10 e afirma que o código do TAC Agent tem comentários e mensagens em chinês, com indícios de ter sido escrito com ajuda de IA. A própria GreyNoise ressalva que o idioma é apenas um indício a ser somado a outras evidências para apontar origem e que seus sensores não representam todo o volume de ataques.
O que os administradores devem fazer
A orientação dos mantenedores e das empresas que acompanham os ataques é atualizar o OpenSSH para a versão 10.6p2 ou para o pacote corrigido da distribuição. O Alpine liberou atualizações para todas as versões mantidas, da 3.16 à edge, no mesmo dia da correção. Instalar o pacote não basta: o serviço sshd precisa ser reiniciado, senão o programa antigo continua aceitando conexões.
Onde a atualização não for imediata, a recomendação é desligar o login por senha no SSH (PasswordAuthentication no) ou o próprio serviço. Também vale procurar nos registros logins por senha bem-sucedidos em contas com asterisco no /etc/shadow, chaves SSH que ninguém autorizou e arquivos ou serviços de inicialização ligados ao TAC Agent. Máquinas em que não seja possível descartar a invasão devem ser tratadas como comprometidas.
Correções mais frequentes
Nas notas da nova versão, a equipe do OpenSSH explica que considera a causa raiz externa ao programa, mas que o defeito podia ser explorado por ele e por isso foi bloqueado ali. Os mantenedores também relatam um volume crescente de relatórios de falhas encontrados com ajuda de modelos de IA e casos em que o mesmo erro é descoberto de forma independente por pessoas diferentes. Como adversários que não reportam falhas provavelmente conseguem encontrá-las também, o projeto diz que passará a lançar correções com mais frequência, em vez de acumulá-las para a versão seguinte.
Racks de servidores em data center da Wikimedia Foundation, em julho de 2012; imagem ilustrativa. Foto: Victor Grigas, via Wikimedia Commons (CC BY-SA 3.0).
