SSHole: falha no OpenSSH deixa entrar sem senha em servidores Alpine Linux

Na quinta-feira, 5 de novembro de 2026, o projeto OpenSSH publicou a versão 10.6p2 para corrigir uma falha que permite entrar em um servidor sem conhecer a senha de uma conta. O problema recebeu o código CVE-2026-123158 e o apelido de "SSHole". A falha atinge o servidor SSH quando ele roda em sistemas Linux baseados na biblioteca musl, como o Alpine Linux, e não usa o módulo de autenticação PAM. No dia seguinte, uma empresa de inteligência de ameaças afirmou ter visto tentativas reais de exploração, com acesso de administrador obtido em um servidor-isca. Este texto reúne o que está confirmado, o que as manchetes simplificaram e o que uma empresa pode fazer ainda hoje.

O que é o SSHole, em português de gente

O SSH é a porta de serviço dos servidores Linux: é por ele que o administrador entra para configurar, atualizar e consertar a máquina. Cada conta de usuário tem, no arquivo de senhas do sistema, um campo que guarda a senha em forma embaralhada (o "hash"). Algumas contas não têm senha de propósito, como a do administrador (root) em muitas imagens do Alpine ou contas que entram só por chave criptográfica. Nesses casos o campo guarda apenas um asterisco, que significa "nenhuma senha serve aqui".

O defeito está no encontro de duas regras. Para impedir que alguém descobrisse quais usuários existem medindo o tempo de resposta, o OpenSSH passou, em 2016, a calcular a senha digitada mesmo quando a conta não tem senha. Já a biblioteca musl, quando recebe uma senha com mais de 256 bytes, devolve justamente um asterisco como sinal de erro. O servidor compara o asterisco devolvido com o asterisco guardado na conta, acha que são iguais e libera o acesso. Em resumo: bastava digitar uma senha longa demais para uma conta sem senha. Não é falha de criptografia, nem de memória: é um erro de lógica, e por isso funciona de primeira, sem adivinhação e sem força bruta.

A descoberta é do pesquisador Özgün Kültekin, da empresa Wakefield, cujo relato chegou ao OpenSSH em 4 de novembro, um dia antes da correção. Segundo a cobertura da imprensa técnica, ele usou agentes de inteligência artificial para rodar cerca de 17.600 tentativas de login incomuns contra várias versões do servidor SSH. Só a combinação musl sem PAM aceitou entradas que deveria ter recusado. A nota de gravidade é CVSS 3.1 de 8,1, classificada como alta.

Quando a falha realmente funciona

As fontes que analisaram o caso concordam que o ataque exige que todas estas condições estejam presentes ao mesmo tempo:

• o servidor SSH roda em um sistema com musl e foi compilado sem PAM (é o padrão do pacote openssh-server do Alpine) ou está configurado com UsePAM no;
• o login por senha está ligado, o que é o padrão do OpenSSH;
• existe ao menos uma conta cujo campo de senha é exatamente um asterisco (contas marcadas com ponto de exclamação não são atingidas);
• existe ao menos uma outra conta local com senha comum, de onde o servidor empresta o "tempero" usado no cálculo;
• o atacante consegue alcançar a porta SSH pela rede.

Se qualquer uma faltar, a falha não se aplica. Isso explica por que a imensa maioria dos servidores Linux do mundo, que usa a biblioteca glibc (Debian, Ubuntu, Fedora, Red Hat), não é afetada.

"Acesso root": o que a manchete simplifica

A manchete que circulou nas redes fala em hackers obtendo acesso de administrador em servidores Alpine. É verdade que isso foi observado, mas o caminho importa. O Alpine, por padrão, não permite login direto como root com senha. O que o ataque entrega, em geral, é o acesso à conta sem senha que existir no sistema. Nas imagens oficiais do Alpine para nuvem (AWS e Azure, versões 3.18.11 a 3.24.3), essa conta é o usuário alpine, que pode virar administrador sem digitar senha por meio do doas. Segundo o aviso do próprio Alpine, essas máquinas ficam exploráveis quando existe, em algum lugar do sistema, uma senha comum cadastrada. Também chega ao administrador quem tiver liberado o login direto de root por senha.

Outro detalhe que as imagens das redes embaralham: o número "10.6p2" que aparece nelas não é a versão vulnerável. É a versão que traz a correção.

Já está sendo explorada?

Aqui é preciso separar as fontes. Nas primeiras análises, de 5 de novembro, não havia relato de exploração real. Em 6 de novembro, o site Help Net Security divulgou que a empresa de inteligência de ameaças Previdian viu a primeira tentativa menos de nove horas depois da publicação do CVE e confirmou acesso de administrador em um servidor-isca (honeypot) que rodava Alpine com OpenSSH. Segundo a Previdian, foram oito tentativas, todas de um único endereço, usando senhas gigantes e depois comandos de reconhecimento do sistema. A mesma reportagem informa que a falha ainda não constava no catálogo de vulnerabilidades exploradas da agência americana CISA.

Há, portanto, relato de exploração por uma fonte especializada, em ambiente controlado, e é prudente tratar o risco como real. Existem também códigos de demonstração públicos circulando. A Previdian alerta que os não verificados podem conter código malicioso: quem for testar a própria rede deve usar apenas as verificações de leitura descritas pelo Alpine.

Quem não é afetado

• Sistemas com glibc, como Debian, Ubuntu, Fedora e Red Hat.
• Servidores que autenticam por PAM (no Alpine, o pacote openssh-server-pam com UsePAM yes).
• Servidores com PasswordAuthentication no, ou seja, que só aceitam chave criptográfica.
• Contas bloqueadas com ponto de exclamação em vez de asterisco.
• O Dropbear, servidor SSH leve usado por padrão em vários roteadores, e o SSH do OpenBSD.

Entre os sistemas que podem ser afetados, além do Alpine, a imprensa técnica cita equipamentos montados com Buildroot ou Yocto que usam OpenSSH sobre musl, e contêineres baseados em Alpine que rodam um servidor SSH dentro deles.

O que fazer hoje

O Alpine publicou pacotes corrigidos no mesmo dia para todas as versões de 3.16 até a edge (a de desenvolvimento), e o OpenSSH lançou a versão 10.6p2. Para quem usa Alpine, a orientação oficial tem dois passos, e o segundo é o que mais se esquece:

1. Atualizar: apk upgrade -U -a.
2. Reiniciar o serviço SSH: rc-service sshd restart. Atualizar o pacote não troca o programa que já está rodando: o servidor antigo continua aceitando conexões até ser reiniciado.

Quem não puder atualizar agora deve desligar o login por senha, depois de confirmar que o acesso por chave funciona, para não se trancar para fora. Em versões recentes do Alpine isso se faz com um arquivo em /etc/ssh/sshd_config.d/ contendo PasswordAuthentication no, seguido de sshd -t para validar e do reinício do serviço. O desenvolvedor do OpenSSH Damien Miller recomendou publicamente desligar a autenticação por senha ou o SSH nessas máquinas imediatamente, sem esperar.

Outras medidas, que o Alpine também recomenda: trocar o asterisco por ponto de exclamação nas contas sem senha, manter o login direto de root em prohibit-password ou no, reconstruir as imagens de contêiner a partir de uma base corrigida (baixar a imagem nova não atualiza os contêineres que já estão rodando) e tirar a porta SSH da internet, deixando-a acessível só de endereços conhecidos ou por VPN.

Como saber se alguém já entrou

Um acesso obtido por essa falha aparece no registro do sistema como um login comum por senha. O Alpine orienta procurar, em /var/log/messages, linhas "Accepted password for" referentes a contas que não deveriam ter senha, como alpine, root ou usuários que só entram por chave. Em seguida convém olhar o uso do doas ou do sudo nos minutos seguintes, usuários criados recentemente, o arquivo authorized_keys e arquivos novos em pastas temporárias. Dois detalhes ajudam a interpretar o que se vê: o tamanho da senha não fica registrado, e um ataque bem-sucedido não deixa tentativas fracassadas antes. Se não for possível descartar que houve invasão, a recomendação é tratar a máquina como comprometida, trocar os segredos que ela guardava e reconstruí-la.

O que isso muda para uma empresa que não usa Alpine

Provavelmente seu servidor principal não é afetado, e vale dizer isso com clareza. Mas a lição prática vale para qualquer porte, e há três perguntas a fazer ainda esta semana. Existe algum contêiner, equipamento ou "caixinha" de fornecedor na sua rede que rode Linux enxuto, com acesso SSH aberto, e que ninguém atualiza porque "está funcionando"? A porta SSH de algum equipamento está exposta à internet sem necessidade? E o login por senha está desligado nos servidores que só precisam de chave?

O caso também mostra um padrão conhecido: o tempo entre a divulgação de uma falha e a primeira tentativa real de exploração está em poucas horas. Atualização que espera o próximo ciclo de manutenção chega tarde. Esse é um dos motivos pelos quais o monitoramento contínuo e um inventário de quais sistemas existem na rede fazem diferença: não é possível corrigir o que ninguém sabe que está lá.

Perguntas frequentes

O que é o SSHole (CVE-2026-123158)?

É uma falha de autenticação no servidor OpenSSH quando ele roda em Linux com a biblioteca musl, como o Alpine, sem PAM. Uma senha com mais de 256 bytes faz o sistema aceitar o login em uma conta que não tem senha. A correção está no OpenSSH 10.6p2, de 5 de novembro de 2026.

A versão 10.6p2 do OpenSSH é a vulnerável?

Não. A 10.6p2 é a versão que corrige o problema. As versões anteriores, em sistemas musl sem PAM, são as afetadas. No Alpine, os pacotes corrigidos têm numeração própria, por exemplo 10.3_p1-r2 na versão 3.24 e 9.9_p2-r1 na 3.21, e por isso alguns verificadores que olham só o número podem acusar máquinas já corrigidas.

Meu servidor Ubuntu ou Debian precisa de atenção?

Para esta falha, não: sistemas com glibc e PAM não são afetados. Vale a regra de sempre manter o sistema atualizado e o login por senha desligado quando só chaves são necessárias.

Hackers já usaram essa falha?

A empresa Previdian relatou tentativas reais pouco depois da divulgação e acesso de administrador em um servidor-isca. Outras fontes, em 5 de novembro, ainda não tinham registro de exploração. Trate o risco como real e aplique a correção.

Como especialista em cibersegurança, a Ragnatela trata esse tipo de aviso como rotina: primeiro descobre quais sistemas do cliente estão expostos, depois corrige, reinicia o que precisa ser reiniciado e confere se funcionou. Quem cuida de rede e servidores precisa de um inventário vivo e de alguém olhando o ambiente quando a falha é publicada, não semanas depois. Se você quer saber se há algum equipamento com SSH aberto na sua empresa que ninguém lembra de atualizar, a gente olha com você, numa conversa sem custo.

Fontes

Fonte: Alpine Linux — "OpenSSH password authentication bypass" (aviso de segurança), 05/11/2026. ler matéria.

Fonte: OpenSSH — notas de lançamento da versão 10.6p2, 05/11/2026. ler matéria.

Fonte: Help Net Security — "OpenSSH flaw exploited in the wild just hours after disclosure (CVE-2026-123158)", 06/11/2026. ler matéria.

Fonte: Ethiack — "CVE-2026-123158 (sshole): OpenSSH Password Bypass on Alpine Linux". ler matéria.

Fonte: OX Security — "OpenSSH Password Authentication Bypass on Alpine Linux (*sshole)", 05/11/2026. ler matéria.

Fonte: BleepingComputer — "OpenSSH flaw lets attackers log into password-disabled Linux accounts", 05/11/2026. ler matéria.

Fonte: Threat Defence — "Alpine OpenSSH CVE-2026-123158: Patching and Hunting". ler matéria.