Relatório aponta falhas verificadas no Tailscale v1.104.2 e no headscale v0.29.5

O relatório, assinado por Erica Windisch (Cyberdione Labs), audita o cliente Tailscale v1.104.2, o servidor de controle headscale v0.29.5, a biblioteca gliderssh e o recurso experimental conn25. Os testes rodaram entre 22 e 24 de outubro de 2026, em laboratório, com software sem modificações. O ponto central é o Tailscale SSH: ele não faz autenticação de usuário (o método é none), e a identidade do dispositivo, já validada pela camada WireGuard, é o que a política avalia. Com isso, quem tem um foothold em um dispositivo autorizado consegue usar o encaminhamento de Unix-socket, que roda como root, para escalar privilégios, substituir sockets, apagar arquivos e capturar as chaves de enrollment.

O conn25 recebe do cliente um destino que, segundo o relatório, não é validado de forma adequada. Isso abre caminho para metadados de cloud, LANs internas e serviços Kubernetes. No headscale há esgotamento de memória sem autenticação e bloqueio de onboarding. Os pesquisadores medraram a propagação em laboratório: com SSH liberado por política, o espalhamento levou menos de um segundo por salto. O que barrou foram as concessões por par e as credenciais vinculadas a hardware (TPM/Secure Enclave). No headscale v0.29.5, o encaminhamento SSH não pode ser desativado, então cada concessão deve ser tratada como equivalente a root.

A atualização de 27 de outubro de 2026 traz correções já nos repositórios públicos (branch main), mas sem release numerada na hora da redação. Entre elas estão o redesenho do encaminhamento SSH com processos filhos sem privilégio, limites na troca de window-change e de variáveis de ambiente no gliderssh, bloqueio do serve --tcp para o socket localapi e leitura limitada no componente de relay. A Tailscale prometeu um cliente corrigido até o fim de 27 de outubro de 2026, sujeito a testes. Até lá, as mitigações do relatório valem para tailscale até v1.104.2 e headscale até v0.29.6.

Para quem opera uma tailnet com SSH habilitado em toda a frota, a leitura é direta: regras amplas por identidade ou tag transformam um host comprometido em acesso privilegiado a muitos outros. Revisar as concessões para o formato por par, desativar o encaminhamento onde der e tirar a telemetria do alcance dos servidores são medidas que dependem de configuração, não de patch. Na resposta a incidentes, reinstalar o host não revoga chaves já copiadas, então a exclusão do nó no control plane precisa entrar no runbook.