Um único dispositivo invadido em uma rede Tailscale pode ser usado para obter acesso root a outros servidores que ele consegue alcançar, segundo um pesquisador de segurança que publicou as conclusões nesta semana.
O ataque exige duas condições: o Tailscale SSH (Secure Shell, protocolo de acesso remoto seguro) configurado para permitir encaminhamento de portas, e um atacante que já controle um dispositivo que as regras de acesso da rede permitam conectar ao alvo.
As conclusões foram publicadas em 25 de outubro, em um relatório intitulado Tailworm, de Erica Windisch, da Cyberdione Labs. Windisch testou o Tailscale na versão 1.104.2 e o headscale na versão 0.29.5, servidor autohospedado que algumas redes usam para executar o Tailscale em vez do serviço hospedado pela empresa, durante três dias em um laboratório.
O relatório descreve testes feitos nesses softwares, e não ataques contra redes reais. Até a publicação, o Tailscale não havia emitido nenhum boletim de segurança, nenhum identificador CVE (Common Vulnerabilities and Exposures, sistema de identificação de vulnerabilidades) nem uma versão corrigida.
O Tailscale se manifestou publicamente. Mike Shaver, vice-presidente de engenharia da empresa, escreveu no Reddit que a companhia recebeu o relatório, já vinha analisando as mesmas áreas com especialistas externos em segurança e encontrou problemas que está trabalhando para corrigir. Shaver afirmou que a empresa ainda está apurando quais configurações são afetadas e que “não recomenda que todos desativem o Tailscale SSH”.
O Tailscale SSH não funciona como um servidor SSH comum. Em vez de verificar a senha ou a chave do usuário que se conecta, ele identifica o dispositivo, e uma única regra de acesso decide se aquele dispositivo pode abrir uma sessão SSH com determinado alvo.
Por isso, o ataque não depende de senhas ou chaves roubadas. Ele precisa de uma primeira posição de controle em um dispositivo, que, segundo o relatório, um atacante pode obter pelos meios habituais: uma aplicação web vulnerável, um pacote de software comprometido, phishing ou credenciais de login roubadas. O Tailscale não cria essa primeira brecha.
O quanto um administrador pode fazer depende de onde a rede é executada. No serviço hospedado do Tailscale, o encaminhamento pode ser desativado regra por regra. No headscale na versão 0.29.5, o encaminhamento não pode ser desativado de forma alguma. Por isso, segundo o relatório, todo acesso SSH concedido nessa versão deve ser tratado como se desse acesso root ao alvo.
No laboratório, Windisch demonstrou o problema em etapas. Usando o encaminhamento padrão de portas SSH, uma sessão comum fez com que o processo do Tailscale, que roda com privilégio de root, se conectasse a um socket do sistema que só o root deveria acessar. O teste obteve acesso root e leu o arquivo de senhas do sistema quase imediatamente, sem direitos de administrador.
Um segundo método substituiu um socket pertencente ao root pelo do atacante, permitindo a execução direta de comandos como root em determinados serviços.
Um terceiro método contornou uma verificação de segurança destinada a limitar quais arquivos o encaminhamento pode acessar, explorando uma condição de corrida no sistema entre o momento em que ele verifica um caminho de arquivo e o momento em que o utiliza. Segundo o relatório, nos testes essa cadeia foi além: capturou uma chave usada para registrar novos dispositivos e a usou para incluir a máquina do próprio atacante na rede como um servidor confiável.
Essa última etapa funcionou do início ao fim apenas em redes nas quais o recurso Tailnet Lock do Tailscale não estava ativado. Nas redes que o têm ativado, os segredos necessários foram capturados em trânsito, mas a etapa final não foi concluída.
Windisch descreve o resultado geral como “wormable” (capaz de se propagar automaticamente de um sistema a outro). No laboratório, um único dispositivo comprometido poderia se espalhar para todos os dispositivos que as regras de acesso permitissem, sem senhas, chaves roubadas ou qualquer ação do usuário, em menos de um segundo por etapa.
Nas palavras do relatório, “a malha converte um acesso comum e inicial em acesso privilegiado a toda a frota, na velocidade da máquina”. Essa propagação foi medida em laboratório, e não observada em redes reais.
O relatório aponta dois fatores que a conteriam: regras de acesso escritas como pares únicos de origem e destino, que sozinhas interromperam a propagação, e chaves de dispositivo vinculadas a hardware, como um TPM (Trusted Platform Module, módulo de segurança em hardware) ou um Secure Enclave.
Alguns pesquisadores que leram o relatório questionaram publicamente a descrição de “wormable”, enquanto outros classificaram como grave a descoberta do acesso root.
O problema do SSH é um dos 11 achados do relatório, que também abrange os conectores de aplicativos do Tailscale, seu recurso serve, o relé DERP (sigla para Designated Encrypted Relay for Packets, usado para comunicação entre dispositivos) e o headscale. Windisch disse ao The Hacker News que a escalada de privilégios via SSH “é preocupante”, mas que o achado sobre os conectores de aplicativos “pode ser mais impactante para algumas organizações”. Esse achado, em um recurso experimental chamado conn25, permite que um usuário autorizado envie tráfego para destinos que a equipe de segurança nunca aprovou, incluindo o serviço de metadados de um provedor de nuvem, que pode fornecer credenciais de servidores.
Todos os achados se baseiam apenas no relatório de Windisch. Nenhum outro pesquisador os reproduziu publicamente, e o Tailscale não confirmou as alegações técnicas específicas. Windisch afirmou que o código de prova de conceito por trás dos achados não é público e que o forneceu apenas ao contato de segurança do Tailscale.
Windisch descreveu a divulgação como “relatada, mas não coordenada”, afirmação que também fez no Ycombinator HN. Pelo menos um comentarista da plataforma considerou irresponsável publicar sem antes reportar o problema ao Tailscale.
Em resposta a perguntas do The Hacker News, Windisch disse que, de fato, enviou ao Tailscale uma cópia do relatório e do código de prova de conceito antes da publicação, encaminhando-os ao contato de segurança da empresa no sábado anterior. Ela afirmou também ter levado preocupações sobre a arquitetura do Tailscale ao diretor-executivo da companhia anteriormente e ter publicado um hash de arquivo e recomendado que os usuários desativassem o Tailscale SSH.
O relatório é o mais recente de uma série de problemas na mesma parte do Tailscale. Anteriormente, em 2026, a empresa corrigiu diversas falhas no Tailscale SSH e no tratamento de sockets de servidor, incluindo uma em que o encaminhamento de sockets Unix do SSH podia alcançar um socket privilegiado, na versão 1.98.9.
O que fazer agora
Como não há correção disponível, as medidas possíveis são alterações na configuração do Tailscale SSH e de recursos relacionados. O relatório e as recomendações do próprio Tailscale coincidem na maioria delas.
- Revise as regras de acesso do Tailscale SSH. Escreva-as como pares únicos de origem e destino, que identifiquem um dispositivo e um alvo, e remova regras amplas que concedam acesso por identidade ou tag. O relatório considera as regras por par o único controle que interrompeu a propagação nos testes.
- Desative o encaminhamento de portas SSH sempre que possível. No serviço hospedado do Tailscale, isso é uma configuração por regra. No headscale na versão 0.29.5, não pode ser desativado; por isso, trate todo acesso SSH concedido ali como se desse acesso root ao alvo.
- Remova as permissões de conectores de aplicativos de dispositivos que não precisam delas.
- Remova qualquer encaminhamento tailscale serve que aponte para um socket Unix.
- Ative a expiração de chaves de nó, para que uma chave de dispositivo roubada não permaneça válida para sempre.
- Se um dispositivo estiver comprometido, exclua-o no plano de controle. Reinstalar o sistema da máquina não revoga as chaves que um atacante possa já ter copiado dela.
O Tailscale também sugere ativar o modo de verificação SSH, que acrescenta uma etapa de login antes do início de uma sessão, além de ativar atualizações automáticas. O modo de verificação não corrige a escalada de privilégios; apenas acrescenta mais uma barreira diante dela.
