[ Início ]

Resumo executivo

Em 05/11/2026, o projeto OpenSSH publicou emergencialmente a versão 10.6p2 para mitigar a CVE-2026-123158 (SSHole), uma vulnerabilidade de bypass de autenticação por senha em determinadas instalações Linux com musl libc e OpenSSH sem PAM. Em configurações específicas, um atacante remoto que conheça o nome de uma conta cujo campo de senha contenha * pode autenticar-se sem conhecer a senha legítima, utilizando uma entrada longa (257 a 1024 bytes). Essas contas incluem usuários configurados apenas para acesso por chave e o usuário alpine de certas imagens de nuvem.

Nas configurações afetadas, a exploração pode ocorrer com uma única conexão, sem força bruta. O Alpine Linux é um caso especialmente relevante, pois seu pacote openssh-server é compilado sem PAM. Outros sistemas baseados em musl, como builds específicos de OpenWrt, Buildroot e Yocto, exigem avaliação da implementação e da configuração efetiva do serviço SSH; o simples uso dessas plataformas não implica vulnerabilidade.

O comportamento que contribuiu para a falha remonta a decisões de implementação anteriores, incluindo uma mitigação introduzida em 2016. A recomendação imediata é atualizar o OpenSSH e reiniciar o daemon sshd; se isso não for possível, desativar a autenticação por senha após garantir acesso seguro por chave ou console. A descrição técnica e provas de conceito estão publicamente disponíveis, mas isso não equivale, por si só, à confirmação de exploração maliciosa em campo.

Ficha técnica

Como a falha funciona

Sem PAM, o sshd pode validar a senha por meio de crypt() e comparar o valor retornado com o campo de senha armazenado. Como parte de uma mitigação histórica contra enumeração de usuários por diferenças de tempo (CVE-2016-6210), o processamento de determinados campos inválidos utiliza um salt obtido de outra conta para executar uma operação de hash mesmo quando o alvo não possui um hash válido.

Na musl, crypt() pode devolver o literal * como sinal de erro ao receber uma senha acima do limite admitido. Esse mesmo literal também representa, em determinadas instalações, uma senha não utilizável no arquivo /etc / shadow. Sob as pré-condições descritas, a comparação interpreta o retorno de erro como se fosse um hash coincidente e pode aceitar a autenticação.

Condições para exploração

Uma instalação sem a correção deve ser considerada potencialmente vulnerável quando todas as seguintes condições estiverem presentes:

• O sshd roda sobre musl libc.
• O sshd opera sem PAM. No Alpine, isso vale para o pacote openssh-server e para o openssh-server-pam configurado com UsePAM no.
• PasswordAuthentication está em yes, que é o padrão do OpenSSH.
• Existe ao menos uma conta com campo de senha *.
• Existe ao menos uma outra conta local com hash $5$ ou $6$. Basta uma conta com senha para tornar alcançáveis todas as contas sem senha.

O atacante precisa identificar uma conta elegível. Nomes previsíveis, como alpine, deploy e git, podem facilitar a descoberta, mas a efetiva possibilidade de acesso também depende de regras como AllowUsers, DenyUsers, AuthenticationMethods, PermitRootLogin e blocos Match, bem como da exposição do serviço na rede. A existência das pré-condições deve motivar correção imediata, sem depender de um teste de exploração.

Sistemas afetados

• Alpine Linux: todas as versões verificadas pelo projeto, de 3.16 a 3.24 e edge, com openssh-server (sem PAM) ou openssh-server-pam com UsePAM no.
• Imagens oficiais tiny-cloud do Alpine (qcow2, VHD, AMI), versões 3.18.11 a 3.24.3. Elas trazem o usuário alpine com campo * e doas sem senha. São seguras no primeiro boot, mas tornam-se exploráveis assim que surge na máquina qualquer hash $6$, por exemplo quando um administrador define uma senha de console. A partir daí, o atacante chega a root via doas.
• Outros sistemas baseados em musl que executam OpenSSH sem PAM, segundo o pesquisador: OpenWrt (quando usa OpenSSH no lugar do Dropbear padrão), Buildroot, Yocto e firmwares embarcados derivados.

Contas tipicamente expostas

• Usuários só-chave criados com adduser sem senha ou com usermod -p '*'.
• Usuários vindos de diretório via musl-nscd (nslcd, winbind, sssd), que não têm entrada no shadow.
• O usuário alpine das imagens tiny-cloud.
• root, que no Alpine vem como root:* desde a 3.16. Na configuração padrão, o PermitRootLogin prohibit-password o protege. Ele só fica diretamente exposto com PermitRootLogin yes, mas continua alcançável por escalada a partir de outra conta afetada.

Sistemas não afetados

• Sistemas com glibc (Debian, Ubuntu, RHEL e derivados, Fedora etc.).
• Qualquer sistema em que o sshd usa PAM para autenticação por senha (UsePAM yes).
• Sistemas com PasswordAuthentication no.
• Servidores SSH que não são OpenSSH, como o Dropbear, e sistemas não-Linux, como o OpenBSD.
• Containers baseados em Alpine que não executam sshd, que são a grande maioria dos casos.
• Imagens de nuvem configuradas via cloud-init, que grava PasswordAuthentication no.
• Contas bloqueadas com ! no campo de senha.
• Sistemas em que nenhuma conta possui hash no formato $.

Ações recomendadas (em ordem de prioridade)

Os comandos de diagnóstico e mitigação estão publicados, na íntegra e organizados por finalidade, em um repositório público do Diário do Analista. Antes de executar, confira o escopo e as orientações de segurança; os procedimentos que alteram a configuração SSH exigem acesso alternativo e planejamento de reversão.

Consultar e copiar os comandos operacionais do SSHole (CVE-2026-123158)

1. Identifique se o host está no escopo

Triagem técnica: confirme se a biblioteca C utilizada pelo servidor é a musl, consulte o pacote OpenSSH instalado e examine a configuração efetiva da autenticação por senha e do uso de PAM. Com acesso administrativo autorizado, examine o arquivo de contas protegidas para identificar campos de senha com o marcador de bloqueio e a presença de hashes SHA-256 ou SHA-512. Execute essas verificações localmente, usando procedimentos aprovados pela organização.

Se os critérios forem encontrados em um pacote sem a correção, classifique o host como potencialmente vulnerável e priorize a mitigação. A configuração efetiva deve ser verificada por contexto, inclusive na presença de regras condicionais.

Regras condicionais: além da configuração geral, confira o comportamento efetivo para cada usuário, grupo e endereço de origem relevante, pois diretivas condicionais do OpenSSH podem alterar os métodos de autenticação permitidos. Consulte a documentação oficial da opção de teste contextual do servidor SSH.

2. Atualize o OpenSSH e reinicie o sshd

Aplicação da correção: atualize os pacotes OpenSSH com o gerenciador de pacotes do Alpine Linux, ou aplique o pacote homologado para sua distribuição e seu branch. Reinicie o serviço SSH depois da atualização, preserve a sessão administrativa até verificar um novo acesso e confirme a versão completa do pacote instalado.

Atenção: a atualização do pacote não reinicia automaticamente um processo sshd já em execução. Reinicie o daemon e valide o serviço antes de encerrar a sessão administrativa em uso.

Versões corrigidas do pacote openssh no Alpine:

As point releases 3.21.10, 3.22.8, 3.23.8 e 3.24.4 já incluem o pacote corrigido. Embora a 3.21 tenha encerrado o suporte regular em 01/11/2026, o Alpine publicou pacotes corrigidos até a 3.16. Em ambientes Buildroot, Yocto, OpenWrt ou firmware próprio, aplique a correção correspondente ao build ou o OpenSSH portable 10.6p2 e reconstrua/reimplante a imagem quando necessário.

Importante para inventários e scanners: nas versões estáveis do Alpine, a correção foi incorporada por backport. Uma versão upstream inferior a 10.6p2 não significa necessariamente que o pacote da distribuição esteja vulnerável; compare a versão completa do pacote com a tabela acima.

3. Se não for possível atualizar agora: desative a autenticação por senha

Risco operacional: antes de alterar o SSH, confirme acesso funcional por chave, assegure um caminho de recuperação por console ou gerenciamento fora de banda e mantenha a sessão administrativa aberta até testar a nova configuração.

Mitigação temporária: configure o OpenSSH para não aceitar autenticação por senha, utilizando a diretiva PasswordAuthentication no no arquivo de configuração apropriado. Antes de reiniciar o serviço, garanta acesso alternativo por chave e, quando disponível, por console. Valide a sintaxe e confira o resultado efetivo para os diferentes contextos de usuários e origens. Faça backup e mantenha um procedimento de reversão documentado.

O parâmetro efetivo de autenticação por senha deve permanecer desabilitado para todos os contextos de acesso aplicáveis. A inclusão de arquivos complementares de configuração depende da versão e do arquivo principal usado no host. Verifique também regras condicionais, confirme o acesso por chave em uma nova sessão e documente a reversão.

4. Inventarie containers e appliances

Procure containers baseados em Alpine que executam sshd, comuns em bastions, jump hosts, ambientes de CI e servidores Git. Inclua também roteadores e appliances com firmware baseado em musl.

Inventário de containers: relacione os containers e appliances baseados em musl e determine quais realmente executam o daemon OpenSSH. Ferramentas de gerenciamento de containers e de inventário de ativos permitem correlacionar a imagem-base, os processos em execução e o serviço exposto. Containers Alpine sem servidor SSH não são afetados por esse vetor.

5. Verifique se houve comprometimento

Procure autenticações bem-sucedidas por senha para contas que possuem, ou possuíam à época do evento, marcadores de senha não utilizável. Essa busca é uma triagem inicial, não uma verificação forense exaustiva.

Busca de indícios: consulte logs de autenticação locais e centralizados em busca de eventos do tipo Accepted password associados a contas que, à época do evento, não deveriam aceitar autenticação por senha. Correlacione usuário, IP de origem, horário, sessão e eventual escalada de privilégios. Preserve os registros antes de qualquer alteração potencialmente destrutiva.

Nos hosts expostos, correlacione os eventos com o endereço de origem, horário, sessões e alterações de privilégios. Inspecione o uso de doas ou sudo, contas criadas, arquivos authorized_keys, tarefas agendadas, serviços, conexões de saída e mudanças de configuração. Preserve os registros disponíveis antes de ações que possam sobrescrevê-los; considere logs centralizados, arquivos rotacionados e trilhas de auditoria. Não encontrar eventos nos logs locais não comprova ausência de exploração. Se não for possível descartar acesso não autorizado, trate o host como potencialmente comprometido e siga o processo formal de resposta a incidentes. A atualização impede a exploração por essa via, mas não elimina persistência já estabelecida.

Indicadores de comprometimento

Até a verificação de 05/11/2026, não foram identificados indicadores universais de rede (IPs, domínios ou hashes) associados a uma campanha confirmada. Há, entretanto, indicadores comportamentais úteis para investigação; eles exigem contexto e correlação e não constituem prova isolada da exploração desta CVE.

Contexto

O OpenSSH foi avisado em 04/11/2026 e publicou a correção no dia seguinte, sem período de embargo. Segundo Damien Miller, a decisão se deve à observação recente de redescoberta rápida de bugs por agentes de IA, às vezes em questão de horas. Por isso, o projeto passou a considerar embargos longos uma prática que beneficia principalmente os atacantes. O pesquisador também relata ter usado agentes de IA para testar milhares de combinações de builds e logins.

Para o analista, o recado prático é este: o intervalo entre a divulgação e a exploração tende a ser cada vez menor. Esta falha não deve esperar o próximo ciclo de patching.

Checklist operacional para equipes de infra e SOC

Para executar as verificações e ações aqui descritas, acesse o repositório de comandos do SSHole.

• Localizar serviços OpenSSH expostos e identificar builds que usam musl sem PAM.
• Conferir a presença de contas com campo * e pelo menos um hash $5$ ou $6$, sem testar senhas exploratórias em produção.
• Verificar PasswordAuthentication e regras Match efetivas para os contextos relevantes.
• Instalar o pacote corrigido e reiniciar o sshd; validar o retorno do serviço.
• Se a atualização estiver indisponível, desabilitar autenticação por senha mantendo acesso alternativo seguro.
• Pesquisar autenticações anômalas, escalada de privilégios e persistência em logs locais e centralizados.
• Registrar evidências, decisões de mitigação, versão instalada e resultado da validação no sistema de gestão de incidentes.

Nota de atualização: informações relativas a CVE, CVSS, KEV e exploração em campo refletem as consultas de 05 e 06/11/2026 e podem mudar. Consulte as fontes oficiais antes de aplicar medidas em ambientes de produção.

Referências

• OpenSSH 10.6p2 — notas de release
• Damien Miller — “urgent security release: 10.6p2” (openssh-unix-dev)
• SSHole — descrição técnica do pesquisador (Özgün Kültekin, Wakefield)
• CVE Program — CVE-2026-123158
• Diário do Analista — comandos operacionais para SSHole (GitHub)