Se você usa sshd no Alpine Linux, atualize openssh e reinicie sshd: em sistemas afetados, qualquer um que chegue à porta SSH pode entrar sem a senha, em uma única tentativa. O Alpine publicou pacotes corrigidos para edge e nove branches estáveis em 5 de novembro de 2026, o mesmo dia em que o OpenSSH lançou a versão 10.6p2.
No momento da publicação desta nota, nenhum identificador CVE havia sido atribuído, e nem o Alpine nem o OpenSSH indicaram uma versão corrigida do musl. Os scanners guiados por CVE podem não detectá-lo ainda.
Sou afetado pela vulnerabilidade de OpenSSH no Alpine?
Você é afetado apenas se todas as quatro condições forem atendidas simultaneamente:
sshdvem do pacoteopenssh-server(compilado sem PAM), ou deopenssh-server-pamcomUsePAM no.PasswordAuthenticationestá ativado, que é o padrão do OpenSSH.- Pelo menos uma conta tem
*no campo de senha. É mais comum do que parece: o Alpine distribuirootcomoroot:*desde aproximadamente a 3.16, e também contam usuários que só entram com chave, usuários de serviços de diretório sem entrada em shadow e o usuárioalpinedas imagens tiny-cloud. - Pelo menos uma outra conta tem um hash de senha
$5$ou$6$.
As versões afetadas são edge e da 3.16 a 3.24.
| Situação | Afetado? |
|---|---|
Contêiner que não executa sshd |
Não |
PasswordAuthentication no |
Não |
openssh-server-pam com UsePAM yes |
Não |
Contas bloqueadas (! no campo de senha) |
Não |
Nenhum hash com formato $ em todo o sistema |
Não |
Imagens com cloud-init que definem PasswordAuthentication no |
Não |
Para revisar as duas últimas condições, abra /etc/shadow: o segundo campo de cada linha é a senha. * significa sem senha, ! significa conta bloqueada (não afetada) e um valor que começa com $5$ ou $6$ é um hash. Como root:* vem por padrão, na prática a pergunta é se algum usuário do servidor tem uma senha real configurada.
Como corrigir o bypass de senha de OpenSSH no Alpine?
Com dois comandos:
apk upgrade -U -a
rc-service sshd restart
O reinício não é opcional. Atualizar o pacote não substitui o daemon que já está em execução.
Estas são as versões corrigidas de openssh por branch:
| Branch | Versão corrigida de openssh |
|---|---|
| edge | 10.6_p2-r0 |
| 3.24 | 10.3_p1-r2 |
| 3.23 | 10.2_p1-r1 |
| 3.22 | 10.0_p1-r11 |
| 3.21 | 9.9_p2-r1 |
| 3.20 | 9.7_p1-r6 |
| 3.19 | 9.6_p1-r3 |
| 3.18 | 9.3_p2-r4 |
| 3.17 | 9.1_p1-r7 |
| 3.16 | 9.0_p1-r6 |
A 3.21 deixou de ter suporte em 1º de novembro de 2026, mas o Alpine mesmo assim publicou pacotes corrigidos para todas as versões até a 3.16.
Afeta as imagens cloud do Alpine Linux?
Sim, e são o caso mais arriscado. As imagens tiny-cloud oficiais da 3.18.11 a 3.24.3 trazem um usuário alpine com senha * e doas sem senha. São seguras no primeiro arranque, mas assim que existe qualquer hash $6$ na instância, o bypass funciona, e o doas sem senha converte esse acesso em root.
As imagens geradas a partir das versões corrigidas (3.21.10, 3.22.8, 3.23.8 e 3.24.4) e posteriores já incluem a correção. As instâncias lançadas a partir de imagens anteriores precisam da atualização ou da mitigação da próxima seção, uma por uma.
E se não conseguir atualizar? Como desativar a autenticação por senha em SSH
Desative a autenticação por senha e deixe SSH apenas com chave. Antes de começar, confirme que o acesso com chave funciona e mantenha aberta sua sessão atual, para que um erro não o deixe de fora.
Este é o bloco do aviso do Alpine:
mkdir -p /etc/ssh/sshd_config.d
echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
sed -i.bak -e '1i PasswordAuthentication no' \
-e 's/^\(\s*PasswordAuthentication[^y#]*\)yes/\1no/i' \
/etc/ssh/sshd_config
sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthentication
O último comando deveria mostrar passwordauthentication no.
O arquivo drop-in só tem efeito a partir da 3.19, que é quando a configuração padrão do Alpine começa a ler /etc/ssh/sshd_config.d/. Por isso o bloco também edita diretamente /etc/ssh/sshd_config: insere o ajuste no início e muda para no qualquer linha PasswordAuthentication yes existente, incluindo as que estão dentro de blocos Match. O original fica guardado como sshd_config.bak.
Como saber se alguém já entrou?
Busque em /var/log/messages linhas de sshd com Accepted password for em contas que não têm senha: alpine, root ou seus usuários que só entram com chave. Um acesso com senha a uma conta sem senha é a assinatura deste ataque.
Nas máquinas expostas, revise também o uso de doas, os usuários e arquivos criados recentemente e todos os authorized_keys. Se não conseguir descartar um acesso, trate a máquina como comprometida.
O que é Alpine Linux e o que tem a ver com musl?
O Alpine Linux é uma distribuição leve muito usada como imagem base de contêineres e em instâncias cloud, que gerencia seus pacotes com apk. Diferentemente da maioria das distribuições, usa musl como biblioteca C em vez de glibc, e é isso que importa aqui: o OpenSSH descreve os sistemas afetados como alguns Linux compilados sem suporte de PAM, em particular os que usam musl libc. Por isso esse fallo, que em inglês circula como “Alpine openssh password authentication bypass”, é um problema do Alpine e não de qualquer servidor com OpenSSH.
Por que uma senha longa entra sem a real?
O fallo está no musl, não na lógica própria de sshd. Sem PAM, sshd verifica uma senha passando a tentativa por crypt() e comparando o resultado com o campo guardado. Para uma conta cujo campo é muito curto para conter um salt, como *, sshd toma emprestado o salt de outra conta, e por isso tem que existir um hash $5$ ou $6$ em algum lugar do sistema.
O crypt() do musl retorna * como indicador de erro quando a chave supera os 256 bytes. * é também exatamente o que se guarda para uma conta sem senha, então a comparação coincide e o acesso é concedido. Ao invasor basta enviar uma senha de entre 257 e 1024 bytes.
Os mantenedores do OpenSSH consideram que a causa de fundo está fora de sshd, mas que se pode evitar de dentro, e é isso que faz a 10.6p2. Os pacotes dos branches estáveis do Alpine incluem um patch com o mesmo efeito. O fallo foi reportado por Özgün Kültekin, de Wakefield. As notas da 10.6p2 também indicam que o OpenSSH publicará versões com mais frequência por enquanto, porque os relatórios assistidos por IA estão trazendo à luz fallos que outros encontram de forma independente.
E você? Qual é a primeira coisa que revisa quando sai um aviso de segurança sem CVE?
- Apenas com chave (
PasswordAuthentication no) - Ainda com senha
- Não uso sshd no Alpine
- Prefiro outra opção (nos conte qual)
Comente abaixo ou, se este artigo chegou via email, responda diretamente ao email: sua resposta é publicada aqui.
Relacionado: axios Comprometido no npm: O Que Todo Dev JS Precisa Verificar Agora