Tailscale atualiza investigação sobre o Tailscale SSH e cita escalonamento de privilégios

A Tailscale publicou em 26 de outubro de 2026 uma atualização sobre a investigação das vulnerabilidades no Tailscale SSH. A maior parte dos problemas identificados envolve escalonamento de privilégios. Em certas circunstâncias, quem já está autorizado a conectar por Tailscale SSH pode executar ações além das permissões do usuário local configurado, inclusive obter privilégios elevados.

A exploração depende das permissões do usuário ou dispositivo que se conecta, da configuração do sistema e de outras condições. A empresa ainda verifica o escopo completo e quais configurações são afetadas. Pelo avaliação atual, ela não recomenda que todos desativem o Tailscale SSH. Os engenheiros implementaram correções para a maioria dos problemas e concluem os testes antes de liberar um cliente corrigido, com meta até o fim de terça-feira, 27 de outubro, sujeita à conclusão dos testes.

Enquanto isso, a orientação é revisar as políticas de acesso SSH, limitando-as a quem precisa, e desativar o encaminhamento (forwarding) se não for usado. Para isso, defina TS_SSH_DISABLE_FORWARDING=1 no ambiente do serviço tailscaled e reinicie o serviço. Isso desliga o forwarding sem desativar o Tailscale SSH e mitiga várias das falhas mais sérias. Depois das correções, a empresa promete um security advisory com versões e configurações afetadas e, em seguida, um post técnico sobre as causas.

Em 27 de outubro de 2026, o CEVIU noticiou "Relatório aponta falhas verificadas no Tailscale v1.104.2 e no headscale v0.29.5". Segundo esse relato, no Tailscale SSH o encaminhamento de Unix-socket é executado como root, o que permite escalada de privilégios. A atualização da Tailscale confirma o tema de escalonamento de privilégios e a relevância do forwarding, ao recomendar desativá-lo como mitigação. O texto da empresa, porém, não cita versões nem o headscale.

Para quem opera servidores acessíveis por Tailscale SSH, a leitura prática é: não dá para tratar o acesso de usuários internos como inofensivo. Vale revisar quem pode conectar e a qual usuário local, e desligar o forwarding se ninguém depende dele. Quem tem sistemas sensíveis pode apertar as políticas até o cliente corrigido sair.