Uma pesquisa da Cyberdione Labs identificou falhas no Tailscale SSH que permitiram obter acesso root em servidores durante testes de laboratório. A conexão inicial usava uma conta sem privilégios administrativos, mas o encaminhamento de conexões dava acesso a serviços internos com permissões superiores às daquela conta.
O ataque descrito no relatório começa com um dispositivo já aprovado na rede e sob controle do invasor. Esse dispositivo também precisa ter autorização para acessar o servidor pelo Tailscale SSH, com encaminhamento permitido. Para você que administra servidores pela ferramenta, essas condições ajudam a entender quais conexões estão envolvidas: a pesquisa trata do acesso que um invasor consegue ampliar depois de comprometer uma máquina autorizada. Nos testes publicados, esse caminho permitiu alcançar o Docker no servidor de destino e executar comandos como root.
Direto ao ponto
A primeira medida custa uma alteração por autorização: negar o encaminhamento. Depois, a permissão ampla, que aceita qualquer origem de uma identidade ou de uma tag, vira permissão por par, com origem e destino nomeados. Onde o Tailscale SSH não é necessário, o recurso sai do dispositivo, desde que você confirme outro caminho de acesso antes.
Segundo a pesquisa, o headscale 0.29.5 permite o encaminhamento em toda sessão aceita e não oferece um ajuste para desativá-lo. Nesse ambiente, a pesquisadora orienta tratar cada autorização de SSH como acesso potencial a root e restringir os destinos permitidos.
Por que o encaminhamento do Tailscale SSH permite acesso root
O relatório Tailworm descreve testes com Tailscale 1.104.2 e headscale 0.29.5, realizados entre 22 e 24 de outubro de 2026. As falhas de SSH envolvem o encaminhamento de conexões para sockets Unix no servidor de destino.
Um socket Unix é o canal pelo qual um processo conversa com um serviço da mesma máquina. O Docker, o systemd e o próprio Tailscale usam esse tipo de canal. As permissões do arquivo decidem quais processos podem abrir a conversa. O tailscaled roda como root, então a conexão que ele abre em nome da sessão chega a canais que o usuário da sessão não alcançaria sozinho.
O relatório descreve três caminhos para esse encaminhamento. Com ssh -L, um socket temporário aponta para o serviço do destino. Com ssh -R, o tailscaled remove um socket que pertence ao root e sobe o listener do atacante no lugar dele, o que permite execução de código em daemon que recebe comandos. O terceiro explora o intervalo entre a checagem do caminho e o uso: enquanto a sessão renomeia o caminho em ciclo, o processo com privilégio resolve o nome antigo e opera no arquivo real, como em /run/systemd/private.
O mesmo caminho alcançou o socket de administração do Tailscale e capturou uma chave de inscrição em texto claro. Com a chave, o laboratório inscreveu um nó novo que apareceu como servidor legítimo na tailnet. A inscrição foi executada e revertida no ambiente de teste.
Nos testes, cada salto entre servidores levou menos de um segundo e não exigiu senha nem chave SSH. A propagação ficou limitada aos destinos autorizados pela política. A permissão por par foi o único controle que interrompeu a sequência. Um dispositivo comprometido pode alcançar os servidores que a autorização de SSH permite.
Isso não é o Tailscale sendo invadido
O resumo de uma linha transforma o relatório em invasão do Tailscale. A pesquisa não afirma isso. Não há atacante sem autenticação alcançando dispositivos aleatórios, porque o teste começa em uma máquina que já está na tailnet, com autorização de SSH até o destino e encaminhamento permitido. A pesquisadora descreve o que um invasor faz depois de obter esse ponto de partida.
Também não basta usar o Tailscale só com os seus dispositivos. Não compartilhar a tailnet reduz quantas máquinas podem iniciar a conexão. O requisito, porém, é um dispositivo sob controle do atacante, não um convidado: o notebook com que você administra servidores continua na lista, porque um invasor pode obter o acesso inicial por essa máquina.
A divulgação do Tailworm merece uma crítica
Na nota que acompanha o Tailworm, Erica Windisch, da Cyberdione Labs, defende que tornar as falhas conhecidas imediatamente pode reduzir o tempo até as correções. Ela também menciona a licença aberta do software e a ausência de vínculo com a Tailscale. A página consultada em 26 de outubro de 2026 não apresenta uma cronologia de reporte privado, resposta do fornecedor e prazo combinado para divulgação. Isso limita o que podemos afirmar sobre as conversas entre as partes.
Publicar detalhes que permitem reproduzir um ataque sem uma correção confirmada deixa você administrando servidores expostos enquanto procura uma mitigação. Essa é a consequência que merece crítica: os passos usados para demonstrar a falha também podem orientar sua exploração. O código aberto permite pesquisar e corrigir o software, mas essa liberdade não elimina o benefício de avisar os mantenedores e combinar a publicação com orientações de proteção.
O relatório enumera 11 achados, incluindo problemas no headscale e uma observação de configuração. A lista reúne categorias diferentes de problemas, sem estabelecer 11 CVEs confirmadas do Tailscale ou comprovar uma invasão da infraestrutura da empresa. As falhas de SSH discutidas neste artigo descrevem movimento lateral e escalonamento de privilégios depois do comprometimento de um dispositivo autorizado.
Considero o Tailscale um ótimo software e é lamentável ver essa pesquisa resumida como “Tailscale foi hackeado”. Você precisa conhecer as permissões que tornam o ataque possível para avaliar a sua instalação. Uma manchete que omite essas condições prejudica a compreensão, assim como a garantia de que uma rede só com dispositivos próprios estaria automaticamente protegida.
Como costuma funcionar o reporte de uma vulnerabilidade
Para preparar um envio à empresa, consulte o artigo sobre como reportar uma vulnerabilidade CVE, que inclui um modelo de relatório e orientações para acompanhar a correção.
A divulgação coordenada procura dar ao fornecedor tempo para investigar e corrigir a falha antes que os detalhes de exploração sejam publicados. O guia do CERT/CC descreve esse trabalho conjunto entre pesquisadores, mantenedores e coordenadores. O processo costuma incluir estas etapas, algumas delas em paralelo:
- Descoberta e validação: o pesquisador reproduz a falha em ambiente autorizado e registra as versões, os requisitos de acesso e uma prova de conceito, evitando danos e leitura desnecessária de informações pessoais.
- Consulta à política de segurança: verifica os canais de contato, o escopo permitido e as condições do programa de recompensas, quando houver. No caso da Tailscale, o site oficial informa o endereço security@tailscale.com para receber relatos.
- Envio privado: o relatório apresenta o componente afetado, o impacto, os passos de reprodução e a prova de conceito pelo canal indicado. O pesquisador pode sugerir uma correção, sem precisar entregar um patch para reportar a falha.
- Triagem e correção: os mantenedores reproduzem o problema, discutem a gravidade e desenvolvem a atualização. Pesquisador e fornecedor acompanham os testes e o prazo de divulgação.
- Atribuição do CVE: uma autoridade de numeração, chamada CNA, atribui o identificador quando o caso atende às condições de atribuição do programa. A própria empresa pode ser uma CNA; caso contrário, o relato é encaminhado a uma autoridade que cubra o produto. A reserva pode ocorrer antes da correção, conforme as normas do Programa CVE.
- Divulgação pública: o comunicado informa as versões afetadas, a correção disponível ou as mitigações e os créditos da pesquisa. O registro CVE identifica a vulnerabilidade; sua existência não certifica que ela já foi corrigida.
Os 90 dias são uma referência conhecida, adotada em políticas como a do Project Zero, mas não constituem um prazo universal. Exploração ativa, ausência de resposta e dificuldades de correção podem mudar o calendário. A coordenação também não obriga o pesquisador a esperar indefinidamente: ela permite documentar as tentativas de contato e explicar por que os detalhes serão publicados mesmo sem patch.
No caso do Tailworm, uma cronologia pública permitiria avaliar quanto tempo a Tailscale teve para responder e quais medidas foram discutidas durante esse período. Sem esse registro, a crítica deve se concentrar na exposição dos detalhes de exploração e na falta de informação sobre a coordenação, sem atribuir omissão ao fornecedor ou intenção à pesquisadora.
O que não resolve
Trocar a chave do OpenSSH não corrige essas falhas porque o Tailscale SSH é um servidor incorporado ao cliente. A sessão que ele atende usa a identidade do dispositivo na camada WireGuard, sem exigir uma chave SSH própria. A correção de uma CVE do OpenSSH no Debian trata de outro serviço, ainda que os dois apareçam no mesmo endereço privado.
Restringir o usuário da sessão também não fecha o caminho. O processo que faz o encaminhamento roda como root, então o limite de privilégio do usuário local não alcança o trabalho que ele executa. O laboratório demonstrou o resultado a partir de uma sessão sem privilégio nenhum.
O modo de verificação do Tailscale SSH, que exige uma autenticação no navegador antes de abrir a sessão, não cobre o encaminhamento. A autenticação autoriza a abertura da sessão, mas não restringe o encaminhamento que ocorre dentro dela. Segundo o relatório, a aprovação no serviço da Tailscale vale para os destinos autorizados em modo de verificação durante aquela janela. No headscale testado, essa autorização fica restrita ao par de origem e destino.
A ordem segura para desligar
Confirme outro caminho de acesso antes de mexer no dispositivo que você está usando. A documentação do Tailscale SSH avisa que a mudança pode interromper a sessão atual. Uma máquina sem acesso alternativo exigirá acesso pelo console.
Comece pelos servidores que não precisam do recurso. Neles, o Tailscale SSH sai e a rede continua servindo para você chegar ao OpenSSH instalado na máquina. Ao revisar a instalação, identifique qual dos dois serviços recebe suas conexões, porque o endereço privado aparece nos dois arranjos e não separa um do outro.
No headscale 0.29.5, não há ajuste para negar o encaminhamento. A saída prática é reduzir o conjunto de destinos que aceitam SSH, para que o alcance de uma sessão comprometida caia junto.
Revise também o que está exposto além do SSH. Um encaminhamento de serve para socket Unix leva tráfego de um par autorizado até a interface de administração do nó. O relatório registra uma alteração de preferências aceita por esse caminho. Quando esse encaminhamento foi configurado sem necessidade, ele deve sair.
Se um dispositivo for comprometido, apague o nó no plano de controle. Reinstalar o sistema não revoga uma chave que já foi copiada, porque ela vive em um arquivo que o root lê. A expiração da chave limita o período de uso da identidade copiada.
Na consulta de 26 de outubro de 2026 aos boletins de segurança da Tailscale, não foi localizado comunicado que associasse Tailworm a uma CVE ou a uma versão corrigida. Por isso este texto apresenta os resultados como relato de laboratório. A confirmação da correção precisa vir do fornecedor. O changelog da Promovaweb acompanha as versões publicadas sem substituir esse comunicado.
Para aprofundar a administração de redes e servidores, conheça a Formação DevOps da Promovaweb. Para revisar as permissões da sua instalação com acompanhamento ao vivo, o Desenvolvimento Colaborativo da Dev Side Studio permite trabalhar nessa configuração com o editor e o terminal abertos.
