Resumo para quem decide

Uma vulnerabilidade de bypass de autenticação no OpenSSH, batizada de SSHole e catalogada como CVE-2026-123158, já está sendo explorada ativamente contra servidores Linux. A falha tem CVSS 3.1 de 8,1 (alta gravidade) e afeta instalações de sshd rodando sobre musl libc sem PAM habilitado, cenário comum em imagens Alpine Linux, muito usadas em contêineres.

O problema está corrigido na versão 10.6p2 do OpenSSH, lançada em 5 de novembro de 2026. Um PoC público apareceu cerca de 4 horas depois do patch, e a primeira exploração bem-sucedida confirmada por sensores externos ocorreu menos de 48 horas após o fix. A vulnerabilidade já está no catálogo KEV da CISA, o que confirma exploração ativa.

Se sua empresa usa Alpine Linux ou qualquer distribuição baseada em musl com SSH exposto, a ação é simples: atualizar para OpenSSH 10.6p2 ou superior, ou, como alternativa imediata, desabilitar autenticação por senha via SSH enquanto o patch não é aplicado. O restante deste post detalha o mecanismo da falha, o que os atacantes fazem depois de entrar, e como verificar se sua infraestrutura foi afetada.

SSHole: como funciona o bypass de autenticação no OpenSSH

A CVE-2026-123158 foi divulgada pelo pesquisador de segurança Ozgun Kultekin e recebeu a classificação CWE-394 (“Unexpected Status Code or Return Value”). O vetor CVSS completo é AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H: ataque remoto, sem necessidade de privilégios prévios nem de interação do usuário, com impacto total em confidencialidade, integridade e disponibilidade. O CVSS classifica a complexidade de ataque como alta, mas na prática a GreyNoise descreve a falha como trivial de explorar, com exploits funcionais publicados.

O bug entre camadas: como musl e OpenSSH se enganam mutuamente

A causa raiz não está isolada em um único componente. Quando um atacante envia uma senha com tamanho exagerado, entre 256 e 1024 caracteres segundo a Previdian, a função de hashing de senha do musl libc retorna um asterisco (*) em caso de erro, em vez de falhar de forma segura. O OpenSSH, por sua vez, interpreta esse * como uma correspondência válida quando o campo de hash da conta em /etc/shadow também é *, valor normalmente usado justamente para desabilitar login por senha nessa conta.

O resultado é que uma conta configurada para nunca aceitar senha passa a aceitar qualquer senha longa o bastante. A correção veio do lado do OpenSSH, que não tratava esse retorno de erro do musl. Por isso a versão do pacote OpenSSH sozinha não diz tudo: o risco depende da combinação com a libc e com a ausência de PAM. Outro caso de falha em componente de base usado por muitos sistemas está no post sobre vulnerabilidades no OpenSSL V.3.

Quem está exposto: musl libc sem PAM e o caso Alpine Linux

A falha afeta sshd do OpenSSH em versões anteriores à 10.6p2, rodando em Linux que usa musl libc sem PAM habilitado. O exemplo mais direto é o Alpine Linux, cuja configuração padrão de servidor OpenSSH usa musl sem PAM, segundo a Previdian e a BleepingComputer. Como Alpine é amplamente usado como base de imagens Docker por ser leve, o alcance potencial inclui ambientes de contêiner que muitas empresas nem sempre monitoram com o mesmo rigor de servidores tradicionais.

Há duas condições que limitam e agravam o problema ao mesmo tempo. Segundo o pesquisador, a falha só atinge contas cujo campo de senha em /etc/shadow é *, como contas que entram apenas por chave; contas com senha válida não são afetadas. E o acesso vira root quando a conta invadida tem privilégio de administrador sem pedir senha. Nas intrusões registradas pela GreyNoise, os atacantes testaram justamente isso, consultando a configuração do doas, o equivalente ao sudo no Alpine.

Não se sabe o número total de sistemas vulneráveis expostos publicamente à internet, nem o volume real de exploração fora dos ambientes de sensores que monitoraram o caso.

Linha do tempo: do patch ao primeiro ataque confirmado

A velocidade entre a correção e a exploração ativa é um dos pontos mais relevantes do caso:

• 5 de novembro, 09:01 UTC: OpenSSH 10.6p2 é lançado com a correção, anunciado na lista oss-security.
• 5 de novembro, 12:19 UTC: o pesquisador publica a análise com o gatilho exato da falha.
• 5 de novembro, 13:16 UTC: primeiro exploit público no GitHub, cerca de 4 horas após o patch.
• 5 de novembro, 15:46 UTC: o ID CVE-2026-123158 é reservado e publicado.
• 6 de novembro: primeiras tentativas de exploração vistas pelos sensores da Previdian.
• 7 de novembro, 00:46 UTC: a GreyNoise registra a primeira exploração bem-sucedida, cerca de 40 horas após o patch.
• 9 de novembro: a vulnerabilidade entra no catálogo KEV da CISA.

Os horários são da linha do tempo publicada pela GreyNoise, montada a partir do OpenSSH, da lista oss-security, do CVE.org, do NVD e do GitHub.

A empresa finlandesa Defused relatou, durante o fim de semana seguinte ao patch, “uma pequena quantidade de atores” tentando explorar o SSHole, descrevendo a atividade como não disseminada. Já a GreyNoise registrou 16 cadeias de exploração bem-sucedidas contra redes que monitora, partindo de 6 endereços IP ligados a atividade pós-exploração, deixando claro que esses números não representam a atividade mais ampla envolvendo a falha. A empresa também registrou 27,5 milhões de varreduras na porta 22 e 20,1 milhões de tentativas de sessão SSH no período, mas fez questão de frisar que esses números não são ataques SSHole confirmados, apenas tráfego geral na porta.

Sensores da Previdian confirmaram exploração bem-sucedida com telemetria própria: 22 tentativas de exploração, partindo de 14 IPs atacantes únicos, em 10 países (Suíça, Dinamarca, Espanha, Irã, Japão, Países Baixos, Noruega, Suécia, Cingapura e Estados Unidos), captadas por 4 sensores.

Com exploit público quatro horas depois do patch, esperar o próximo ciclo mensal de atualização deixa o servidor exposto. Ataques a serviços de acesso remoto não são novidade, como mostramos no post sobre a campanha FortiBleed contra Fortinet.

A empresa de segurança ofensiva watchTower relatou, em 6 de novembro, ter observado exploração do SSHole associada a atividades de botnets e cryptomining, sem detalhar famílias de malware ou payloads específicos.

O que os atacantes fazem depois de invadir: reconhecimento, C2 e o TAC Agent

A GreyNoise documentou em detalhe o comportamento pós-exploração de pelo menos três atacantes distintos, agrupando parte da atividade em um cluster que chamou de “GreyNoise Threat 10” (GT10), responsável por 2 intrusões usando 7 endereços IP.

Reconhecimento de nuvem e tentativas de persistência

Nas intrusões observadas, os atacantes executaram reconhecimento de sistema e de contêiner, consultaram serviços de metadados de nuvem da AWS, Azure e Alibaba Cloud, tentaram ler hashes de senha e chaves SSH do root, e tentaram modificar arquivos authorized_keys para garantir persistência.

Outro atacante, operando a partir do IP 183.220.91.15 (China Mobile Communications Group, AS9808, China), passou quase cinco horas fazendo reconhecimento em um gridpoint da GreyNoise em 7 de novembro: verificou se o sistema rodava em contêiner, consultou metadados das três nuvens citadas e tentou ler chaves SSH do root e hashes em /etc/shadow via doas, sem escrever arquivos nem instalar ferramentas. Um terceiro, a partir do IP 79.116.138.30 (DIGI SPAIN TELECOM, AS57269, Espanha), realizou 2 intrusões em 7 e 10 de novembro, totalizando 17 shells e 76 comandos, com modificação de 3 arquivos.

Arquivos modificados observados por diferentes atacantes incluem /etc/hosts, /root/.ssh/authorized_keys, /home/alpine/.ssh/authorized_keys, /home/alpine/.ash_history, /etc/resolv.conf, /tmp/apk_repos e /tmp/wtest.

O implante TAC Agent: capacidades e limitações observadas

Em um dos casos, um atacante obteve privilégios root e instalou um implante chamado “TAC Agent”, um agente Python de comando e controle. Segundo a análise da GreyNoise (gerada com apoio de LLM e sujeita a atualização), o arquivo fica em /opt/py3/tac_agent.py, tem 89.559 bytes e hash SHA-256 55e6384f6d1648be9b48fb899e46623e9c05eb0df2cbf95f6701680d4e7cbc2a. É a versão 0.1.1, com build datada de 9 de junho de 2026.

O implante é um script Python 3 de arquivo único, usando apenas biblioteca padrão, com comentários, logs e mensagens de erro em chinês. Suas capacidades incluem execução de comandos shell, reconhecimento extenso de sistema, upload e download de arquivos, e autoatualização. O servidor de C2 identificado é https://tac.vpnla.org, que o próprio código do implante identifica como um “Cloudflare Worker”. O enrollment acontece via um POST não autenticado para /agent/register, usando um token fixo embutido no script e compartilhado entre implantações, não exclusivo por vítima. O beacon ocorre a cada 150 segundos (mais jitter de até 1 segundo) via GET para /agent/poll, com o servidor podendo ajustar esse intervalo entre 1 e 300 segundos.

Um detalhe chama atenção: antes de executar um comando shell, o agente verifica com which se os programas necessários existem no sistema. Se não existirem, ele recusa a execução e responde em chinês pedindo que o comando seja reenviado com ferramentas disponíveis. A GreyNoise aponta isso como possível indício de que a operação é conduzida por algum tipo de “planejador” automatizado, que ajusta os comandos conforme o feedback recebido, um sinal de profissionalização nas operações observadas.

Importante: o implante não tem persistência embutida. No caso documentado, os atacantes tentaram garantir persistência configurando manualmente um serviço de inicialização, identificado como /etc/init.d/tac-agent. No episódio analisado, o implante não conseguiu se comunicar com seu servidor C2 em tac.vpnla[.]org e nunca chegou a receber uma tarefa.

As fontes não confirmam a origem dos atacantes. A GreyNoise trata os comentários em chinês no código como um possível indício a combinar com outras evidências, não como atribuição conclusiva, nem detalham se o TAC Agent foi usado contra outros alvos além dos dois casos documentados.

Como corrigir e mitigar o SSHole agora

Patch, workaround e verificação de contas com hash *

A correção oficial é atualizar o OpenSSH para a versão 10.6p2 ou superior o quanto antes. Como alternativa imediata, enquanto o patch não é aplicado, a recomendação é desabilitar a autenticação por senha via SSH nos sistemas afetados, deixando apenas autenticação por chave.

Para verificar se há sinais de exploração, recomenda-se checar:

• Logins por senha bem-sucedidos e inesperados em contas cujo campo de senha em /etc/shadow é * (valor que deveria impedir login por senha).
• Chaves SSH não autorizadas adicionadas a authorized_keys, especialmente em /root/.ssh/authorized_keys ou em diretórios de usuários como /home/alpine/.ssh/authorized_keys.
• Presença de arquivos do TAC Agent ou de serviços de inicialização suspeitos, como /etc/init.d/tac-agent.

A Previdian resume a orientação de forma direta: aplicar o patch imediatamente, validar a exposição de ativos à internet e monitorar por requisições compatíveis com o padrão de exploração.

Indicadores de comprometimento (IoCs) para buscar na sua infraestrutura

Os principais indicadores documentados até agora incluem:

• Domínio de C2: tac.vpnla[.]org.
• Arquivo do implante: /opt/py3/tac_agent.py, hash SHA-256 55e6384f6d1648be9b48fb899e46623e9c05eb0df2cbf95f6701680d4e7cbc2a.
• Arquivo de configuração do agente: ~/.config/tac/agent.json (ou variável de ambiente $TAC_AGENT_CONFIG).
• User-Agent de tráfego C2: TAC-Agent/1.0.
• Arquivo de serviço de persistência: /etc/init.d/tac-agent.
• IPs associados ao cluster GT10: 20.255.63.133, 20.2.81.241, 152.175.65.88, 202.155.94.33, 47.80.65.43 e 209.248.50.17.

A GreyNoise também observou o uso da biblioteca Paramiko (especificamente a versão 5.1.0) em tentativas de senha com tamanho exagerado contra essa CVE, mas ressalta que Paramiko é uma ferramenta de uso geral e sua presença isolada não confirma exploração. As tags de detecção usadas pela GreyNoise são “OpenSSH CVE-2026-123158 Exploit Attempt” e “OpenSSH CVE-2026-123158 Authentication Bypass Attempt”.

O custo de correção aqui é baixo (atualizar um pacote ou desabilitar autenticação por senha), mas depende de visibilidade real sobre quais ativos rodam Alpine ou outras distribuições baseadas em musl na organização, incluindo contêineres que muitas vezes escapam do inventário tradicional de servidores. Outros casos recentes de falhas exploradas em sistemas expostos à internet: servidores GitLab vulneráveis à CVE-2026-97229 e vulnerabilidades no AhsayCBS já exploradas sem correção disponível.

Perguntas frequentes

O que é a SSHole?
É o apelido dado à CVE-2026-123158, uma falha de bypass de autenticação no sshd do OpenSSH que afeta sistemas rodando musl libc sem PAM habilitado, como o Alpine Linux em configuração padrão.

Como a falha funciona na prática?
Uma senha com tamanho exagerado (entre 256 e 1024 caracteres) faz a função de hashing do musl retornar um asterisco em caso de erro. O OpenSSH interpreta esse asterisco como correspondência válida quando o hash armazenado na conta também é *, valor normalmente usado para desabilitar login por senha, permitindo login sem senha correta.

Quais sistemas estão vulneráveis?
Instalações de OpenSSH anteriores à versão 10.6p2 rodando sobre musl libc sem PAM habilitado, e apenas em contas cujo campo de senha em /etc/shadow é *. O Alpine Linux é citado explicitamente como exemplo de distribuição vulnerável em sua configuração padrão de servidor SSH.

A falha já está sendo explorada?
Sim. A vulnerabilidade está no catálogo KEV da CISA, confirmando exploração ativa. GreyNoise e Previdian registraram explorações bem-sucedidas, a Defused viu tentativas, e a watchTower ligou a exploração a botnets e mineração de criptomoeda. A Defused descreve a atividade como ainda não disseminada.

Como corrigir?
Atualizando o OpenSSH para a versão 10.6p2 ou superior. Como mitigação temporária, é possível desabilitar a autenticação por senha via SSH nos sistemas afetados.

O que verificar se eu suspeitar de comprometimento?
Logins por senha bem-sucedidos em contas com hash * em /etc/shadow, chaves SSH não autorizadas em arquivos authorized_keys, e a presença de arquivos ligados ao implante TAC Agent, como /opt/py3/tac_agent.py ou o serviço /etc/init.d/tac-agent.

Para mais detalhes técnicos sobre a falha e a atividade de exploração registrada, veja a cobertura original da BleepingComputer.