CVE-2026-123158: Bypass de Autenticação por Senha do OpenSSH Afeta Alpine Linux

Uma vulnerabilidade de alta gravidade no OpenSSH pode permitir que atacantes remotos não autenticados contornem a autenticação por senha em determinados sistemas Linux ao enviar uma senha excessivamente longa. Rastreadas como CVE-2026-123158 e apelidadas de SSHhole, a falha possui um escore CVSS 3.1 de 8.1 e impacta principalmente ambientes Linux onde o sshd está vinculado contra a musl libc e opera sem PAM. O Alpine Linux é a plataforma afetada mais proeminente porque seu pacote padrão openssh-server usa essa configuração por padrão.

A vulnerabilidade resulta de uma interação inesperada entre a validação de senha do OpenSSH e a implementação crypt() da musl libc. Quando uma senha excessivamente longa é fornecida, crypt() pode retornar a string * para indicar um erro. Algumas contas Linux que são configuradas sem uma senha convencional também armazenam * no campo de senha de /etc/shadow. Em condições vulneráveis, o sshd pode interpretar incorretamente os valores correspondentes como autenticação bem-sucedida.

Um atacante não precisa saber a senha do usuário alvo. Se um serviço SSH exposto atender às condições necessárias, um atacante que puder acessar o serviço poderá autenticar determinadas contas usando uma senha no intervalo de comprimento vulnerável. O impacto depende dos privilégios atribuídos à conta comprometida. O acesso a uma conta de serviço privilegiada ou a uma conta capaz de usar o doas ou outro mecanismo de escalonamento de privilégios pode levar a um comprometimento completo do sistema.

Entre em contato com Vendas

O OpenSSH abordou a questão no Portable OpenSSH 10.6p2, lançado em 5 de novembro de 2026. O Alpine Linux lançou simultaneamente pacotes OpenSSH corrigidos para todos os ramos suportados e para vários ramos mais antigos. A equipe do OpenSSH descreve o lançamento como contendo um contorno de segurança crítico para sistemas Linux que usam musl libc com o PAM desativado.

Ambientes de reprodução pública e material de prova de conceito já estão disponíveis. No entanto, a partir de 6 de novembro de 2026, as fontes analisadas não relatam explorações confirmadas da vulnerabilidade em ataques no mundo real, e a falha não foi adicionada ao catálogo de Vulnerabilidades Conhecidas Exploitadas da CISA.

As organizações podem fortalecer as defesas contra vulnerabilidades emergentes de bypass de autenticação com a Plataforma de Inteligência de Detecção Nativa de IA da SOC Prime, acelerando a caça de ameaças e engenharia de detecção em ambientes SIEM, EDR, XDR e Data Lake.

As equipes de segurança também podem usar o Prime Architect para transformar inteligência de vulnerabilidade em consultas de caça e lógica de detecção adaptadas ao SSH, autenticação, endpoint e telemetria de rede disponíveis.

Detecte a CVE-2026-123158 monitorando logins SSH baseados em senha bem-sucedidos para contas que normalmente usam autenticação somente por chave, tentativas de autenticação incomuns contendo senhas excessivamente longas, acessos remotos inesperados a contas de serviço e atividade pós-autenticação inconsistente com o comportamento normal da conta.

Conteúdo de detecção pode não estar disponível para todas as CVEs. Verifique a Plataforma SOC Prime para cobertura atual. Se detecções relevantes ainda não estiverem disponíveis, verifique novamente, pois novas informações de inteligência de ameaças e conteúdo de detecção são continuamente adicionados.

Análise da CVE-2026-123158

A CVE-2026-123158 afeta o OpenSSH sshd antes do Portable OpenSSH 10.6p2, quando é executado em Linux com musl libc e ocorre autenticação via senha sem PAM. A CVE tem um escore CVSS 3.1 de 8.1 com o vetor AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, refletindo exploração remota sem privilégios prévios ou interação do usuário, mas exigindo uma configuração específica do sistema e da conta.

A causa raiz está na interação entre o OpenSSH e a função de hashing de senha fornecida pela musl libc.

Em sistemas onde o PAM está desativado, o sshd realiza a validação de senha usando a funcionalidade crypt() do sistema. Para uma conta típica, /etc/shadow contém um hash de senha criptográfico, e o valor gerado a partir da senha fornecida pelo usuário é comparado com aquele hash armazenado.

A musl libc se comporta de maneira diferente quando a senha fornecida excede seu comprimento de entrada suportado. Para senhas com mais de 256 bytes, crypt() retorna * como um valor de erro em vez de um hash de senha normal.

O problema surge porque * também é comumente usado em /etc/shadow para contas que não têm uma senha tradicional configurada.

Se um sshd vulnerável receber uma senha muito longa para uma dessas contas, o fluxo de autenticação pode efetivamente comparar o * retornado por crypt() com o * armazenado na entrada shadow da conta. Os valores correspondem, e a autenticação pode erroneamente ser bem-sucedida.

A descrição da CVE afirma que, para configurações de conta afetadas, senhas entre 256 e 1024 caracteres podem resultar em autenticação bem-sucedida. Reproduções independentes descrevem senhas que excedem o limite normal de 256 bytes como suficientes para acionar a condição vulnerável.

Portanto, a falha não é um bypass universal de senha que afeta todas as implantações de OpenSSH.

Várias condições específicas devem se alinhar.

Primeiro, o servidor deve usar a musl libc. O Alpine Linux é o exemplo principal de mainstream, embora outros ambientes Linux minimalistas ou incorporados também possam usar musl.

Em segundo lugar, o sshd deve autenticar usuários sem PAM. O pacote padrão openssh-server do Alpine é construído sem PAM, enquanto a configuração alternativa openssh-server-pam é protegida quando UsePAM yes está ativado.

Terceiro, a autenticação por senha deve estar habilitada. PasswordAuthentication yes é a configuração relevante. Sistemas configurados para autenticação somente por chave pública com PasswordAuthentication no não estão expostos ao caminho de ataque documentado.

Finalmente, o atacante precisa de uma conta cujo campo de senha contenha *. Estas podem incluir usuários apenas por chave, contas criadas sem senhas, algumas identidades fornecidas por serviços de diretório e certos usuários de imagem em nuvem.

O Alpine também observa uma condição adicional: pelo menos uma conta local deve conter um hash de senha no estilo $5$ ou $6$ para que o caminho de autenticação vulnerável funcione como descrito.

A conta root merece atenção especial. O Alpine geralmente armazena root:*, mas o padrão PermitRootLogin prohibit-password do OpenSSH impede a autenticação por senha diretamente para o root. Como resultado, uma instalação padrão do Alpine não expõe automaticamente o login direto de root por meio desse bug.

Essa proteção não elimina o risco mais amplo. Se outra conta com * no campo de senha estiver acessível remotamente e tiver direitos administrativos por meio do doas, sudo, capacidades de container ou outros mecanismos privilegiados, a autenticação bem-sucedida ainda pode fornecer um caminho para comprometimento completo do sistema.

As imagens tiny-cloud oficiais do Alpine são particularmente relevantes. A pesquisa de segurança identificou versões onde a conta alpine poderia atender às condições vulneráveis e também poderia usar o doas para obter privilégios elevados. Isso ilustra por que os defensores devem avaliar os privilégios da conta em vez de presumir que a vulnerabilidade fornece acesso ao usuário inofensivo ou acesso root automático em todos os ambientes.

Distribuições Linux baseadas em glibc, como Debian, Ubuntu e RHEL, não são afetadas por essa vulnerabilidade específica porque o comportamento vulnerável depende da implementação de hashing de senha do musl libc. Sistemas que usam PAM para validação de senha SSH também estão fora da configuração vulnerável documentada.

Contêineres exigem qualificação semelhante. O Alpine é amplamente usado como imagem base de contêiner, mas contêineres comuns que não executam sshd não são vulneráveis a este caminho de ataque. A principal preocupação são contêineres, appliances, ambientes de desenvolvimento ou cargas de trabalho legadas que instalam e expõem explicitamente um servidor SSH.

O cenário de PoC da CVE-2026-123158 se desenvolveu rapidamente. Ambientes de reprodução pública são referenciados diretamente pelo registro de vulnerabilidade, demonstrando que os defensores devem assumir que o bypass de autenticação pode ser reproduzido sem acesso exclusivo à pesquisa de exploits privados. Isso aumenta significativamente a urgência da remediação, mesmo que a exploração maliciosa confirmada ainda não tenha sido relatada.

A vulnerabilidade foi relatada por Özgün Kültekin de Wakefield. O OpenSSH lançou publicamente a versão 10.6p2 com o contorno de segurança em 5 de novembro de 2026. As fontes primárias revisadas não especificam a data exata em que o pesquisador inicialmente descobriu ou relatou o problema em privado.

A correção do OpenSSH adiciona uma validação projetada para impedir que valores de erro e hashes de senha curtos inválidos sejam aceitos durante a autenticação por senha. O OpenSSH observa que considera a causa raiz subjacente existente fora do sshd, mas, como a condição pode ser explorada através do servidor SSH, o projeto implementou uma solução defensiva no próprio OpenSSH.

O Alpine Linux fez um backport da correção em vários ramos:

Ramo Alpine	Pacote OpenSSH Corrigido
edge	10.6_p2-r0
3.24	10.3_p1-r2
3.23	10.2_p1-r1
3.22	10.0_p1-r11
3.21	9.9_p2-r1
3.20	9.7_p1-r6
3.19	9.6_p1-r3
3.18	9.3_p2-r4
3.17	9.1_p1-r7
3.16	9.0_p1-r6

Os administradores devem confiar no status do pacote de distribuição em vez apenas no banner de versão do SSH. As distribuições Linux frequentemente aplicam patches de segurança sem alterar a versão do OpenSSH exibida durante o handshake SSH. Um servidor exibindo uma string de versão mais antiga pode, portanto, já conter a correção do fornecedor.

Para a detecção da CVE-2026-123158, os defensores devem priorizar a telemetria de autenticação SSH. Um sinal de caça particularmente forte é um login com senha bem-sucedido em uma conta que é destinada a usar apenas autenticação por chave pública ou que não possui uma senha utilizável configurada.

Em sistemas Alpine, os administradores podem revisar /var/log/messages, logs centralizados de autenticação, registros SIEM ou telemetria equivalente para eventos de senha aceita envolvendo contas administrativas, de serviço inesperadas ou somente por chave.

Os defensores devem correlacionar a autenticação bem-sucedida com endereços IP de origem, horários de login, duração da sessão, comandos executados após o login, elevação de privilégios, alterações em authorized_keys, criação de contas, trabalhos agendados e conexões de rede externas inesperadas.

A telemetria de rede também pode ajudar a identificar sistemas expostos. Serviços SSH acessíveis externamente que anunciam autenticação por senha ou teclado interativo devem receber uma prioridade de remediação mais alta, especialmente quando o sistema subjacente é Alpine ou outra distribuição baseada em musl.

Atualmente, não há IOCs CVE-2026-123158 como endereços IP de ataque confirmados, domínios, hashes de malware ou infraestrutura de comando e controle. A ausência de indicadores estáticos torna o monitoramento comportamental da autenticação SSH e da atividade subsequente da sessão particularmente importante.

Mitigação da CVE-2026-123158

A remediação principal é instalar o OpenSSH 10.6p2 ou o pacote corrigido fornecido pela distribuição Linux. Os administradores do Alpine devem atualizar o sistema completo usando os repositórios de pacotes atuais e reiniciar o sshd posteriormente. Atualizar apenas o pacote não substitui o processo do daemon SSH já em execução.

As organizações que executam contêineres baseados no Alpine devem reconstruir e reimplantar qualquer imagem que instale o openssh-server. Apenas atualizar o sistema operacional host não corrige pacotes OpenSSH vulneráveis incorporados dentro de imagens de contêiner.

Os administradores também devem identificar a exposição antes de supor que todos os hosts Alpine são vulneráveis. As verificações importantes incluem:

1. Determine se o host usa musl libc.
2. Verifique se o sshd está em execução com o PAM desativado.
3. Confira se a autenticação por senha está habilitada.
4. Identificar contas capazes de fazer login cujo campo de senha em /etc/shadow seja *.
5. Reveja os privilégios atribuídos a essas contas.
6. Confirme o pacote OpenSSH instalado em relação à versão corrigida do pacote da distribuição.

Se o patch imediato for impossível, as organizações devem desativar a autenticação de senha SSH.

Configure:

PasswordAuthentication no

e, onde aplicável:

KbdInteractiveAuthentication no

Os administradores devem confirmar que a autenticação por chave pública funciona antes de aplicar esta configuração para evitar perder acesso administrativo legítimo.

A configuração SSH deve então ser validada e o daemon recarregado ou reiniciado. Posteriormente, a verificação externa deve confirmar que o servidor oferece apenas autenticação por chave pública.

Restringir a acessibilidade da rede proporciona defesa em profundidade adicional. O SSH geralmente deve ser acessível apenas a partir de redes administrativas confiáveis, infraestrutura VPN, hosts de bastião ou listas de permitidos de IP de origem explícitos, em vez de ser universalmente exposto à internet.

As organizações também devem reconsiderar se o SSH é necessário dentro dos contêineres. Ambiente de orquestração modernos geralmente fornecem alternativas como docker exec ou kubectl exec, eliminando um serviço de autenticação remotamente acessível desnecessário.

Para sistemas potencialmente expostos, reveja logins de senha bem-sucedidos históricos ocorridos antes da remediação. Preste atenção especial a contas configuradas sem senhas e identidades normalmente esperadas para autenticar exclusivamente com chaves SSH.

Se um login bem-sucedido inesperado for identificado, trate a conta como potencialmente comprometida. Revise o histórico do shell, onde disponível, a execução de processos, a escalonamento de privilégios, novas ou modificadas entradas authorized_keys, alterações de usuários e grupos, trabalhos cron, scripts de inicialização, instalação de pacotes e conexões de rede externas.

Credenciais e chaves acessíveis à conta comprometida devem ser consideradas potencialmente expostas e rotacionadas de acordo com as descobertas da investigação. Se a conta tinha privilégios administrativos, os defensores devem expandir a investigação para todo o host e quaisquer sistemas acessíveis usando credenciais armazenadas lá.

Material público de prova de conceito significa que as organizações não devem esperar por evidências de ataques generalizados antes de aplicar a correção. Os pré-requisitos de exploração estreitam a população vulnerável, mas os sistemas que atendem a essas condições podem ser acessados remotamente sem conhecimento de uma senha válida.