Ing. Calogero Bono
Em 5 de novembro de 2026 saiu o OpenSSH 10.6p2, que corrige um bug apelidado de «*sshole». Ele afeta servidores SSH em Linux que usam a biblioteca musl, como o Alpine Linux, com o PAM desativado. Quem chega à porta SSH consegue entrar em uma conta sem senha enviando uma senha muito longa. Isso importa porque basta uma conexão e porque as imagens oficiais de nuvem do Alpine podem dar acesso como root.
Alguns termos, antes de entrar nos fatos. musl é uma biblioteca C alternativa à glibc, usada pelo Alpine, OpenWrt, Buildroot e Yocto. crypt() é a função que transforma uma senha no seu hash. PAM é o sistema modular de autenticação do Linux. /etc/shadow é o arquivo que guarda os hashes das senhas. doas é a ferramenta, parecida com o sudo, para obter privilégios de root.
Como funciona o bug *sshole?
Uma conta Linux sem senha tem um asterisco no lugar do hash em /etc/shadow. Nenhuma senha deveria abri-la. Segundo a BleepingComputer, uma mudança na OpenSSH de 2016, criada para corrigir a CVE-2016-6210 sobre enumeração de usuários, faz o cálculo do hash também para essas contas.
Aqui entra a musl. Como explica o aviso do Alpine, a crypt() da musl retorna * como sinal de erro se a chave passar de 256 bytes. Esse asterisco coincide com o salvo na conta, e a comparação dá certo. O pesquisador Özgün Kültekin diz que a falha existe desde 2016.
Quem corre risco de verdade?
São necessárias várias condições juntas. Segundo o Alpine, o pacote openssh-server é compilado sem PAM, ou se usa o openssh-server-pam com UsePAM no. O PasswordAuthentication precisa estar ativo, como no padrão. É preciso uma conta com * e pelo menos outra com hash $5$ ou $6$. Basta um único usuário com senha para tornar acessíveis todos os outros.
O Alpine verificou as versões da 3.21 à 3.24 e edge, além das antigas 3.16 a 3.20. Não são afetados contêineres sem sshd, sistemas com PasswordAuthentication no e sistemas com PAM ativo. Debian, Ubuntu e Fedora, que usam a glibc, não são vulneráveis, segundo a BleepingComputer.
Por que as imagens de nuvem do Alpine preocupam?
As imagens oficiais tiny-cloud, da 3.18.11 à 3.24.3, têm um usuário alpine com senha * e doas sem senha. O Alpine esclarece que elas são seguras no primeiro boot. Tornam-se exploráveis quando aparece um hash $6$, por exemplo se um administrador define uma senha de console ou se o user-data adiciona um usuário com hashed_passwd.
Nesse ponto o atacante obtém um shell como alpine e, com o doas, vira root. As imagens configuradas com cloud-init, que grava PasswordAuthentication no, não são atingidas. Para o root, o padrão PermitRootLogin prohibit-password o protege apenas de forma direta.
Como corrigir e como verificar um ataque?
A correção está na OpenSSH 10.6p2. No Alpine, use apk upgrade -U -a e depois reinicie o sshd, porque a atualização não substitui o daemon em execução. O Alpine publicou pacotes corrigidos até a 3.16, inclusive para versões que não têm mais suporte.
Se não puder atualizar, defina PasswordAuthentication no e reinicie o sshd, depois de confirmar que o acesso com chave funciona. Para procurar vestígios, verifique em /var/log/messages as linhas «Accepted password» para contas sem senha. O Alpine acrescenta que, se você não puder descartar um acesso, a máquina deve ser considerada comprometida. Para as permissões das contas, vale também o guia sobre permissões no Linux.
Limites a conhecer
O Alpine informa que, no momento da publicação, nenhum CVE tinha sido atribuído. A OpenSSH escreve que a causa está fora do sshd, mas é explorável através do sshd e é lá que ela é evitada. Não há dados sobre ataques reais em andamento. As afirmações sobre os 17.600 testes com agentes de IA vêm do pesquisador, relatadas pela BleepingComputer, e não foram verificadas de forma independente.
O que muda para quem trabalha com tecnologia
Se você administra servidores Alpine, roteadores OpenWrt ou sistemas embarcados com Yocto e Buildroot, verifique se o sshd aceita senhas e se há contas com *. Muitos usam o Alpine em contêineres sem sshd e não são afetados. Quem mantém máquinas na nuvem com as imagens tiny-cloud deve verificar cada instância já em execução. Um servidor gerenciado com atualizações regulares reduz esse tipo de risco, falamos disso na página sobre hospedagem e servidores gerenciados. Também vale acompanhar o caso relacionado dos exploits gerados por IA, sobre o qual escrevemos em este artigo.
Nossa opinião
O caso mostra como é frágil a fronteira entre componentes que confiam uns nos outros. A OpenSSH acrescentou uma defesa legítima em 2016, a musl escolheu um valor de erro comum, e juntos abriram uma porta por dez anos. Também chama a atenção que o bug foi encontrado com agentes de IA. A própria OpenSSH avisa que bugs descobertos com IA costumam ser redescobertos por outras pessoas, então esperar é um risco. A solução mais sólida continua sendo a de sempre – chaves no lugar de senhas.
Perguntas frequentes
Debian e Ubuntu são vulneráveis ao *sshole?
Não. Eles usam a glibc e não a biblioteca musl. A BleepingComputer confirma que sistemas com autenticação PAM não são vulneráveis, mas o Alpine esclarece que o openssh-server-pam com UsePAM no não é, enquanto com UsePAM yes não é.
Basta atualizar o pacote openssh?
Não, é preciso também reiniciar o sshd. O Alpine explica que a atualização não substitui o daemon já em execução, então a versão vulnerável continuaria ativa.
Posso me proteger sem atualizar?
Sim, de forma temporária. Defina PasswordAuthentication no na configuração do sshd e reinicie o serviço. Antes, confirme que o acesso com chave funciona.
O root também está exposto?
Só em alguns casos. Com PermitRootLogin prohibit-password, o valor padrão, o root não é alcançável diretamente. Ele passa a ser se o PermitRootLogin yes estiver ativo ou se outro usuário puder virar root, por exemplo com o doas.
Existe um CVE para este bug?
Ainda não, segundo o Alpine. O aviso diz que, no momento da redação, nenhum identificador tinha sido atribuído. A referência são as notas de versão da OpenSSH 10.6p2.
O que acompanhar depois da OpenSSH 10.6p2
A OpenSSH anunciou lançamentos mais frequentes para levar as correções aos usuários mais depressa. O bug deixa algumas questões em aberto que vale acompanhar.
- Verifique se será atribuído um CVE e se suas ferramentas de varredura vão reconhecê-lo.
- Acompanhe quando os fabricantes de firmware baseados em OpenWrt, Buildroot e Yocto publicarão atualizações.
- Prepare uma rotina para instalar as versões menores da OpenSSH sem esperar as versões programadas.
