*sshole: falha no Linux permite login via SSH sem senha em sistemas com OpenSSH e musl

A *sshole nasce na interação entre o OpenSSH e a musl, uma alternativa leve à libc usada no Alpine Linux. Para a exploração funcionar, o OpenSSH com musl não pode usar PAM. A conta alvo também precisa ter hash SHA256 ou SHA512 e estar configurada como sem senha, com "*" no campo de senha do /etc/shadow, algo comum em contas que usam autenticação por certificado. Nesse cenário, o atacante entra enviando mais de 256 caracteres no campo de senha. Segundo os mantenedores do Alpine, basta uma conexão, funciona sempre e dispensa novas tentativas.

A Checkpoint informou que o hash SHA256 ou SHA512 importa porque o sshd empresta o salt dessa conta, e que a conta precisa estar ativa. Contas root ficam protegidas com o padrão PermitRootLogin prohibit password, mas contas alcançáveis com direitos de doas ou sudo ainda podem virar root. A responsabilidade pela falha é disputada: o OpenSSH diz que a causa raiz está fora do sshd, enquanto Rich Felker, da musl, afirma que se trata de uso errado por parte de quem chama a função. OpenSSH e Alpine já lançaram atualizações, e não há CVE conhecido. OpenWRT, buildroot e yocto aparecem como possivelmente afetados, mas isso ainda não está confirmado.

Em 6 de novembro de 2026, o CEVIU noticiou "Falha no OpenSSH permite bypass de autenticação por senha em sistemas com musl sem PAM" e "Alpine Linux alerta para falha no openssh-server que permite burlar a autenticação por senha". A nova matéria consolida o caso sob o nome *sshole e acrescenta o alcance estimado, a disputa sobre a causa raiz e a lista de pacotes que ainda precisam de confirmação.

Para quem opera containers, roteadores ou dispositivos embarcados com Alpine, isso significa checar se há contas com "*" no shadow e se o sshd roda sem PAM. Em embarcados que quase não recebem atualização, o risco tende a durar mais. Em imagens de container, vale reconstruir com o Alpine e o OpenSSH corrigidos.