Hackers exploram nova falha do OpenSSH apelidada de «SSHole» para invadir sistemas Alpine Linux

Os invasores começaram a explorar uma falha recém-divulgada no OpenSSH que permite burlar a autenticação horas após a publicação de uma prova de conceito (PoC), e a primeira invasão bem-sucedida confirmada ocorreu apenas 40 horas após o lançamento da correção. A vulnerabilidade, catalogada como CVE-2026-123158 e apelidada de «SSHole», permite que um invasor faça login em contas que deveriam ter a autenticação por senha completamente desativada.

O bug está na forma como o OpenSSH interage com a musl libc, a biblioteca C leve usada pelo Alpine Linux e outras distribuições mínimas que dominam as imagens base de contêineres em plataformas de nuvem. Quando uma tentativa de login usa uma senha de tamanho excessivo, a função de hash de senha da musl retorna um erro representado por um único caractere, «*» — o mesmo valor de marcador armazenado no arquivo shadow para contas com login por senha desativado. O OpenSSH trata essa correspondência como válida, abrindo assim uma forma de acesso a contas que nunca deveriam ser alcançáveis por senha.

Explorar essa falha exige uma configuração específica — sistemas baseados em musl com autenticação PAM desativada — portanto nem todos os servidores Linux estão expostos. Mas a leveza do Alpine o tornou a imagem base padrão de uma enorme parcela dos contêineres Docker e cargas de trabalho Kubernetes, o que significa que essa configuração afetada é muito mais comum em infraestruturas cloud-native do que a pontuação de severidade CVSS de 8,1 sugere por si só. O acesso root se torna possível se a conta comprometida tiver privilégios administrativos sem senha.

A equipe do OpenSSH lançou uma correção na versão 10.6p2 em 5 de novembro. Uma prova de conceito pública apareceu no mesmo dia, e as tentativas de exploração começaram quase imediatamente. Segundo a empresa de inteligência de ameaças GreyNoise, a primeira invasão bem-sucedida confirmada no mundo real ocorreu em 7 de novembro às 00h46 UTC — cerca de um dia e meio após o lançamento da correção —, com 16 cadeias de exploração bem-sucedidas rastreadas até seis endereços IP de origem, números que a GreyNoise adverte provavelmente subestimam o alcance real da atividade. Já pesquisadores da Previdian registraram 20 tentativas de exploração a partir de 13 endereços IP em nove países, enquanto a WatchTower associou parte dessa atividade a operações existentes de botnets e mineração de criptomoedas. A Defused relatou um número menor de agentes distintos, com atividade limitada subsequente.

Uma vez dentro, os invasores foram observados executando comandos de reconhecimento, consultando serviços de metadados em nuvem (uma técnica comum para coletar credenciais de nuvem), tentando ler hashes de senhas e chaves SSH root, e modificando arquivos authorized_keys para manter acesso persistente. Em pelo menos um caso, um invasor implantou uma ferramenta personalizada de comando e controle em Python chamada TAC Agent — embora, nesse caso, o implante nunca tenha recebido instruções porque seu servidor C2 estava inacessível, segundo a BleepingComputer.

O intervalo de aproximadamente 40 horas entre o lançamento da correção e a exploração confirmada no mundo real está em linha com um padrão que pesquisadores de segurança têm apontado repetidamente ao longo de 2026: assim que uma prova de conceito para uma falha de burla de autenticação é publicada, a varredura em massa e a exploração geralmente começam dentro de um a dois dias, deixando aos defensores uma janela muito estreita para corrigir antes da chegada de ataques automatizados.

Administradores de sistemas baseados em musl, especialmente implantações do Alpine Linux em ambientes de contêiner ou nuvem, devem atualizar para o OpenSSH 10.6p2 imediatamente. Quando a correção imediata não for possível, desativar completamente a autenticação por senha no SSH fecha essa brecha. As equipes de segurança também devem auditar os registros em busca de logins por senha bem-sucedidos inesperados em contas cujo campo de senha no shadow esteja definido como asterisco, verificar entradas não autorizadas em arquivos authorized_keys e procurar qualquer vestígio do TAC Agent ou de serviços de inicialização desconhecidos semelhantes.