Vulnerabilidade CVE-2026-123158, conhecida como sshole, explora uma interação entre OpenSSH e musl libc e permite contornar a autenticação em configurações específicas de servidores Linux.
Uma falha descoberta no OpenSSH chamou a atenção dos administradores Linux por um motivo incomum: ela pode permitir acesso a contas configuradas justamente para não aceitar senhas. Identificada como CVE-2026-123158 e batizada de sshole, a vulnerabilidade não depende do roubo de credenciais. Sob determinadas condições, uma senha longa provoca um resultado inesperado na verificação de autenticação e acaba sendo aceita pelo servidor.
O problema foi identificado pelo pesquisador Özgün Kültekin, da Wakefield, e divulgado em 5 de novembro de 2026. A investigação revelou uma interação entre o mecanismo de autenticação do OpenSSH e a biblioteca musl libc, utilizada pelo Alpine Linux e por outros sistemas leves. Os comportamentos envolvidos existem há anos, mas sua combinação abre uma possibilidade de acesso não autorizado que passou despercebida.
O SSH é uma das ferramentas mais utilizadas para administrar servidores, dispositivos de rede e infraestrutura de nuvem. Por isso, a descoberta merece atenção, especialmente quando o serviço está exposto à Internet ou permite alcançar contas com privilégios administrativos. Isso não significa, porém, que todos os servidores OpenSSH estejam vulneráveis.
O detalhe técnico começa no arquivo /etc/shadow. Uma conta pode apresentar o caractere * no campo reservado ao hash de senha. Esse valor impede a autenticação convencional por senha, embora a conta possa continuar acessível por outros mecanismos, como chaves SSH. O comportamento esperado é simples: nenhuma senha digitada deveria corresponder ao asterisco.
Em sistemas que utilizam musl libc, a função crypt() pode retornar exatamente * ao receber uma senha acima do limite suportado. O OpenSSH, por sua vez, incorporou em 2016 uma proteção contra a enumeração de usuários baseada em diferenças de tempo na autenticação. Em algumas circunstâncias, essa proteção utiliza parâmetros de hash de outra conta local para realizar a verificação, mesmo quando a conta solicitada não possui uma senha utilizável.
Quando os dois comportamentos se encontram, uma senha longa pode fazer a função criptográfica devolver *. Se o campo de senha da conta de destino também contém esse caractere, a comparação pode indicar sucesso, embora nenhuma credencial válida tenha sido apresentada. A descrição da CVE aponta senhas entre 256 e 1.024 caracteres em determinadas configurações. O problema não está na quebra da criptografia, mas na interpretação de um valor de erro como se fosse um resultado válido.
Quais servidores estão realmente expostos
A exploração depende de várias condições simultâneas. O servidor deve executar OpenSSH com musl libc, sem PAM no caminho de autenticação, permitir login por senha e possuir uma conta cujo campo de senha seja exatamente *. A pesquisa também descreve a necessidade de outra conta local com hash SHA-256 ou SHA-512 utilizável durante o processamento. Sem essa combinação, o cenário de exploração relatado não se reproduz.
O Alpine Linux merece atenção porque utiliza musl e pode executar o OpenSSH sem PAM. Ambientes construídos com Buildroot, Yocto ou OpenWrt precisam ser avaliados caso utilizem a mesma combinação. Isso não equivale a dizer que todo dispositivo dessas famílias esteja vulnerável: o OpenWrt normalmente utiliza Dropbear, por exemplo, e imagens-base Alpine não incluem necessariamente um servidor SSH em execução.
Determinadas imagens Alpine destinadas à nuvem também foram mencionadas na pesquisa. Quando uma conta comprometida possui acesso administrativo por meio do doas, a invasão pode alcançar privilégios elevados. O impacto depende da configuração efetiva e das permissões concedidas. Em servidores corporativos, o acesso indevido pode permitir leitura de arquivos, alterações de serviços, instalação de persistência e tentativas de movimentação lateral.
Distribuições que utilizam glibc e PAM nas configurações habituais, como Debian, Ubuntu e Red Hat Enterprise Linux, não estão expostas a essa combinação específica. A Red Hat confirmou que seus produtos não são afetados. Essa distinção é importante para evitar alarmes generalizados baseados apenas na presença do OpenSSH. A avaliação oficial da Red Hat delimita esse escopo.
A equipe do OpenSSH disponibilizou a versão 10.6p2 em 5 de novembro, com uma proteção para impedir a autenticação indevida. O Alpine Linux também publicou pacotes corrigidos para diferentes versões da distribuição. Como correções podem ser incorporadas aos pacotes sem alterar o número principal do OpenSSH, a verificação deve considerar a revisão do pacote instalada, e não apenas a saída de ssh -V.
Depois de atualizar, é necessário reiniciar o serviço SSH de maneira controlada, garantindo que o processo em execução utilize o código corrigido. Antes de qualquer alteração remota, convém manter uma sessão administrativa alternativa aberta. Para quem não consegue aplicar a correção imediatamente, desabilitar a autenticação por senha com PasswordAuthentication no elimina o caminho descrito na pesquisa, desde que a configuração efetiva seja conferida e o acesso por chave esteja funcionando.
Restringir SSH a uma VPN ou rede de administração também reduz a exposição. Equipes de segurança devem procurar nos logs autenticações bem-sucedidas por senha em contas que deveriam rejeitar esse método. Uma ocorrência desse tipo exige investigação, embora sua ausência não seja prova de que o servidor nunca foi comprometido.
Há ainda um aspecto interessante na forma como a falha foi encontrada. Kültekin utilizou agentes de inteligência artificial para realizar aproximadamente 17.600 testes de autenticação, comparando bibliotecas, configurações e implementações. A divergência de comportamento observada nos sistemas com musl e sem PAM ajudou a revelar um problema que sobrevivera por cerca de uma década.
Até a divulgação inicial, não havia confirmação pública de exploração em ataques reais. A publicação dos detalhes técnicos e de provas de conceito, entretanto, torna mais urgente a identificação dos servidores efetivamente expostos. A resposta adequada começa pelo inventário e pela configuração real do serviço: a versão do OpenSSH, isoladamente, não informa se a vulnerabilidade pode ser explorada.
Be the first to comment