Falha no OpenSSH permite login sem senha no Alpine Linux: o que fazer agora

No dia 5 de novembro de 2026, o projeto OpenSSH lançou a versão Portable OpenSSH 10.6p2 para corrigir uma falha de bypass de autenticação por senha. A vulnerabilidade, registrada como CVE-2026-123158 e apelidada de “sshole” pelo pesquisador que a descobriu, permite que um atacante entre via SSH em certas contas sem conhecer a senha.

A boa notícia é que a falha só aparece em uma combinação específica de configuração. Por outro lado, essa combinação é o padrão em um sistema muito popular em servidores em nuvem e containers: o Alpine Linux. Abaixo explicamos quem é afetado e o que fazer agora.

O que é a falha

O SSH é o protocolo usado para administrar servidores Linux remotamente. Em muitos sistemas, contas que não devem aceitar login por senha (como o root no Alpine, ou usuários que só entram com chave) têm o caractere * no lugar da senha, no arquivo /etc/shadow. Por convenção, nenhuma senha digitada pode “bater” com esse valor.

Segundo o relato técnico do pesquisador Özgün Kültekin, o problema nasce de dois comportamentos que, isolados, faziam sentido:

• A biblioteca C musl (usada pelo Alpine) devolve o texto * quando não consegue calcular o hash de uma senha — por exemplo, quando a senha é longa demais.
• O sshd, quando não usa PAM, compara esse resultado com o valor guardado no /etc/shadow.

Resultado: uma senha propositalmente muito longa gera * como “hash”, que é exatamente o valor salvo nas contas bloqueadas para senha, e o login é aceito. As notas de versão do OpenSSH reconhecem que a causa raiz está fora do sshd, mas que ela é explorável por meio dele, e por isso a correção foi feita no próprio OpenSSH.

Quem é afetado

De acordo com o relato do pesquisador, todas as condições abaixo precisam ser verdadeiras:

• O sshd roda sobre a musl (Alpine Linux, OpenWrt, Buildroot, Yocto e muitas imagens de container);
• O sshd não usa PAM — que é o padrão do pacote openssh-server do Alpine;
• O login por senha está habilitado (também o padrão);
• Existe ao menos uma conta com * no lugar da senha e outra conta com uma senha real.

Ainda segundo o pesquisador, sistemas baseados em glibc (Debian, Ubuntu, Red Hat, Fedora), configurações com PAM, o Dropbear e o OpenBSD não são afetados. O relato também aponta que as imagens oficiais do Alpine para AWS e Azure eram vulneráveis por meio do usuário padrão, que tem permissão de administrador via doas sem senha.

A falha recebeu nota 8,1 (alta) no CVSS 3.1, conforme levantamento da SOC Prime.

Já está sendo explorada?

As informações ainda divergem. A Help Net Security relatou que a empresa de inteligência de ameaças Previdian detectou a primeira tentativa de ataque menos de nove horas após a publicação do CVE e confirmou acesso root em um honeypot com Alpine Linux. Até a data da reportagem, a falha não constava no catálogo de vulnerabilidades exploradas da CISA (KEV).

Também já circulam provas de conceito no GitHub. A mesma reportagem alerta que esses códigos não foram verificados e podem conter malware — não os execute em máquinas da empresa.

Na prática, trate a falha como urgente: o tempo entre a divulgação e as primeiras tentativas de ataque foi de horas, não de semanas.

O que fazer agora: checklist

1. Descubra se você tem sistemas com musl expostos via SSH. Verifique servidores, VPSs, appliances e containers que rodam Alpine (o arquivo /etc/alpine-release existe nesses sistemas). Não esqueça de imagens Docker que incluem um servidor SSH.

2. Atualize o OpenSSH e reinicie o serviço. No Alpine:

apk update && apk upgrade openssh
rc-service sshd restart

O rastreador de segurança do Alpine lista a versão corrigida para cada ramo (por exemplo, 10.6_p2-r0 no edge e 10.3_p1-r2 no 3.24). Confie na versão do pacote, não no banner do SSH: as correções foram aplicadas também em versões mais antigas. E lembre-se de reiniciar o sshd — até lá, o processo antigo continua aceitando conexões.

3. Se não puder atualizar agora, desligue o login por senha. Essa é a recomendação do pesquisador e, segundo a Help Net Security, também de Damien Miller, desenvolvedor do OpenSSH:

echo "PasswordAuthentication no" > /etc/ssh/sshd_config.d/00-no-password.conf
rc-service sshd restart

Antes, garanta que você tem acesso por chave SSH funcionando, para não se trancar fora do servidor.

4. Atualize suas imagens de container. Reconstrua as imagens a partir de uma base Alpine atualizada e publique novamente. Containers em execução não se atualizam sozinhos.

5. Procure sinais de invasão. Liste as contas que não deveriam aceitar senha e verifique se alguma delas teve login por senha aceito:

awk -F: '$2=="*" {print $1}' /etc/shadow
grep "Accepted password for" /var/log/messages

Um login por senha aceito em uma conta sem senha (como root ou um usuário que só usa chave) é um forte indício de exploração. Revise também usuários criados recentemente, os arquivos authorized_keys e o uso de doas/sudo.

6. Se houver indício de acesso, trate como incidente. Não basta atualizar: um atacante pode ter deixado chaves, usuários ou programas para voltar depois. Isole a máquina, preserve os logs e, se possível, reconstrua o servidor a partir de uma base limpa.

A lição para além desta falha

O sshole mostra como duas decisões razoáveis, tomadas em projetos diferentes e com anos de distância, podem se combinar em uma brecha séria. Por isso, algumas práticas reduzem o impacto da próxima falha, qualquer que seja ela:

• Use apenas chaves SSH para acesso administrativo e desligue o login por senha sempre que possível;
• Não exponha o SSH para toda a internet: restrinja por IP, VPN ou bastion;
• Mantenha um inventário de servidores e imagens, para saber rapidamente onde aplicar uma correção;
• Monitore os logs de autenticação e receba alertas de logins incomuns.

Se você não sabe ao certo quais servidores da sua empresa estão expostos, ou quer ajuda para corrigir e verificar o ambiente, conheça nossos serviços de monitoramento de malware e vulnerabilidades e de resposta a incidentes. E se preferir começar por um diagnóstico, solicite uma avaliação gratuita — a gente ajuda a entender o seu risco real, sem alarmismo.