OpenSSH SSHole CVE-2026-123158: Atualize Seus Servidores Linux

A causa raiz remonta a 2016, quando um patch para um problema de enumeração de usuários (CVE-2016-6210) introduziu um efeito colateral sutil que permaneceu oculto por cerca de dez anos. Essa história é o verdadeiro desafio para as equipes corporativas: o comportamento vulnerável não está em um recurso novo, e sim em um código em que se confia há uma década.

Três realidades dificultam a gestão desse tipo de falha. Primeiro, a configuração define a exposição. Um servidor ser vulnerável depende da biblioteca C, do ajuste de PAM e da existência de contas sem senha, dados que raramente aparecem em um inventário de ativos. Segundo, contêineres e equipamentos escondem o problema. O Alpine é uma imagem base popular, então o OpenSSH vulnerável pode estar dentro de imagens que ninguém considera servidores. Terceiro, a velocidade mudou. A primeira tentativa de exploração foi observada menos de nove horas após a publicação do CVE e, em 8 de novembro, já eram 20 tentativas a partir de 13 endereços IP distintos em países como Dinamarca, Irã, Japão, Países Baixos, Noruega, Singapura, Suécia, Suíça e Estados Unidos.

A janela entre a divulgação e o ataque agora é medida em horas. Equipes que aplicam patches em ciclo mensal ficam, na prática, desprotegidas durante a parte mais perigosa de cada divulgação.

O SSHole transforma uma operação falha de cálculo de hash de senha em um login bem-sucedido. A sequência abaixo segue a descrição técnica pública.

1. Encontrar um serviço SSH exposto. O atacante mira um servidor OpenSSH sobre musl com PAM desativado, como uma configuração padrão do Alpine Linux acessível pela rede.
2. Escolher uma conta sem senha. A conta alvo é configurada deliberadamente sem senha utilizável, o que o sistema marca com um asterisco (*) no campo de senha.
3. Enviar uma senha de tamanho excessivo. O atacante fornece uma senha arbitrária de 257 a 1.024 bytes.
4. O cálculo do hash falha. O código de tratamento de senhas não consegue processar a entrada e, em vez de informar um erro, devolve o mesmo asterisco que indica uma senha desabilitada.
5. A comparação tem sucesso. O daemon sshd compara o asterisco devolvido com o asterisco armazenado para a conta, considera-os iguais e concede o acesso.

No caso do honeypot descrito pela Previdian, o atacante usou senhas de tamanho excessivo para entrar e depois executou comandos de reconhecimento como id, uname e hostname por meio de sessões SSH não interativas. É um comportamento típico de primeira fase: confirmar o acesso, conhecer o sistema e decidir o próximo passo.

O que um atacante bem-sucedido pode fazer? Segundo a Safe Security, o impacto depende dos privilégios da conta comprometida. Além do acesso SSH não autorizado, os atacantes podem alcançar credenciais de implantação, segredos de aplicações e infraestrutura conectada, o que permite movimento lateral ou interrupção de serviços. Serviços gerenciados de TI disciplinados reduzem esse risco ao manter um inventário preciso, aplicar patches em um cronograma definido e verificar o resultado em vez de presumi-lo.

Um plano de resposta claro transforma uma vulnerabilidade de manchete em um evento rotineiro de manutenção. As ações imediatas recomendadas nas publicações são diretas.

• Aplicar o patch. Instale o OpenSSH 10.6p2 ou o pacote corrigido da sua distribuição e depois reinicie o sshd. Reiniciar importa: um pacote atualizado em disco não protege um daemon que continua executando o código antigo.
• Investigar. O Alpine recomenda procurar em /var/log/messages linhas do sshd com "Accepted password for" em contas que nunca deveriam aceitar login por senha, como alpine, root ou qualquer usuário somente com chaves. Revise o uso do doas e os usuários, arquivos e chaves autorizadas criados recentemente em máquinas expostas.
• Presumir comprometimento na dúvida. A orientação do Alpine é explícita: se não for possível descartar um login, trate a máquina como comprometida.
• Reduzir a exposição. Não deixe o SSH aberto para toda a internet. Restrinja-o a redes de gerenciamento, uma VPN ou um gateway de confiança zero. Uma arquitetura de conectividade multioperadora e SD-WAN bem projetada torna essa segmentação consistente em todas as unidades e nuvens.
• Remover contas sem senha desnecessárias. Menos contas com hash de asterisco significam menos formas de acionar o erro.

O ganho para o negócio é concreto. Aplicar patches mais rápido reduz a janela de ataque, a revisão de logs limita o dano de um acesso não detectado e as restrições de rede tornam muito menos provável que a próxima falha de SSH seja sequer alcançável. Em setores regulados, isso também gera a evidência que os auditores pedem: o que estava exposto, quando foi corrigido e como foi verificado.

Uma lista prática para esta semana: inventariar todos os servidores e imagens de contêiner com OpenSSH, identificar os que usam Alpine ou musl, atualizar para a 10.6p2 ou para o pacote do fornecedor, reiniciar o sshd, procurar nos logs logins por senha suspeitos e restringir o acesso SSH a redes gerenciadas.

A HIT Communications tem mais de 30 anos de experiência conectando e protegendo empresas na América Latina, nos Estados Unidos e na Europa. Uma falha como o SSHole exige três camadas trabalhando juntas: aplicação rápida de patches, detecção contínua e uma rede que limite a exposição.

Nossos serviços de cibersegurança incluem um centro de operações de segurança (SOC) 24/7, SIEM e detecção e resposta gerenciadas, para que logins SSH suspeitos sejam investigados na hora e não semanas depois. Nossos serviços gerenciados de TI cobrem inventário, aplicação de patches, hardening e infraestrutura em nuvem, para que as atualizações cheguem a servidores e imagens de contêiner conforme o cronograma. Por baixo de ambos, nosso desenho de conectividade multioperadora entrega redes segmentadas e redundantes em que o acesso administrativo é restrito por projeto.

Trabalhamos com CIOs e gerentes de TI que querem um único parceiro responsável em vez de vários fornecedores. Se você não tem certeza de quais servidores e contêineres usam OpenSSH sobre Alpine ou musl, esse é o melhor ponto de partida.

O SSHole mostra a rapidez com que uma falha divulgada vira ataque: menos de nove horas até a primeira tentativa e um número crescente de atacantes desde então. A correção existe, a exposição se limita a uma configuração específica e o momento mais barato de agir é agora.

Atualize para o OpenSSH 10.6p2, reinicie o sshd, revise seus logs em busca de logins por senha que não deveriam existir e feche o SSH para a internet pública. Se quiser apoio para encontrar os sistemas afetados ou montar uma rotina de patches e monitoramento que não dependa de uma única pessoa, fale com a equipe da HIT Communications e analisaremos seu ambiente com você.