Falha no OpenSSH pode liberar contas Linux sem senha em configurações específicas
Uma vulnerabilidade identificada como CVE-2026-123158, também chamada de sshole, pode permitir que um invasor autentique-se em determinadas contas Linux sem conhecer uma senha válida. O problema não representa uma falha geral em todos os servidores OpenSSH: a exploração depende da combinação de componentes e configurações específicas, sobretudo do uso da biblioteca musl libc.
A descoberta foi feita pelo pesquisador Özgün Kültekin, da Wakefield, e divulgada em 5 de novembro de 2026. O defeito envolve a forma como o OpenSSH e a musl libc lidam com senhas muito longas durante a verificação de autenticação. Em certas circunstâncias, uma senha extensa pode produzir um resultado inesperado, interpretado pelo servidor como uma correspondência válida.
O SSH é amplamente usado para administrar servidores, equipamentos de rede e ambientes em nuvem. Por isso, qualquer vulnerabilidade relacionada à autenticação merece atenção, em especial quando o serviço está acessível pela Internet. Ainda assim, a presença do OpenSSH, por si só, não significa que um sistema esteja vulnerável.
Como a falha pode contornar a autenticação
O caso está relacionado ao conteúdo do arquivo `/etc/shadow`, que armazena informações de autenticação das contas locais. Quando o campo referente à senha contém o caractere `*`, a autenticação convencional por senha deve ser bloqueada. A conta, porém, ainda pode aceitar outros métodos de acesso, como chaves SSH, conforme a configuração do sistema.
Em sistemas com musl libc, a função `crypt()` pode retornar o próprio caractere `*` quando recebe uma senha acima do limite suportado. Separadamente, o OpenSSH inclui uma proteção contra a enumeração de usuários, técnica pela qual um atacante tenta descobrir quais contas existem no servidor. Em determinadas condições, essa proteção pode levar o programa a usar informações de hash de outra conta local durante a verificação.
A vulnerabilidade surge quando esses comportamentos se combinam. Se a função criptográfica devolve `*` e o campo da conta que está sendo acessada também contém esse caractere, a comparação pode indicar sucesso. Assim, uma entrada que deveria ser tratada como erro acaba sendo interpretada como uma autenticação válida. Não se trata de quebrar a criptografia nem de descobrir a senha real, mas de uma falha na interpretação do resultado.
A descrição da CVE menciona senhas com comprimentos entre 256 e 1.024 caracteres em determinadas configurações. A exploração também exige que outras condições estejam presentes: o servidor precisa usar OpenSSH com musl libc, não contar com PAM no fluxo de autenticação por senha e permitir esse tipo de login. Além disso, a pesquisa aponta a necessidade de uma segunda conta local com um hash SHA-256 ou SHA-512 aproveitável pelo processo de autenticação.
Quais sistemas podem estar expostos
O Alpine Linux merece avaliação cuidadosa porque utiliza musl libc e algumas configurações podem executar o OpenSSH sem PAM. Imagens e sistemas construídos com Alpine, Buildroot, Yocto ou OpenWrt também devem ser examinados caso reúnam os componentes necessários. Isso não significa que todos esses ambientes estejam automaticamente vulneráveis: o OpenWrt, por exemplo, costuma usar o Dropbear, e uma imagem Alpine sem servidor SSH ativo não apresenta a mesma exposição.
Algumas imagens Alpine voltadas para uso em nuvem também foram mencionadas na análise. O impacto potencial depende das permissões da conta que poderia ser acessada. Se ela puder executar comandos administrativos por meio do `doas`, por exemplo, a invasão pode evoluir para privilégios mais altos. Em um servidor corporativo, o acesso não autorizado pode facilitar a leitura de arquivos, a alteração de serviços, a instalação de mecanismos de persistência e tentativas de avançar para outros sistemas da rede.
Distribuições que usam glibc e PAM em suas configurações habituais – como Debian, Ubuntu e Red Hat Enterprise Linux – não correspondem à combinação específica descrita para essa vulnerabilidade. A Red Hat informou que seus produtos não são afetados. Mesmo assim, administradores devem confirmar a composição real do ambiente, especialmente em instalações personalizadas, contêineres e dispositivos embarcados, nos quais os padrões de uma distribuição podem ter sido alterados.
O que os administradores devem fazer
A primeira medida é identificar quais servidores usam OpenSSH, qual biblioteca C está instalada e se o login por senha está habilitado. Também é importante verificar se o PAM participa da autenticação e revisar as contas locais, dando atenção às que têm `*` no campo de senha do `/etc/shadow`. A análise deve considerar a configuração efetiva, e não apenas o nome da distribuição.
Em seguida, os responsáveis devem instalar as atualizações de segurança disponibilizadas pelos mantenedores do sistema e do OpenSSH, quando aplicáveis. Até que a correção esteja disponível ou seja aplicada, uma redução do risco consiste em desativar a autenticação por senha e permitir o acesso administrativo apenas por chaves SSH, desde que essa mudança seja compatível com a operação e não impeça o acesso legítimo.
Também é recomendável limitar o acesso ao SSH por firewall ou por regras de rede, permitindo conexões somente a partir de endereços e segmentos confiáveis. A restrição reduz a quantidade de possíveis origens de ataque, mas não substitui a atualização do software nem a revisão dos métodos de autenticação.
Depois de aplicar as medidas, os administradores devem testar o acesso com uma conta autorizada e confirmar que os métodos permitidos continuam funcionando. É prudente manter uma sessão administrativa aberta durante mudanças de configuração e garantir uma forma alternativa de recuperação, para evitar que uma alteração incorreta bloqueie o acesso ao servidor.
Por fim, equipes de segurança devem revisar registros de autenticação em busca de acessos incomuns, tentativas repetidas ou conexões originadas de endereços inesperados. A ausência de sinais suspeitos não comprova que um sistema nunca foi exposto, mas o monitoramento ajuda a identificar atividades que merecem investigação. O risco da CVE-2026-123158 depende de uma combinação estreita de fatores; mapear esses fatores e corrigir os sistemas compatíveis é a maneira mais eficaz de reduzir a exposição.