Tailworm: Uma Caixa Comprometida, Root no Próximo 11 Descobertas Não Corrigidas no Tailscale e o Que Bloquear Hoje à Noite Sua rede privada é privada apenas até que um dispositivo nela seja comprometido. Um novo relatório afirma que o SSH do Tailscale pode transformar esse único dispositivo em root nos demais. Sem patch. Sem CVE. Ainda assim. ---------------------- Em 25 de outubro, a pesquisadora Erica Windisch (Cyberdione Labs) publicou o relatório "Tailworm": 11 descobertas em 5 grupos, testadas no Tailscale 1.104.2 e headscale 0.29.5 entre 22 e 24 de outubro. A questão central: o SSH do Tailscale é executado dentro do tailscaled, e o tailscaled é executado como root. Quando uma sessão encaminha soquetes Unix (ssh -L / -R), as verificações de caminho e operações de arquivo ocorrem com permissões de root. Em seu laboratório, uma sessão comum passou pelo soquete do Docker e leu /etc/shadow. Outra cadeia capturou uma chave de inscrição e se juntou a um node malicioso que parecia um servidor confiável. A propagação levou menos de um segundo por salto. Sem senhas, sem chaves roubadas. 🔹O Que Está Confirmado, O Que Não Está🔹 ▫️ Todos os resultados são reproduções de laboratório, não invasões no mundo real ▫️ O boletim mais recente do Tailscale ainda é TS-2026-013. Nada sobre Tailworm, nenhuma versão corrigida ▫️ O VP de Engenharia Mike Shaver diz que estão analisando e não recomendam que todos desativem o SSH do Tailscale. Sua recomendação: revise políticas e encaminhamentos SSH, ative atualizações automáticas ▫️ A pesquisadora afirma que foi "relatado, mas não coordenado". Críticos no HN chamam o relatório ilegível ▫️ O atacante ainda precisa de um primeiro ponto de entrada: um aplicativo web vulnerável, um pacote envenenado, um implant de phishing ou credenciais roubadas 🔹Por Que Isso Importa Além da TI🔹 Não é a primeira vez este ano. Os boletins TS-2026-006 e TS-2026-009 descreveram caminhos SSH para root, um através de um nome de usuário "-i". Ambos corrigidos na versão 1.98.9. Em julho, um agente de IA usou uma única chave reutilizável do Tailscale para inscrever 181 nodes na rede da Hugging Face. Nenhuma falha foi necessária. Muitos desenvolvedores executam bots, nodes RPC, validadores e agentes de IA em um VPS acessível apenas por meio do Tailscale. A malha é o perímetro. Uma caixa comprometida se torna problema de todas as caixas. 🔹Ações Práticas para Desenvolvedores🔹 📝 Verifique se você realmente o usa. Abra seu arquivo de política e leia a seção ssh. Não é necessário em um node? tailscale set --ssh=false. Mantenha outro método de acesso primeiro, ou você se bloqueará. 📝 O OpenSSH padrão sobre a tailnet ainda funciona e reduz as permissões para o usuário antes do início da sessão. 📝 Reescreva regras SSH por par: uma origem, um destino. Nenhuma regra por tag ou todos os membros. Permissões por par foram o único controle que impediu a propagação no laboratório. 📝 Negue encaminhamentos em cada regra SSH, a menos que você precise. No headscale 0.29.5 você não pode, então trate cada permissão SSH como root. 📝 Remova encaminhamentos serve que apontem para soquetes Unix e permissões de conector de aplicativo não utilizadas. 📝 Ative expiração da chave do node e Tailnet Lock. Substitua chaves de autenticação reutilizáveis por chaves únicas ou efêmeras. 📝 Se um node for comprometido, exclua-o no plano de controle. Reimaging não revoga chaves que já foram copiadas. 📝 Ative atualizações automáticas e acompanhe tailscale.com/security-bulletins. Minha tese se fortalece se o boletim oficial confirmar as descobertas sobre encaminhamento e lançar uma correção de redução de privilégios. Fraqueja se o boletim limitar a maioria desses problemas ao headscale ou configurações incomuns. Zero trust é um arquivo de política. Não uma propriedade do software. Você executa SSH do Tailscale em algo que armazena chaves?