CVE-2026-123158 (SSHole): uma senha longa entra por SSH em alguns servidores Alpine Linux

O que a falha faz

O Alpine e algumas outras distribuições Linux pequenas usam a musluma biblioteca C compacta que fornece as funções básicas usadas pelos programas; a maioria das grandes distribuições usa a glibc e compilam o OpenSSH sem PAMum sistema do Linux que cuida dos logins; com ele, o sshd entrega a verificação da senha a um módulo separado. Nessa configuração, o próprio sshd confere a senha: ele calcula o hash do que o usuário digitou e compara com o hash guardado para a conta.

Contas sem senha, como o root nas imagens recentes do Alpine ou usuários que só entram com chave SSH, guardam um único * nesse campo. Segundo uma análise técnica da empresa de segurança Ostorlab, a musl desiste de senhas com mais de 256 bytes e devolve o texto * como sinal de erro. O sshd então compara esse * com o * guardado, vê que são iguais e deixa a pessoa entrar. O registro CVE descreve o mesmo problema de forma mais curta, como uma interpretação errada de "se uma string deve ser um hash de senha".

O OpenSSH diz que considera a causa principal "fora do próprio OpenSSH", mas que consegue bloquear o desvio no sshd. A correção faz o sshd rejeitar hashes guardados com menos de quatro caracteres, então um * sozinho nunca mais combina.

Quem é afetado

O alerta do Alpine lista quatro condições que precisam valer ao mesmo tempo:

1. O sshd roda sem PAM: o pacote openssh-server, ou o openssh-server-pam com UsePAM no.
2. PasswordAuthentication está em yes, o padrão do OpenSSH.
3. A máquina tem uma conta cujo campo de senha é *. No Alpine isso inclui o root (na imagem base desde mais ou menos a versão 3.16), usuários que só entram com chave, usuários de serviços de diretório como sssd ou winbind e o usuário alpine das imagens tiny-cloud.
4. Pelo menos uma conta local tem um hash de senha de verdade do tipo $5$ ou $6$.

Entrar direto como root também exige PermitRootLogin yes, mas o Alpine avisa que o doas pode abrir outro caminho até o root. Contas bloqueadas (! no campo de senha) não são afetadas, nem contêineres Docker que não rodam o sshd.

Qual é a gravidade

O registro CVE, escrito pela MITRE como CNACVE Numbering Authority, organização autorizada a criar IDs de CVE e escrever a descrição oficial, dá nota 8,1 (Alta) no CVSS 3.1, com o vetor AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. O OpenSSH classifica o problema como crítico. O Alpine é mais direto: quem alcança a porta SSH precisa de uma conexão e de uma senha longa, e "funciona sempre" quando as condições estão presentes.

Os ataques até agora

Códigos de demonstração apareceram no GitHub logo depois do lançamento, e a avaliação da CISA no registro CVE indica prova de conceito pública. Até 8 de novembro, a falha não está no catálogo de vulnerabilidades exploradas da CISA.

Duas empresas que mantêm sensores na internet publicaram o que estão vendo. A GreyNoise marcou a primeira tentativa em 5 de novembro, às 18h34 UTC, e diz ter confirmado a exploração bem-sucedida dos seus próprios sistemas-isca, deixados vulneráveis de propósito, a partir de 7 de novembro, com 14 ações depois do login vindas de quatro endereços. A Previdian contou 19 tentativas de 12 endereços em 8 países até 8 de novembro, mas avisa que os seus dados não mostram se alguma deu certo. Nenhuma das duas relatou uma organização real atingida.

O desenvolvedor do OpenSSH Damien Miller escreveu que a equipe soube do problema só na véspera do lançamento e correu porque agentes de IA hoje redescobrem falhas publicadas "em poucas horas".

O que fazer agora

1. No Alpine, rode apk upgrade -U -a e depois rc-service sshd restart. O Alpine ressalta que só atualizar não substitui o sshd que já está rodando. As versões 3.21.10, 3.22.8, 3.23.8 e 3.24.4 já trazem a correção.
2. Em outros sistemas Linux com musl e sem PAM, passe para o OpenSSH 10.6p2 ou para o pacote corrigido da sua distribuição.
3. Se ainda não der para atualizar, defina PasswordAuthentication no. Antes, confirme que o login com chave SSH funciona, mantenha uma sessão aberta durante a mudança e confira com sshd -T | grep -i passwordauthentication. O nosso guia passo a passo para trocar a senha do SSH por chaves mostra como fazer isso sem ficar trancado do lado de fora.
4. Procure sinais de invasão. O Alpine sugere buscar em /var/log/messages por "Accepted password for" em contas sem senha, como root, alpine ou usuários que só usam chave, e revisar o uso do doas, usuários novos e os arquivos authorized_keys. Se não der para descartar um login, trate a máquina como comprometida.
5. Se você gera imagens de contêiner que rodam o sshd, recrie-as a partir de uma base do Alpine atualizada e recrie os contêineres.

É o segundo desvio de login da semana: nos firewalls da SonicWall, uma falha na VPN deixa atacantes pularem o SAML e a autenticação em dois fatores.