SSHole: a falha que conecta qualquer conta sem senha em servidores Linux

A descoberta e exploração pública de uma vulnerabilidade de contorno de autenticação no OpenSSH — batizada de SSHole e rastreada como CVE-2026-123158 — trouxe à tona um problema que permaneceu latente por dez anos, desde 2016. Com pontuação CVSS de 8.1 (alta), a falha afeta exclusivamente servidores OpenSSH rodando em distribuições Linux baseadas na biblioteca C musl libc sem o módulo PAM (Pluggable Authentication Modules) ativado — o caso típico do Alpine Linux e de muitas imagens de contêiner. A CISA já catalogou a vulnerabilidade como sendo explorada ativamente no mundo real e impôs um prazo de remediação de 12 de novembro para agências federais dos Estados Unidos.

Como funciona a falha

A mecânica do SSHole é elegante na sua simplicidade. Administradores de servidores Linux frequentemente configuram contas de serviço bloqueando o login por senha — basta substituir o hash de senha no arquivo `/etc/shadow` por um asterisco (`*`). Essa conta não deveria aceitar nenhum login por senha, pois o asterisco não representa um hash válido.

O problema nasceu de um patch de 2016 destinado a corrigir aCVE-2016-6210, uma vulnerabilidade de enumeração de usuários. Para impedir que atacantes identificassem nomes de usuário válidos através de tempos de resposta diferentes, o OpenSSH foi modificado para executar o hashing de senha mesmo quando a conta não possuía hash utilizável — incluindo contas configuradas com `*`.

Aqui reside o conflito: a função `crypt()` da biblioteca musl libc retorna `*` quando o hashing falha, inclusive quando a senha submetida excede seu limite de 256 bytes. O OpenSSH, por sua vez, compara o valor retornado pelo hashing contra o asterisco armazenado no `/etc/shadow`. O resultado: o login é bem-sucedido. Qualquer senha entre 257 e 1.024 caracteres funciona como chave mestra.

O pesquisador Ozgun Kultekin, que descobriu e divulgou a vulnerabilidade, afirma que a exploração requer cinco condições simultâneas: OpenSSH em sistema musl, PAM desativado, autenticação por senha habilitada, ao menos uma conta com hash `*`, e outra conta com hash válido (`$5$` ou `$6$`). Com isso, comprometer uma única conta com senha torna todas as contas sem senha acessíveis.

O que está realmente afetado

O impacto é mais grave em ambientes de nuvem e IoT. As imagens oficiais tiny-cloud do Alpine Linux (qcow2, VHD e AMI) das versões 3.18.11 a 3.24.3 vêm com um usuário `alpine` cujo campo de senha é `*` e possui privilégios `doas` sem senha. Na primeira inicialização, estão seguras. No momento em que algum administrador configura um usuário com senha, a máquina fica vulnerável. Um atacante obtém um shell como `alpine` e usa `doas` para se tornar `root`.

Sistemas baseados em glibc — Debian, Ubuntu, Fedora, Red Hat, SUSE — não são afetados, pois a implementação do `crypt()` no glibc não retorna `*` nas mesmas condições. Da mesma forma, sistemas que utilizam PAM estão protegidos, pois a cadeia de autenticação do PAM intercepta a requisição antes que o bug no OpenSSH se manifeste.

Kultekin descobriu a falha usando agentes de inteligência artificial que executaram aproximadamente 17.600 testes de autenticação com diferentes configurações do OpenSSH, hashes de senha malformados e senhas de tamanho excessivo — um exemplo notável de como a automação por IA está sendo empregada tanto para descobrir quanto, provavelmente, para explorar vulnerabilidades.

Exploração ativa e escala do ataque

As primeiras tentativas de exploração foram registradas em 5 de novembro de 2026, logo após a divulgação pública do patch e do código de prova de conceito. A watchTower, empresa de segurança ofensiva, observou na manhã de 6 de novembro ataques associados a botnets e mineradores de criptomoedas. Até 9 de novembro, a Previdian havia registrado 22 tentativas bem-sucedidas a partir de 14 endereços IP únicos, distribuídos por 9 países.

A CISA adicionou a vulnerabilidade ao seu Known Exploited Vulnerabilities (KEV) catalog em 9 de novembro, classificando-a como exploração confirmada em ambiente produtivo. O mandato de remediação para agências federais civis dos Estados Unidos é 12 de novembro, prazo de apenas três dias após a listagem — um dos prazos mais agressivos já estabelecidos pela agência.

Além da lista do KEV, a CISA invocou requisitos de triagem forense, sugerindo que entidades afetadas devem investigar se seus ambientes já foram comprometidos. Ferramentas de detecção, como o Goonam Scanner do Google, já estão sendo usadas para varrer ativos expostos em larga escala.

Mitigação e remediação

O OpenSSH 10.6p2, lançado em 5 de novembro, corrige o problema definitivamente. As versões corrigidas do Alpine Linux são:

- Alpine 3.21.10 - Alpine 3.22.8 - Alpine 3.23.8 - Alpine 3.24.4

Administradores que não podem atualizar imediatamente devem desabilitar a autenticação por senha:

``` PasswordAuthentication no ```

Em seguida, reiniciar o daemon `sshd`.

Para verificar possíveis comprometimentos em Alpine Linux, execute:

``` grep "Accepted password" /var/log/messages ```

Se o log mostrar login por senha bem-sucedido para uma conta sem senha (como `alpine`, `root` ou qualquer usuário key-only), trate a máquina como comprometida. Revise o uso do `doas`, usuários recentemente criados, arquivos suspeitos e chaves SSH não autorizadas em `/root/.ssh/authorized_keys`.

O que a falha revela sobre a segurança do ecossistema Linux

O SSHole expõe dois problemas estruturais do ecossistema de código aberto. Primeiro, a fragmentação de bibliotecas C — musl vs. glibc — cria vetores de ataque que passam despercebidos em testes convencionais, já que a vasta maioria dos pesquisadores e ferramentas de auditoria opera em ambientes glibc. Segundo, a descoberta de uma vulnerabilidade de dez anos por meio de teste automatizado por IA sinaliza uma mudança de paradigma: o pentesting impulsionado por agentes autônomos está se tornando uma ameaça real e acessível. Se agentes de IA podem encontrar falhas como essa em 17.600 tentativas, não é difícil imaginar que os mesmos agentes (ou seus adversários) estejam explorando essas mesmas falhas simultaneamente.

A pergunta que fica: quando agentes de segurança autônomos se tornarem tão comuns quanto os agentes maliciosos, a corrida entre detecção e exploração será vencida por quem?

---

Fontes: BleepingComputer (nov. 9, 2026), SecurityWeek (nov. 6, 2026), CVE Details (CVE-2026-123158), Alpine Linux Security Advisory (nov. 5, 2026)

Fontes: BleepingComputer, SecurityWeek, Alpine Linux, CVE Details

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