O cenário de pesadelo perfeito para um servidor Linux é quando tudo o que um atacante precisa é alcançar a porta Secure Shell (SSH) do servidor, entrar sem cerimônia e assumir o controle. Foi o que aconteceu com o Alpine Linux, o popular servidor Linux leve. Para piorar, isso ocorreu apenas alguns dias depois de o Alpine Linux ter desviado por pouco de uma bala do tamanho de um buraco de segurança em sua implementação do GitLab.

Como explicou o engenheiro de segurança Gregory Bryant em sua postagem no LinkedIn: "A maioria dos bypasses de autenticação vem de cadeias lógicas complexas, mas a vulnerabilidade do OpenSSH do Alpine Linux de ontem (CVE-2026-123158) se resume a um único caractere: *."

Se você executa o Alpine Linux (ou outra distro baseada em musl) com o pacote openssh-server padrão (sem Pluggable Authentication Modules, ou PAM) e PasswordAuthentication habilitado, um atacante pode fazer login em contas com senha desabilitada, ou somente com chave, simplesmente enviando uma senha entre 257 e 1024 bytes.

O Alpine Linux não é o único sistema operacional que usa musl, uma versão leve da biblioteca C padrão (libc). Outros sistemas operacionais que usam musl e são potencialmente vulneráveis incluem Adélie Linux; Void Linux; Sabotage Linux; OpenWrt, uma variante do Android; e o Yocto Project, usado para construir distribuições Linux embarcadas.

A Wind River, que produz a distro Linux embarcada comercial Wind River Linux, também está investigando o problema. Um representante da empresa me disse: "A Wind River leva a segurança a sério. Estamos revisando ativamente a vulnerabilidade relatada e avaliando seu impacto potencial. Tomaremos as medidas apropriadas conforme necessário."

Nos bastidores, quando o OpenSSH é compilado sem PAM, ele verifica senhas fazendo o hash da tentativa de senha usando a função crypt() da biblioteca C. Em seguida, compara o resultado com o campo de senha armazenado da conta. Até aí, tudo bem.

Mas quando uma chave tem mais de 256 bytes, a função crypt() do musl retorna a string * como indicador de erro. Isso também é o que o campo de senha contém para qualquer conta sem senha, como uma conta somente com chave. Assim, o "hash" corresponde e o login é bem-sucedido, e o atacante entra.

Para explorar isso, um atacante só precisa do nome de tal conta. O atacante também precisa de pelo menos outra conta na máquina com um hash de senha de 5 ou 6, e então enviar uma senha de 257 a 1.024 bytes. De acordo com o Alpine, um usuário com senha é suficiente para tornar todas as contas sem senha acessíveis.

Em sistemas Linux que usam crypt() do glibc, que são quase todos, a mesma tentativa retornaria NULL em caso de erro, o que o sshd já rejeita, então Debian, Ubuntu, Fedora, etc., não são afetados.

De acordo com *sshole, o grupo que descobriu o problema, este é um efeito colateral que está escondido desde 2016.

O Alpine disse que todas as versões que verificou são afetadas: 3.21 até 3.24, edge, e os ramos mais antigos 3.16 a 3.20. A exposição requer o seguinte:

O root não é diretamente exposto na maioria dos casos. Ele é distribuído como root:* na imagem base desde cerca de Alpine 3.16, mas o padrão PermitRootLogin prohibit-password do OpenSSH o bloqueia. Outra conta que pode se tornar root, por exemplo através do doas, ainda dá ao atacante uma rota para o root.

O Alpine destacou suas imagens oficiais tiny-cloud, versões 3.18.11 até 3.24.3, como especialmente vulneráveis. Elas vêm com um usuário alpine com campo de senha * e doas sem senha. Elas são seguras na primeira inicialização, mas se tornam exploráveis assim que qualquer hash 6 existir na máquina. Isso pode acontecer quando um administrador define uma senha de console ou quando dados do usuário adicionam um usuário com senha com hash, o que significa, essencialmente, todas elas.

O Alpine lançou 3.21.10, 3.22.8, 3.23.8 e 3.24.4 na quinta-feira, com a correção do OpenSSH entre as mudanças de segurança. Também publicou pacotes corrigidos para cada versão desde a 3.16. O Alpine 3.21 chegou ao fim do suporte em 1º de novembro.

O recém-lançado OpenSSH 10.6p2 evita o problema no sshd. Os ramos estáveis do Alpine carregam um patch para o mesmo problema. Você deve executar apk upgrade -U -a e então reiniciar o th