O SANS Internet Storm Center informou em 8 de novembro que seus sensores registraram tentativas de explorar uma falha no OpenSSH capaz de contornar a autenticação por senha em determinadas instalações. O grupo identificou em sua amostra a primeira tentativa compatível com a CVE-2026-123158, conhecida como SSHole, em 5 de novembro. O Alpine Linux publicou correções para a falha no mesmo dia.
O risco recai sobre o servidor que aceita a conexão, o sshd. Para quem administra Alpine em uma máquina virtual, equipamento ou contêiner, a prioridade é verificar a configuração efetiva de autenticação e a revisão do pacote fornecida pela distribuição.
O que o SANS observou
O relato de Johannes Ullrich no SANS ISC usa dados de honeypots Cowrie, sensores que aceitam conexões de teste para registrar tráfego suspeito. Eles observaram um aumento de senhas longas e distinguiram as primeiras tentativas compatíveis com a falha do ruído de scripts que já enviavam entradas incomuns. O sensor guarda até 255 caracteres da senha enviada. Por isso, o volume de entradas longas não pode ser convertido em número de tentativas bem-sucedidas, nem informa quantos servidores de produção foram comprometidos.
Quais servidores podem estar expostos
O aviso do Alpine Linux descreve a combinação necessária: servidor OpenSSH ligado à biblioteca musl, sem PAM ativo, com autenticação por senha habilitada, uma conta cujo campo de senha esteja marcado com * e pelo menos um hash de senha local dos tipos SHA-256-crypt ou SHA-512-crypt. PAM é a camada de módulos de autenticação que certas instalações usam para validar credenciais. Uma conta que usa chave pode entrar no escopo se a configuração do servidor também aceitar senhas e os outros requisitos estiverem presentes.
Um contêiner baseado em Alpine que não executa sshd fica fora desse cenário. O mesmo vale para instalações Alpine com PasswordAuthentication no ou com o pacote PAM e UsePAM yes. A Red Hat informa que seus produtos ficam fora do escopo porque seus pacotes OpenSSH usam glibc e PAM. Assim, o nome OpenSSH sozinho não identifica se uma máquina está vulnerável.
Como verificar a correção no Alpine
O Alpine distribuiu os pacotes corrigidos nas versões 3.21.10, 3.22.8, 3.23.8 e 3.24.4 do sistema. A revisão do OpenSSH varia por ramo. Compare a versão instalada com a linha correspondente no aviso, em vez de usar um número de OpenSSH único como referência:
| Ramo do Alpine | Pacote OpenSSH corrigido |
|---|---|
| 3.24 | 10.3_p1-r2 |
| 3.23 | 10.2_p1-r1 |
| 3.22 | 10.0_p1-r11 |
| 3.21 | 9.9_p2-r1 |
| edge | 10.6_p2-r0 |
O aviso também lista revisões para os ramos antigos de 3.16 a 3.20, que já não recebem atualizações regulares. Depois de instalar a correção, reinicie o serviço sshd: o Alpine avisa que atualizar o pacote não reinicia o processo em execução. Em um contêiner, verifique a imagem e o processo que está atendendo conexões após a substituição da instância.
Se precisar adiar a atualização, o Alpine orienta desabilitar a autenticação por senha. Em acesso remoto, confirme primeiro que sua chave funciona e mantenha a sessão atual aberta enquanto testa uma nova conexão. Valide a configuração antes de reiniciar o serviço e só encerre a sessão anterior depois de conferir o acesso.
