SSHole: a correção começa por descobrir qual OpenSSH você realmente opera

A Previdian relatou exploração da CVE-2026-123158, chamada SSHole, em um honeypot com Alpine Linux e OpenSSH, incluindo acesso root naquela configuração.[2] O caso é urgente para ambientes compatíveis com as condições descritas, mas não autoriza dizer que todo servidor Linux com SSH esteja vulnerável.

O que muda para quem desenvolve

O mecanismo exige OpenSSH sobre musl, sem validação de senhas por PAM e pelo menos uma conta cujo campo de hash contenha *.[2] A configuração padrão do servidor OpenSSH no Alpine pode reunir essas condições; glibc, autenticação mediada por PAM, sistemas não Linux e Dropbear ficam fora do mecanismo relatado.[2] Para quem entrega imagens e automações, o inventário precisa descer além do nome da distribuição.

A falha ocorre quando um erro no cálculo do hash produz * e esse retorno é aceito ao coincidir com o marcador da conta.[2] O acesso herda os privilégios da conta atingida, sem atravessar automaticamente uma senha com hash válido.[2] A distinção operacional importa: exposição do serviço, política de autenticação e privilégios são dimensões diferentes.

Como aplicar

Monte uma matriz por ativo: implementação do servidor SSH, biblioteca C, presença de PAM, contas relevantes e exposição de rede. Colete essas informações sem copiar hashes ou outros dados sensíveis para tickets. Marque como desconhecido o que ainda não foi confirmado, em vez de preencher com a configuração esperada da imagem-base.

A correção indicada é OpenSSH 10.6p2 ou o pacote corrigido da distribuição, seguida de reinício do sshd.[2] Planeje a mudança com um canal de recuperação para não depender exclusivamente da sessão que será reiniciada. Registre separadamente o pacote instalado e a confirmação de que o processo passou a usar a versão corrigida.

A orientação do Alpine inclui buscar logins por senha em contas que não deveriam aceitá-los, além de revisar usuários, chaves autorizadas, arquivos e uso de doas.[2] Use essa investigação para decidir se o problema termina na atualização ou exige resposta a comprometimento.

Cuidados e limites

O sucesso observado em honeypot demonstra explorabilidade daquela configuração, não a dimensão global de uma campanha.[2] Também não conclua que um host foi invadido só porque estava vulnerável.

Por outro lado, atualizar não demonstra ausência de acesso anterior. Se não for possível descartar comprometimento, trate a recuperação como um problema de confiança no host. A melhor triagem combina condições verificadas e evidências de autenticação, não apenas um número de versão na planilha.

Fonte

[2] Fonte: The Hacker News