Falha do OpenSSH permitia entrar em contas sem senha em sistemas com musl
Correção libera OpenSSH 10.6p2 e pacotes atualizados do Alpine; administradores devem reiniciar o sshd após instalar o patch.
Vários fornecedores e o próprio OpenSSH publicaram correções em 5 de novembro de 2026. Para eliminar a vulnerabilidade é preciso instalar o OpenSSH 10.6p2 ou os pacotes corrigidos do Alpine Linux e, em seguida, reiniciar o sshd em execução.
A exploração bem-sucedida exigia quatro condições específicas: uma compilação do OpenSSH sem PAM, PasswordAuthentication ativado, pelo menos uma conta cujo campo de senha em /etc/shadow fosse um único asterisco (*) e pelo menos uma conta local com hash de senha do tipo $5$ ou $6$.
O problema ocorria porque a função crypt() da biblioteca musl passa a retornar "*" para erros de hashing quando a senha tem mais de 256 bytes. Quando não havia salt disponível, o sshd pegava o salt de outra conta e comparava o resultado; ambos retornavam "*", permitindo o login imediato.
Como medida temporária, caso não seja possível atualizar de imediato, defina PasswordAuthentication no e reinicie o sshd. Também verifique /var/log/messages por entradas como "Accepted password" em contas que deveriam ser sem senha; trate qualquer caso incerto como possível comprometimento.
A origem do bug remonta a mudanças no musl em 2012 e a uma alteração no OpenSSH em 2016 para sempre fazer hashing das tentativas. Equipes de segurança avisam que varreduras oportunistas e tentativas de brute force usando senhas muito longas provavelmente aparecerão em breve, à medida que atacantes incluírem essa checagem em ferramentas automatizadas.