A vulnerabilidade CVE-2026-123158 expõe servidores Linux que utilizam musl libc e têm o PAM desabilitado a um risco concreto: permite que um atacante remoto obtenha acesso via SSH sem conhecer a senha, contornando a autenticação por senha em condições específicas. O problema foi corrigido pelo OpenSSH na versão 10.6p2. Para equipes técnicas responsáveis por infraestrutura Linux, a atualização e a revisão das configurações de autenticação são medidas urgentes para conter o risco.
CVE-2026-123158: compreendendo a falha
O erro ocorre em sistemas Linux que combinam a biblioteca musl libc — comum em distribuições enxutas como Alpine Linux — e o PAM (Pluggable Authentication Modules) desativado. Nesses casos, o sshd pode interpretar incorretamente senhas muito longas (entre 257 e 1024 bytes), permitindo acesso não autorizado mesmo quando a senha fornecida é inválida. A falha se manifesta quando existe uma conta local com campo de senha '*' (frequente em contas configuradas apenas para login por chave) e ao menos outra conta com senha hash do tipo $5$ ou $6$.
Distribuições como Alpine Linux são especialmente suscetíveis, já que normalmente compilam o OpenSSH sem suporte ao PAM. Já sistemas como Red Hat Enterprise Linux, que utilizam glibc e mantêm o PAM ativo, não são afetados. O impacto é elevado em ambientes de produção, nuvem ou servidores expostos à internet, especialmente onde a autenticação por senha segue ativa e as contas locais não foram revisadas.
O ataque pode ser realizado remotamente, sem necessidade de interação do usuário ou conhecimento prévio da senha. Isso amplia a superfície de risco e exige atenção reforçada em ambientes multiusuário ou automatizados.
Detalhes técnicos: como ocorre a exploração
Para explorar a CVE-2026-123158, o invasor depende de uma sequência de condições:
- OpenSSH rodando em um sistema Linux com musl libc e PAM desabilitado.
- Autenticação por senha ativada no arquivo sshd_config.
- Presença de uma conta local cujo campo de senha no /etc/shadow seja '*'.
- Existência de pelo menos uma conta com hash de senha $5$ (SHA-256) ou $6$ (SHA-512).
O atacante realiza o ataque enviando uma senha especialmente longa durante a tentativa de login SSH. O sshd vulnerável não valida corretamente o tamanho do hash da senha, permitindo o acesso mesmo sem a senha correta. O erro está na manipulação das strings de senha e hash, agravado pela ausência do PAM como camada de autenticação.
Para identificar possíveis explorações, é recomendável monitorar logs de autenticação, buscar tentativas de login com senhas de tamanho incomum e analisar padrões atípicos de acesso. Ferramentas como auditd e a auditoria do kernel Linux podem ser empregadas para rastrear ações suspeitas, especialmente em contas restritas a autenticação por chave.
Cenários de risco: análise aprofundada
- Servidores Alpine Linux em cloud e containers: Ambientes que utilizam Alpine Linux, frequentes em containers e soluções cloud pela leveza, ficam expostos se a autenticação por senha não for explicitamente desativada. Mesmo contas destinadas a login por chave, se mantiverem campo de senha '*', tornam-se vetores de ataque caso existam outras contas com hash $5$ ou $6$.
- Infraestrutura multiusuário: Em servidores com múltiplos usuários locais, é maior a chance de coexistirem as configurações que permitem a exploração. Ausência de auditoria regular sobre usuários e senhas pode deixar brechas não identificadas. Um exemplo é uma equipe DevOps com contas antigas não revisadas.
- Pipelines de automação e CI/CD: Imagens de containers ou VMs baseadas em versões vulneráveis do OpenSSH podem disseminar o risco por todo o ciclo de automação, especialmente se as atualizações não forem automatizadas. Um pipeline que gera múltiplas instâncias a partir de uma imagem Alpine Linux desatualizada propaga a vulnerabilidade em larga escala.
- Ambientes com glibc e PAM: Sistemas como Red Hat Enterprise Linux, que utilizam glibc e mantêm PAM ativado por padrão, não são afetados. Este contraste reforça a importância de entender não só o software, mas também as bibliotecas e opções de compilação envolvidas na distribuição escolhida.
O acesso obtido por meio desta falha pode resultar em shell remoto, instalação de malwares, persistência e busca de privilégios elevados. Ambientes sem políticas rígidas de acesso ou sem confinamento via SELinux ficam ainda mais vulneráveis a danos amplos.
Mitigação: orientações práticas
Para proteger servidores vulneráveis, siga estas recomendações técnicas alinhadas às orientações das distribuições e do OpenSSH:
- 1. Atualize para OpenSSH 10.6p2: Instale a versão corrigida assim que possível. Em Alpine Linux, utilize:
apk update && apk add --upgrade openssh
Após atualizar, reinicie o sshd:
rc-service sshd restart ou service sshd restart - 2. Desative a autenticação por senha se não puder atualizar imediatamente: No sshd_config, configure PasswordAuthentication no e reinicie o serviço.
sed -i 's/^#\?PasswordAuthentication .*/PasswordAuthentication no/' /etc/ssh/sshd_config - 3. Prefira autenticação por chave SSH ou múltiplos fatores: Garanta que todos os acessos se deem por chaves criptográficas e, se possível, adote autenticação multifator para reduzir a superfície de ataque.
- 4. Audite usuários e campos de senha: Revise /etc/shadow para identificar contas com campo de senha '*', usando, por exemplo:
awk -F: '$2 == "*" {print $1}' /etc/shadow
Remova contas desnecessárias e ajuste configurações conforme o uso real. - 5. Monitore e audite acessos: Ative logs detalhados e utilize ferramentas como auditd para identificar tentativas suspeitas. Ajuste /etc/audit/audit.rules para registrar eventos relevantes.
- 6. Implemente confinamento com SELinux: Mantenha o SELinux em modo enforcing e mapeie contas para domínios restritos. Isso limita o alcance de invasores em caso de exploração.
- 7. Atualize imagens de containers e pipelines automatizados: Certifique-se de que todas as imagens base estejam corrigidas antes de novas implantações. Automatize a verificação de versões do OpenSSH em pipelines CI/CD para evitar reincidências.
Reforce a prática de atualização contínua e revisão das configurações de autenticação em todos os ambientes Linux sob sua gestão.
Erros recorrentes e como evitá-los
- Procrastinar atualizações: Adiar a atualização do OpenSSH mantém o ambiente vulnerável. Firewalls ou restrições de rede não substituem a correção da falha, pois o ataque pode partir de usuários internos ou de redes já comprometidas.
- Manter PasswordAuthentication ativado desnecessariamente: Mesmo que o acesso principal seja por chaves, deixar PasswordAuthentication yes ativo expõe contas locais. Desative sempre que possível.
- Esquecer de reiniciar o sshd: Após atualizar ou alterar configurações, reinicie o serviço para garantir que as mudanças entrem em vigor:
systemctl restart sshd ou service sshd restart - Não revisar contas locais e campos de senha: Contas antigas ou sem uso podem ser exploradas. Utilize comandos como awk -F: '$2 == "*" {print $1}' /etc/shadow periodicamente para identificar casos de risco.
- Ignorar ambientes automatizados: Containers e pipelines podem perpetuar a vulnerabilidade se as imagens base não forem atualizadas. Sempre verifique e teste imagens antes de implantar em produção.
- Relaxar políticas de SELinux sem motivo: Manter o SELinux em modo permissivo amplia o impacto de uma invasão. Utilize o modo enforcing sempre que possível para limitar a ação de invasores.
Evitar esses equívocos fortalece a postura de segurança da infraestrutura e reduz consideravelmente a exposição ao risco.
Perguntas frequentes
Quais sistemas são afetados pela CVE-2026-123158?
Servidores Linux que utilizam musl libc e têm o PAM desabilitado, como Alpine Linux, estão vulneráveis. Sistemas baseados em glibc e com PAM ativo (por exemplo, Red Hat Enterprise Linux) não são afetados.
O que fazer se não for possível atualizar imediatamente?
Desative a autenticação por senha no sshd_config, reinicie o serviço sshd e assegure que todos os acessos sejam feitos exclusivamente por chaves SSH. Monitore logs e revise periodicamente usuários e configurações até que a atualização seja viável.
Como identificar se o ambiente está vulnerável?
Verifique se o sistema utiliza musl libc, se o PAM está desabilitado e se o OpenSSH é anterior à versão 10.6p2. Analise o /etc/shadow para contas com campo de senha '*', e se há ao menos uma conta com hash $5$ ou $6$.
Distribuições como Ubuntu são afetadas?
Red Hat Enterprise Linux não é afetada. As informações disponíveis não detalham o caso do Ubuntu, mas a vulnerabilidade está restrita a sistemas Linux que usam musl libc e têm PAM desabilitado.
Conclusão
Para mitigar a CVE-2026-123158, mantenha o OpenSSH atualizado, desative a autenticação por senha quando possível e utilize autenticação por chaves. Revise contas locais e automatize atualizações em ambientes de produção. Para ampliar seu conhecimento em segurança de infraestrutura e DevOps, acesse a plataforma de cursos da Hcode.
Fontes
OpenSSH 10.6p2, OpenSSH, 5 de novembro de 2026.
Security advisory: openssh-server password authentication bypass, Alpine Linux, 5 de novembro de 2026.
CVE-2026-123158, Red Hat Customer Portal, 5 de novembro de 2026.