Segurança · 6 min de leitura
SSHole: falha no OpenSSH do Alpine Linux libera login
Falha no OpenSSH (CVE-2026-123158) permite entrar sem senha em servidores Alpine Linux com senha longa. Veja quem é afetado e como corrigir hoje.
Por Jean Pierre · Publicado em
Resposta rápida
A falha CVE-2026-123158, apelidada de SSHole, permite que um atacante entre por SSH, sem saber senha nenhuma, em contas sem senha definida de servidores Linux com a biblioteca musl e sem PAM, caso do pacote padrão do Alpine Linux. Basta enviar uma senha com mais de 256 caracteres. A correção saiu em 05/11/2026 (OpenSSH 10.6p2 e pacotes do Alpine), já há tentativas de exploração registradas e a medida é atualizar e reiniciar o sshd ou desligar o login por senha.
Em 05/11/2026, o projeto OpenSSH publicou uma correção de emergência para uma falha que permite entrar por SSH, sem saber senha nenhuma, em alguns servidores Linux. O caso mais comum é o Alpine Linux, distribuição leve muito usada em servidores na nuvem e em equipamentos. A falha recebeu o identificador CVE-2026-123158 (nota CVSS 8,1, alta, segundo o registro do NVD) e foi apelidada de SSHole.
Este texto resume o que se sabe, com base no aviso oficial do Alpine e nas notas da versão 10.6p2 do OpenSSH, e diz o que fazer hoje.
O que é a falha SSHole
Em servidores Linux com a biblioteca musl e o sshd sem PAM, uma conta sem senha definida aceita qualquer senha com mais de 256 caracteres (até 1.024). O atacante só precisa alcançar a porta SSH e saber o nome de uma conta sem senha. Segundo o Alpine, basta uma conexão e funciona em todas as tentativas, sem precisar de força bruta.
O motivo é técnico: sem PAM, o próprio sshd confere a senha. Quando a senha é longa demais, a função da musl que calcula o hash falha e devolve o caractere *, o mesmo que o sistema guarda para indicar "conta sem senha". O sshd compara os dois, vê que são iguais e libera a entrada. Segundo a cobertura do The Hacker News, o comportamento existe desde uma mudança de 2016 no OpenSSH; o projeto afirma que a causa raiz está fora do sshd, mas que a falha é explorada por ele e por isso foi corrigida ali.
Quem está exposto
O aviso do Alpine lista quatro condições, e o servidor está exposto só quando todas são verdadeiras:
- Roda o pacote
openssh-serverdo Alpine (compilado sem PAM) ou oopenssh-server-pamcomUsePAM no. - O login por senha está ligado (
PasswordAuthentication yes, o padrão do OpenSSH). - Existe uma conta com
*no campo de senha, como contas só de chave, orootda imagem base desde o Alpine 3.16 ou o usuárioalpinedas imagens oficiais de nuvem. - Pelo menos outra conta local tem senha com hash
$5$ou$6$.
Uma única conta com senha já deixa todas as contas sem senha alcançáveis. O root fica protegido pelo padrão PermitRootLogin prohibit-password, mas isso não ajuda se a conta invadida puder virar root, por exemplo pelo doas. O Alpine alerta que as imagens de nuvem tiny-cloud de 3.18.11 a 3.24.3 dão ao usuário alpine acesso de root sem senha pelo doas: são seguras no primeiro boot, mas ficam vulneráveis assim que alguém define uma senha para qualquer conta.
Quem não está exposto
Segundo o OpenSSH e o Alpine, não são afetados os sistemas que não são Linux, as distribuições baseadas em glibc (como Ubuntu, Debian e Red Hat), os servidores que conferem senha pelo PAM, as máquinas com PasswordAuthentication no e as imagens configuradas por cloud-init, que já desligam o login por senha. Contêineres Docker que não rodam o sshd também ficam de fora.
O pesquisador que encontrou a falha cita outros sistemas baseados em musl para conferir, como OpenWrt, Buildroot e Yocto. No OpenWrt, o SSH padrão é o Dropbear, que não é afetado; o risco só existe onde alguém instalou o servidor do OpenSSH. Vale olhar roteadores, equipamentos e imagens embarcadas, e não só os servidores da nuvem.
Já há exploração
A empresa de inteligência Previdian registrou a primeira tentativa de exploração menos de nove horas depois da publicação do CVE e confirmou acesso de root em um honeypot com Alpine e OpenSSH. Até 08/11/2026, eram 20 tentativas vindas de 13 endereços IP em nove países, segundo a empresa. Na data deste texto, a falha não constava do catálogo de vulnerabilidades exploradas da CISA.
Os números são de sensores de uma empresa privada e mostram tentativas, não invasões confirmadas em empresas. Ainda assim, o recado é claro: a falha é simples de explorar, já está sendo testada na internet e servidores com SSH aberto devem ser tratados como prioridade.
Como corrigir agora
No Alpine, a correção é atualizar o pacote e reiniciar o serviço, porque a atualização não troca o sshd que já está rodando:
apk upgrade -U -arc-service sshd restart
As versões 3.21.10, 3.22.8, 3.23.8 e 3.24.4 já trazem o pacote corrigido, e o Alpine também publicou pacotes para as versões fora de suporte, de 3.16 a 3.20. Quem compila o OpenSSH por conta própria deve usar a 10.6p2. Instâncias de nuvem criadas a partir de imagens antigas continuam vulneráveis até serem atualizadas.
Se não der para atualizar hoje
A alternativa é desligar o login por senha: PasswordAuthentication no na configuração do sshd, conferir com sshd -t e reiniciar o serviço. O comando sshd -T | grep -i passwordauthentication deve mostrar passwordauthentication no. O aviso do Alpine traz os comandos completos, inclusive para linhas dentro de blocos Match.
Antes de mexer, confirme que o acesso por chave funciona e mantenha a sessão atual aberta até um novo login dar certo, para não ficar trancado fora do servidor. Em servidores que não precisam de SSH aberto para a internet, restringir o acesso por firewall ou VPN reduz a exposição a esta e às próximas falhas.
Como saber se alguém entrou
O Alpine recomenda procurar em /var/log/messages linhas do sshd com Accepted password para contas que não têm senha, como alpine, root ou usuários que só entram por chave. Nas máquinas expostas, revise também o uso do doas, usuários e arquivos criados recentemente e as chaves autorizadas.
Nas palavras do aviso, se não for possível descartar um acesso, a máquina deve ser tratada como comprometida. Isso significa reinstalar a partir de uma base limpa, trocar senhas, chaves e segredos guardados nela e avaliar se dados pessoais foram expostos, caso em que a LGPD e a Resolução CD/ANPD 15/2024 podem exigir comunicação à ANPD e aos titulares.
O que fica de lição para servidores Linux
A correção resolve esta falha, mas o padrão se repete: serviços expostos à internet, login por senha ligado sem necessidade e atualizações que só valem depois de reiniciar o serviço. Desligar a senha no SSH, usar chaves, limitar quem alcança a porta e manter inventário dos servidores reduzem o impacto da próxima vulnerabilidade.
Também vale ter visibilidade do que acontece dentro do servidor. Um EDR não corrige a falha do OpenSSH, mas ajuda a perceber o que um invasor faz depois de entrar, como comandos de reconhecimento e criação de usuários. A Codlinx, parceira oficial Bitdefender, protege servidores Windows e Linux com o GravityZone e faz um diagnóstico gratuito do ambiente, com retorno em até 24 horas úteis. Para outra falha recente em servidores, veja o caso do PHP2Shell.