Em 5 de novembro de 2026, o OpenSSH lançou a versão 10.6p2 com uma correção para um bypass de autenticação que afeta configurações específicas de OpenSSH com musl e sem PAM. Na Alpine, é preciso instalar a revisão corrigida correspondente ao ramo e reiniciar o sshd: atualizar o pacote, por si só, não substitui o daemon em execução. (OpenSSH; aviso da Alpine)
Na Alpine, a atualização só passa a valer para o serviço depois que o sshd é reiniciado.
Quais condições permitem o bypass
O aviso da Alpine descreve uma combinação específica: um servidor OpenSSH usando musl, PAM desativado — por configuração (UsePAM no) ou por uma compilação sem PAM — e PasswordAuthentication yes. A conta-alvo precisa ter * no campo de senha, e outra conta local precisa ter um hash $5$ ou $6$. Nessas condições, uma senha de 257 a 1.024 bytes pode provocar a falha; a Alpine diz que basta uma conexão SSH, sem tentativas repetidas.
O PAM, ou Pluggable Authentication Modules, é uma estrutura que permite integrar métodos de autenticação ao sistema. Para essa falha, a configuração efetiva do servidor importa: uma conta que usa chaves SSH não significa, por si só, que a autenticação por senha esteja desativada globalmente.
Na configuração descrita pela Alpine, servidores com PasswordAuthentication no ou UsePAM yes não são afetados por esse bypass. O aviso também exclui contas cujo campo de senha contém ! e sistemas sem um hash local do tipo indicado. Contêineres que não executam sshd não atendem ao requisito do servidor SSH.
O OpenSSH atribuiu a causa raiz a algo externo ao sshd, embora tenha corrigido o caminho explorável pelo serviço. Rich Felker, autor do musl, caracterizou o caso como uso incorreto pelo programa chamador. (OpenSSH; aviso de Rich Felker)
Revisões corrigidas do OpenSSH na Alpine
A Alpine publicou revisões corrigidas para o ramo edge e para os ramos de versão 3.16 a 3.24. A revisão necessária depende do ramo instalado:
| Ramo da Alpine | Revisão corrigida do pacote openssh-server |
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 orientação da Alpine é atualizar os pacotes e reiniciar o serviço:
apk upgrade -U -a
rc-service sshd restart
Se não for possível aplicar a atualização, a Alpine indica desativar a autenticação por senha com PasswordAuthentication no e reiniciar o sshd. Sem a reinicialização, o processo antigo continua em execução.
Quando as imagens tiny-cloud podem ficar expostas
A Alpine identifica artefatos oficiais tiny-cloud, nas versões 3.18.11 a 3.24.3, com uma conta alpine cujo campo de senha contém * e que pode usar doas sem senha. Segundo o aviso, essas imagens são seguras na primeira inicialização. As condições de exposição podem surgir depois que houver um hash $6$ na máquina, desde que os demais requisitos do bypass também coincidam. Uma autenticação bem-sucedida nessa conta pode permitir acesso root por meio do doas sem senha.
O que verificar nos registros
A Alpine recomenda procurar em /var/log/messages entradas Accepted password para contas que deveriam não ter senha e revisar o doas, as contas de usuário, os arquivos e as chaves autorizadas. Se não for possível descartar um acesso indevido, a orientação é tratar o sistema como comprometido.
