O OpenSSH 10.6p2 saiu em 4 de novembro de 2026 com uma correção para um bypass de autenticação por senha no sshd. A falha recebeu o identificador CVE-2026-123158 e, em 9 de novembro, a CISA a incluiu no catálogo Known Exploited Vulnerabilities, a lista de falhas com exploração confirmada. Para órgãos federais americanos, o prazo de correção é 12 de novembro.
O que a falha permite
Segundo a descrição publicada no rastreador de segurança do Ubuntu, o sshd anterior à 10.6p2, rodando em Linux, compilado contra a musl libc e sem PAM (o módulo de autenticação usado pela maioria das distribuições com glibc), não tinha uma proteção contra esse bypass. Em algumas configurações de conta, qualquer senha entre 256 e 1024 caracteres é aceita. O Alpine Linux é o exemplo citado. O Ubuntu classifica a falha com prioridade alta e CVSS 3.1 de 8,1.
A mensagem do commit que corrige o problema, assinada por Damien Miller, diz que o bypass "afeta algumas configurações" e que a causa raiz não está no OpenSSH, mas que o projeto tem como evitá-la. A mudança passa a recusar hashes de senha armazenados com menos de quatro caracteres e ajusta a liberação de memória nas rotinas de verificação. Em 9 de novembro entrou no repositório outro commit, "harden password checking", ainda sem versão publicada que o inclua.
Quem precisa olhar agora
O risco está em qualquer máquina ou contêiner que rode sshd sobre musl, sem PAM, com login por senha habilitado e acessível pela rede. Na prática, isso aponta para servidores e imagens baseados em Alpine: bastions, servidores SFTP de troca de arquivos com clientes, contêineres de desenvolvimento ou de suporte que alguém deixou com SSH aberto.
Ubuntu, Debian e Red Hat usam glibc por padrão. O Ubuntu registra que, por esse motivo, a instalação padrão não deve ser afetada, mas mantém os pacotes como "em avaliação" porque a musl existe no repositório. Quem só usa Alpine como base de imagem para a aplicação, sem instalar openssh-server, também fica fora do alcance.
O ponto difícil é saber onde esses sshd estão. Contêiner com SSH costuma nascer como atalho de depuração e ficar sem dono. Se ninguém responde pela manutenção dessas imagens depois da entrega, a pergunta de quem cuida do sistema depois que o projeto acaba vira uma busca às pressas no inventário.
O que fazer até 12 de novembro
O prazo da CISA vale para o governo americano, mas serve de referência para qualquer equipe: a exploração já foi confirmada, então esperar a próxima janela de manutenção não faz sentido.
- Levantar hosts e imagens com
sshdem Alpine ou outra distribuição musl.ssh -Vmostra a versão;ldd $(which sshd)mostra se o binário usa musl. - Atualizar para o OpenSSH 10.6p2 ou para o pacote corrigido da distribuição, e reconstruir as imagens de contêiner que embutem o servidor.
- Onde a atualização não puder sair hoje, desligar
PasswordAuthenticationnosshd_confige aceitar só chave pública, ou tirar a porta 22 da internet. - Revisar os registros de autenticação desde antes de 4 de novembro em busca de logins por senha em contas que não deveriam usá-la. A CISA marcou esta falha com exigência de triagem forense, o que indica que corrigir pode não bastar se houve acesso.
O que ainda não se sabe
A descrição pública não detalha quais "configurações de conta" tornam o bypass possível, e a correção sugere, sem confirmar, que contas com o campo de senha curto ou vazio são o caminho. Também não há informação pública sobre quem está explorando a falha, nem sobre uso em ransomware, que a CISA registra como desconhecido. O commit de 9 de novembro indica que pode vir outra versão com reforço adicional; vale acompanhar as notas de release do OpenSSH e os avisos do Alpine antes de dar o assunto por encerrado.
Se a sua empresa está avaliando algo parecido, me chama no LinkedIn ou no WhatsApp.
