Falhas por corrigir no Tailscale SSH transformam um dispositivo comprometido em root nos seus vizinhos

Uma avaliação laboratorial publicada a 25 de outubro de 2026 descreve uma cadeia de fragilidades no Tailscale SSH que, em condições específicas, permite a um atacante que já controla um nó de uma tailnet obter root em todos os outros nós a que esse nó consegue chegar. À data de redação não existe CVE, boletim de segurança nem versão corrigida, o que obriga as equipas de defesa a apoiarem-se na configuração em vez das atualizações.

O que aconteceu

A avaliação testou o Tailscale 1.104.2 e o headscale 0.29.5, a alternativa self-hosted ao serviço de coordenação da Tailscale, durante três dias num laboratório controlado. Apenas foi visado software já publicado. Nenhuma rede de produção foi tocada, e o código de prova de conceito foi partilhado em privado com a Tailscale em vez de ser publicado.

O problema central está na forma como o Tailscale SSH gere o reencaminhamento de portas. O Tailscale SSH não autentica o utilizador com palavra-passe ou chave. Identifica o dispositivo que se liga e deixa uma única regra de acesso decidir se esse dispositivo pode abrir uma sessão no destino. Se a regra também permitir reencaminhamento de portas, foram demonstradas três técnicas distintas para escalar uma sessão vulgar até root:

• Reencaminhamento local de socket Unix. O daemon do Tailscale corre como root. Reencaminhar um socket Unix através dele levou o daemon a ligar-se a sockets que só o root deveria conseguir abrir, e o teste leu o ficheiro de palavras-passe do sistema quase de imediato, sem qualquer privilégio de administrador.
• Reencaminhamento inverso de socket. Um socket pertencente ao root foi substituído por um controlado pelo atacante, o que permitiu executar comandos como root contra certos serviços que confiam nesse socket.
• Uma condição de corrida time-of-check / time-of-use. Uma verificação de segurança destinada a limitar os caminhos de ficheiro que o reencaminhamento pode tocar foi contornada explorando o intervalo entre a validação do caminho e a sua utilização.

No laboratório, a terceira técnica foi mais longe. Capturou uma chave usada para inscrever novos dispositivos e utilizou-a para juntar à tailnet uma máquina controlada pelo atacante, como servidor de confiança. Esse último passo só funcionou do princípio ao fim em redes sem Tailnet Lock. Onde o Tailnet Lock estava ativo, os segredos foram igualmente capturados em trânsito, mas a inscrição falhou.

O relatório classifica o resultado como "wormable": um único dispositivo comprometido poderia propagar-se a todos os pares que as regras de acesso permitem, sem palavras-passe, sem chaves roubadas e sem interação do utilizador, em menos de um segundo por salto. Essa afirmação foi contestada publicamente por alguns profissionais, enquanto outros consideram que a descoberta do acesso root é grave por si só. Convém ser rigoroso. A propagação foi demonstrada em laboratório, não foi reproduzida por terceiros e a Tailscale não confirmou as afirmações técnicas concretas.

A cadeia SSH é uma de 11 descobertas da mesma avaliação. As restantes abrangem os app connectors do Tailscale, a funcionalidade serve, o relé DERP e o headscale. Uma delas diz respeito ao modo experimental conn25 dos app connectors, em que um utilizador autorizado poderá encaminhar tráfego para destinos que a equipa de segurança nunca aprovou, incluindo o endpoint de metadados de um fornecedor cloud, que entrega credenciais de servidor.

A posição da Tailscale

A Tailscale respondeu publicamente. O seu vice-presidente de engenharia afirmou que a empresa recebeu o relatório, já estava a rever as mesmas áreas de código com especialistas externos e tinha encontrado problemas que está agora a corrigir. A empresa continua a apurar que configurações são afetadas e não recomenda explicitamente que todos desativem o Tailscale SSH.

A própria divulgação foi descrita pela sua autora como "reportada mas não coordenada". O relatório e a prova de conceito foram enviados ao contacto de segurança da Tailscale antes da publicação, e um hash do ficheiro foi divulgado publicamente juntamente com o conselho de desativar o Tailscale SSH. Não é o primeiro problema nesta parte do produto. No início de 2026, a Tailscale corrigiu vários erros de SSH e de gestão de sockets, incluindo um em que o reencaminhamento de sockets Unix conseguia alcançar um socket privilegiado, na versão 1.98.9.

Porque é que importa

O Tailscale é frequentemente implementado precisamente para substituir VPNs planas por acesso baseado em identidade e privilégio mínimo. O ponto fraco aqui descrito não é o túnel WireGuard, mas o modelo de confiança em torno do SSH: o dispositivo é a identidade, e o reencaminhamento corre dentro de um processo root. Isso significa que o primeiro ponto de apoio do atacante, obtido pelas vias habituais através de uma aplicação web vulnerável, um pacote envenenado, phishing ou credenciais roubadas, passa a ser a única parte difícil. Tudo o resto assenta nas próprias regras de acesso da malha.

Duas coisas travaram a cadeia nos testes, e ambas estão hoje nas mãos do administrador:

• Regras de acesso escritas como pares origem-destino individuais, que nomeiam um dispositivo e um destino, em vez de concessões amplas por identidade de utilizador ou etiqueta.
• Chaves de dispositivo ligadas a hardware como um TPM ou Secure Enclave, que não podem simplesmente ser copiadas de um host comprometido.

Onde o plano de controlo é self-hosted, a margem é menor. No serviço gerido da Tailscale, o reencaminhamento de portas pode ser desligado por regra. No headscale 0.29.5 não pode ser desligado de todo, pelo que cada concessão SSH aí deve ser tratada como equivalente a root no destino.

O que fazer agora

Como não há patch, as mitigações são alterações de configuração. As recomendações da Tailscale e as do relatório coincidem na maioria:

1. Reescreva as regras de acesso SSH como pares explícitos. Remova regras amplas que concedem SSH por identidade ou etiqueta. As regras por par foram o único controlo que conteve a propagação nos testes.
2. Desative o reencaminhamento de portas SSH sempre que possível. No serviço gerido é uma definição por regra. No headscale 0.29.5 não está disponível, por isso assuma root em cada concessão.
3. Retire as permissões de app connector dos dispositivos que não precisam delas e reveja qualquer utilização do modo experimental conn25.
4. Elimine qualquer reencaminhamento tailscale serve que aponte para um socket Unix.
5. Ative a expiração das chaves de nó para que uma chave de dispositivo roubada não permaneça válida indefinidamente.
6. Se um dispositivo for comprometido, elimine-o no plano de controlo. Reinstalar a máquina não revoga chaves que o atacante já possa ter copiado.
7. Ative o SSH check mode e as atualizações automáticas. O check mode acrescenta um passo de autenticação antes de a sessão começar. Não corrige a escalada de privilégios, mas é mais uma barreira à frente dela.

A lição mais ampla é que a segurança de uma rede em malha é exatamente tão forte quanto o alcance que as suas regras permitem. A suposição de que o movimento lateral é difícil assim que um dispositivo está "dentro" da tailnet não se confirma aqui. Os nossos serviços de penetration testing são construídos precisamente em torno desta pergunta: partindo de um único host assumido como comprometido, até onde consegue um atacante chegar de facto através das suas regras de acesso, definições de reencaminhamento e relações de confiança antes de algo o travar? Conhecer essa resposta antes de um intruso real é o que transforma uma revisão de configuração num controlo defensável.