Uma falha no OpenSSH colocou em risco servidores Alpine Linux que têm contas sem senha. Em 5 de novembro de 2026, o projeto OpenSSH lançou a versão 10.6p2 para corrigir uma falha considerada crítica. Em certas condições, ela permite que um atacante entre em contas que não têm senha, em uma única tentativa.
Quem é afetado pela falha no OpenSSH
O problema atinge principalmente servidores Alpine Linux (muito usado em contêineres e imagens leves de nuvem) em que, ao mesmo tempo:
- o OpenSSH foi compilado sem PAM;
- o login por senha está ativado (padrão do pacote);
- existe pelo menos uma conta sem senha;
- existe outra conta local com senha.
Atenção especial: o Alpine vem com a conta root sem senha desde a versão 3.16, e algumas imagens de nuvem (tiny-cloud de 3.18.11 a 3.24.3) dão ao usuário alpine acesso root sem senha.
Distribuições baseadas em glibc (como Debian, Ubuntu e Rocky) e sistemas que usam PAM não são afetados, segundo o mantenedor.
O que fazer
- Agora: desative o login por senha no SSH (PasswordAuthentication no) ou bloqueie o acesso SSH até atualizar.
- Atualize o pacote (o Alpine já tem pacotes corrigidos para todas as versões a partir da 3.16).
- Reinicie o sshd. Só atualizar não basta: o serviço em execução continua com o código antigo até ser reiniciado.
- Revise as contas sem senha em todos os servidores.
Atenção a contêineres e imagens de nuvem
Como o Alpine Linux é muito usado como base de contêineres e de imagens leves de nuvem, vale revisar não só os servidores em produção, mas também as imagens que servem de modelo. Se uma imagem base vulnerável continuar em uso, cada nova máquina criada a partir dela nasce com o mesmo problema. Atualize as imagens, gere novas versões e substitua as instâncias antigas. Em contêineres, o SSH muitas vezes nem é necessário: quando possível, remova o serviço e use as ferramentas de acesso da própria plataforma.
E o meu site com isso?
Muitos sites WordPress rodam em servidores Linux administrados pela própria empresa ou por um profissional contratado. Quem entra no servidor tem acesso a todos os arquivos do site, ao banco de dados e às senhas guardadas na configuração. Por isso, cuidar do SSH também é cuidar do site.
Como saber se meu servidor foi afetado
Primeiro, confirme a distribuição, a versão do OpenSSH e a configuração de login. Estes comandos ajudam:
cat /etc/alpine-releasemostra a versão do Alpine Linux.ssh -Vmostra a versão do OpenSSH instalada.grep -i passwordauthentication /etc/ssh/sshd_configindica se o login por senha está ativado.- Revise o arquivo /etc/shadow (como root e com cuidado) para identificar contas sem senha definida.
Depois, olhe os registros de autenticação do servidor em busca de logins bem-sucedidos em contas que não deveriam ser usadas. Se encontrar algo suspeito, trate o servidor como comprometido: troque as credenciais, revise as chaves SSH autorizadas e, se possível, recrie a máquina a partir de uma imagem limpa.
Checklist rápido de prevenção para SSH
- Login apenas com chave SSH, com PasswordAuthentication no.
- Acesso direto do root desativado ou limitado a chaves.
- Nenhuma conta sem senha ou sem uso no sistema.
- Porta SSH acessível só a partir de endereços confiáveis, por firewall ou VPN.
- Atualizações de pacotes aplicadas com frequência, sempre seguidas do reinício dos serviços afetados.
Servidores também estiveram no centro de outros alertas recentes: veja o ataque ao cPGuard, que atingiu servidores de hospedagem, e os switches Zyxel invadidos mesmo depois da correção de junho.
Dica de rotina
Para servidores, a melhor prática é usar apenas chaves SSH, sem login por senha, e revisar periodicamente quem tem acesso. É uma mudança simples que fecha várias portas de uma vez.
Fale comigo | Administração de servidores
Fonte