OpenSSH *sshole: quando uma senha com 257 caracteres destrava o root

O que parecia um bug de fronteira — um erro de comparação de strings em uma combinação específica de bibliotecas C — se transformou em uma das vulnerabilidades mais relevantes do outono. A falha, batizada de \*sshole (CVE-2026-123158) pelo pesquisador Özgün Kültekin da Wakefield, reside numa interseção quase invisível entre o OpenSSH e o musl libc, a biblioteca C leve que alimenta Alpine Linux, OpenWrt, Buildroot e inúmeras imagens de contêiner. O resultado: qualquer pessoa com acesso de rede pode fazer login em contas configuradas para rejeitar senhas — incluindo a raiz — simplesmente enviando uma senha entre 257 e 1.024 caracteres.

A correção já está disponível desde 5 de novembro (OpenSSH 10.6p2), mas o código de exploração pública apareceu quatro horas depois. Até 9 de novembro, a CISA já havia adicionado a falha ao seu catálogo de Vulnerabilidades Exploradas Conhecidas (KEV), com prazo de 12 de novembro para mitigação em agências federais dos EUA. Firms como GreyNoise, watchTowr, Previdian e Defused confirmam exploração ativa desde 7 de novembro.

Como o *sshole funciona

A mecânica da falha é elegante na sua simplicidade. Quando o sshd do OpenSSH roda em um sistema com musl libc sem PAM (Pluggable Authentication Modules), a verificação de senha opera em modo simplificado: o sshd solicita que a biblioteca C faça o hash da senha informada e compara o resultado com o valor armazenado no `/etc/shadow`. Contas que devem rejeitar login por senha têm um asterisco (`*`) no campo de hash.

Aqui está o problema: o musl libc, quando recebe uma senha com mais de 256 bytes para hash, falha silenciosamente e retorna `*` — o mesmo valor usado para indicar "conta sem senha". O OpenSSH, por sua vez, interpreta esse retorno como correspondência de hash. O resultado é que, ao enviar 257 caracteres (ou qualquer quantidade entre 257 e 1.024) como senha, o atacante obtém acesso bem-sucedido.

A origens do bug remonta a 2016, quando um patch para corrigir uma vulnerabilidade de enumeração de usuários (CVE-2016-6250) introduziu a lógica de comparação. Nove anos depois, Kültekin identificou que o patch não considerava o comportamento específico do musl. Ele descreve a falha em sshhole.com, onde detalha todas as condições necessárias.

Quem está sob risco

Não são todos os servidores Linux que estão em risco. O ataque só funciona quando todas as seguintes condições são verdadeiras:

1. O servidor executa OpenSSH em musl libc (não em glibc — Debian, Ubuntu, Fedora e Red Hat estão seguros) 2. O OpenSSH foi compilado sem PAM (o padrão do Alpine Linux) 3. A autenticação por senha está habilitada (padrão do OpenSSH) 4. Existe pelo menos uma conta com `*` no campo de hash e outra com hash válido no sistema

Essa combinação é comum em: - Alpine Linux — a distribuição mais afetada, com patches backported desde a versão 3.16 - Imagens de contêiner base em Alpine — a imagem oficial `alpine:tiny-cloud` desde a 3.18.11 até a 3.24.3 inclui o usuário `alpine` sem senha e com privilégios `doas` - Roteadores e dispositivos embarcados — OpenWrt, Buildroot e Yocto que usam musl - Imagens de cloud na AWS/Azure — onde o usuário padrão pode ter privilégios de elevação sem senha

Sistemas com PAM habilitado, sistemas com glibc e imagens configuradas via cloud-init (que desativam login por senha) não são afetados.

A linha do tempo da exploração

O cronograma de exploração do *sshole é um caso de estudo sobre velocidade:

- 5 de novembro, 09:14 UTC — OpenSSH 10.6p2 liberado; Alpine publica pacotes corrigidos - 5 de novembro, ~13:00 UTC — código de exploração pública no GitHub - 7 de novembro, 00:46 UTC — GreyNoise registra a primeira exploração bem-sucedida em sua rede de honeypots - 7 de novembro — watchTowr confirma ataques a botnets e mineradores de criptomoeda - 9 de novembro — CISA adiciona CVE-2026-123158 ao KEV com prazo de 12 de novembro

A Previdian identificou 22 tentativas de exploração a partir de 14 ÍPs únicos até 9 de novembro. O GreyNoise confirmou 16 sessões de pós-exploração a partir de 6 IPs maliciosos. Os ataques observados incluem executação de comandos de reconhecimento (`id`, `uname`, `hostname`), criação de novos usuários, alteração de `authorized_keys` e instalação de mineradores.

A resposta da comunidade

A reação do projeto OpenSSH foi incomumente rápida. O desenvolvedor Damien Miller classificou o ajuste como "critical security workaround" e alertou a comunidade via oss-security e Mastodon: "stop reading and set `PasswordAuthentication=no` or disable SSH for these systems IMMEDIATELY".

A equipe do Alpine Linux backportou o fix para todas as versões ativas desde a 3.16 — incluindo releases que já estavam fora de suporte. A equipe ainda recomendou reiniciar o `sshd` após a atualização, pois a variável de estado que detecta senhas inválidas não é reavaliada automaticamente.

A CISA, por sua vez, adicionou a falha ao KEV em 9 de novembro, o que obriga agências federais dos EUA a mitigar o risco até 12 de novembro sob a Diretiva Operativa Vinculante 26-04.

O que fazer agora

Para administradores em pânico, o caminho de menor resistência é claro:

1. Atualize o OpenSSH para 10.6p2 (ou o pacote backported da sua distribuição). No Alpine, rode `apk upgrade -U -a` e compare a versão com a advisory oficial — versões backported podem ter número mais baixo que 10.6p2 2. Se não conseguir atualizar imediatamente, desative autenticação por senha: `PasswordAuthentication no` no `sshd_config`, seguido de reinício do serviço 3. Verifique se há comprometimento: revise `doas` users, `authorized_keys`, arquivos modificados recentemente. Se houver qualquer dúvida de que um login bem-sucedido ocorreu, trate a máquina como comprometida 4. Escaneie a infraestrutura: o Cloudflare Radar SSHole Lab e o Google goonami-scanner oferecem ferramentas de detecção passiva

Por que isso importa

O *sshole é um lembrete desconfortável de que a segurança do ecossistema Open Source depende de cadeias de dependência que se estendem muito além do software em si. O bug não está no OpenSSH — o projeto considera a causa raíz "fora do sshd". Está no musl libc, na forma como a biblioteca C lida com falhas em operações criptográficas. E o musl, por sua vez, é escolhido por desenvolvedores que buscam imagens menores e mais rápidas para contêiners.

O que torna a falha particularmente perturbadora é que ela foi descoberta por um único pesquisador que construiu o OpenSSH de diversas formas — glibc/musl, com/sem PAM, com/sha256/sha512 — e notou uma divergência. A ferramenta de descoberta foi humana, não automática. E, no entanto, a falha já estava lá desde 2016. O que muda não é a existência do bug, mas a capacidade de ferramentas de geração de código assistidas por IA de encontrar esses padrões em escala.

A pergunta que fica não é sobre o *sshole em si — é sobre quantos outros como ele estão esperando por alguém com tempo e curiosidade suficientes para construir o sistema errado e notar que ele se comporta de forma inesperada.

Fontes: BleepingComputer, Cloudflare Radar, BleepingComputer

✓ Fontes independentes cruzadas e verificadas antes da publicação