Tailscale 1.104.4: falhas no SSH e no Serve e como atualizar

Na noite de 27/10/2026 o Tailscale publicou a versão 1.104.4. Ela corrige as falhas do Tailscale SSH que a empresa tinha anunciado em 26/10 e mais quatro boletins de segurança, do TS-2026-014 ao TS-2026-017, que atingem o Tailscale SSH e o Tailscale Serve. O pior caso é alguém com acesso já liberado alcançar sockets que só o root acessa, como o do Docker ou a API local do tailscaled, e tomar o controle da máquina.

Antes de entrar em pânico: nenhuma dessas falhas é invasão sem login. Todas exigem alguém que já tem algum acesso, seja um dispositivo autorizado pela política da sua tailnet, seja um operador local na máquina. E os boletins não falam em exploração conhecida. Mesmo assim, são falhas sérias, e a correção já está disponível. Abaixo está o que mudou, quem precisa agir, como atualizar e o que fazer se não der pra atualizar hoje.

O que o Tailscale corrigiu na 1.104.4

Em 26/10 o Tailscale publicou uma atualização sobre a investigação do Tailscale SSH. A empresa disse que a maior parte dos problemas é de escalada de privilégio: em algumas situações, quem já pode se conectar pelo Tailscale SSH conseguiria fazer coisas além das permissões do usuário local configurado, podendo chegar a privilégios elevados. A mesma página diz que não recomenda que todo mundo desligue o Tailscale SSH.

Os detalhes estão na página de boletins de segurança. Os quatro boletins dizem a mesma coisa sobre a correção: fixed in Tailscale version 1.104.4 or newer.

TS-2026-014: encaminhamento de socket Unix feito como root

O Tailscale SSH permite encaminhar portas TCP e sockets Unix entre o cliente e o servidor (o famoso ssh -L e ssh -R). O servidor SSH roda dentro do tailscaled, que tem privilégio de root, e ele conferia o caminho do socket só pelo texto, mas fazia a operação como root. Isso abriu três problemas: conexões privilegiadas pelo encaminhamento local (ssh -L), troca de sockets do root pelo encaminhamento remoto (ssh -R) e uma condição de corrida que driblava a lista de caminhos permitidos.

Na prática, quem tinha permissão de encaminhamento conseguia alcançar sockets que só o root acessa, como o socket do Docker ou a API local do tailscaled. Agora o encaminhamento de socket Unix é feito em nome do usuário autenticado, e não mais como root.

Afeta: quem usa o Tailscale SSH e libera encaminhamento local ou remoto nas políticas de acesso.

TS-2026-015: sessão SSH que esgota a memória

Uma sessão SSH autenticada podia fazer a memória do processo tailscaled crescer sem limite, enviando sem parar mensagens de mudança de tamanho de janela e acrescentando variáveis de ambiente. Essa memória continuava ocupada mesmo depois que o cliente desconectava. O resultado era o sistema matar o tailscaled por falta de memória (OOM), o que derruba todas as conexões Tailscale daquela máquina.

Afeta: máquinas que rodam o servidor Tailscale SSH. Precisa de uma sessão SSH permitida pela política.

TS-2026-016: Serve com backend Unix alcançando sockets privilegiados

O Tailscale Serve publica serviços locais na sua tailnet, inclusive serviços que escutam em socket Unix. Havia duas falhas. Primeiro, o encaminhamento TCP para socket Unix não tinha proteção e conectava como root, então dava pra mandar bytes direto para a API local do tailscaled, o que o boletim descreve como tomada completa da máquina. Segundo, a proteção contra links simbólicos só rodava ao recarregar a configuração, e não a cada conexão. Assim, um usuário podia trocar o caminho do backend por um link simbólico depois de configurado e alcançar qualquer socket do root.

Afeta: máquinas em que um operador local pode escrever configurações do Serve, ou em que usuários locais podem escrever nos caminhos usados como backend.

TS-2026-017: permissões trocadas entre mounts no Serve com TLS

Com TLS ligado, o Serve usa HTTP/2, e todas as requisições numa mesma conexão compartilhavam o mesmo contexto. Por causa de uma condição de corrida, o cabeçalho Tailscale-App-Capabilities de um mount podia aparecer em requisições de outro mount. Uma aplicação que usa esse cabeçalho para autorizar acesso poderia liberar respostas para quem só tinha permissão em outra aplicação.

Afeta: máquinas com Serve e TLS ligados e pelo menos dois mounts com exigências de permissão diferentes. O problema depende de requisições simultâneas na mesma conexão.

Você está afetado?

• Usa Tailscale SSH com encaminhamento liberado na política? Afetado pela TS-2026-014, a mais séria do lado do SSH.
• Roda o servidor Tailscale SSH em alguma máquina? Afetado pela TS-2026-015 (risco de queda do tailscaled).
• Usa Tailscale Serve apontando para socket Unix? Afetado pela TS-2026-016.
• Usa Tailscale Serve com TLS e vários mounts com permissões diferentes? Afetado pela TS-2026-017.
• Não usa nem Tailscale SSH nem Serve? Esses quatro boletins não te atingem, mas vale manter o cliente atualizado do mesmo jeito.

Passo 1: confira a versão

Em cada máquina, rode o comando abaixo. A primeira linha mostra a versão do cliente. Com --upstream, o comando mostra também a última versão publicada em pkgs.tailscale.com (referência do CLI).

tailscale version
tailscale version --upstream

Se aparecer qualquer versão abaixo de 1.104.4, atualize. Pra ver a frota inteira de uma vez, abra a página Machines do admin console e olhe a coluna Version: segundo a documentação de atualização, uma seta vermelha indica que há uma atualização de segurança disponível. O filtro Version > Update available mostra só as máquinas desatualizadas.

Passo 2: atualize para a 1.104.4

Os comandos abaixo são os da página oficial de atualização. Use o mesmo gerenciador de pacotes que você usou pra instalar. Às 23h10 de 27/10, o repositório estável já entregava a 1.104.4 para o apt.

Ubuntu e Debian

sudo apt-get update
sudo apt-get install tailscale

Fedora, RHEL 8, CentOS 8 e CentOS Stream 9

sudo dnf update tailscale

CentOS 7 e Amazon Linux 2

sudo yum update tailscale

Pelo próprio CLI

Desde a versão 1.36, algumas distribuições Linux (e o Windows) aceitam atualizar pelo CLI. Dá pra ver antes o que vai acontecer com --dry-run.

tailscale update --dry-run
tailscale update

Docker

A documentação recomenda usar a tag tailscale/tailscale:stable e recriar o container pra pegar a versão nova. Atenção: às 23h10 de 27/10 a imagem v1.104.4 ainda não estava no Docker Hub, e a stable ainda apontava para a 1.104.2. Acompanhe a página da imagem e recrie os containers assim que a 1.104.4 sair. Até lá, use a mitigação do próximo passo onde fizer sentido.

Depois de atualizar, rode tailscale version de novo e confira se aparece 1.104.4.

Não dá pra atualizar hoje? Mitigação temporária

Tanto o boletim TS-2026-014 quanto a página da investigação indicam desligar o encaminhamento do Tailscale SSH, sem desligar o Tailscale SSH inteiro. Pra isso, coloque a variável TS_SSH_DISABLE_FORWARDING=1 no ambiente do serviço tailscaled e reinicie o serviço.

Nos pacotes oficiais para Linux com systemd, o serviço lê as variáveis do arquivo /etc/default/tailscaled (é o EnvironmentFile do tailscaled.service oficial). Acrescente a linha e reinicie:

echo 'TS_SSH_DISABLE_FORWARDING=1' | sudo tee -a /etc/default/tailscaled
sudo systemctl restart tailscaled

O comando de reinício está na referência do tailscaled. Segundo o Tailscale, isso mitiga várias das falhas mais sérias encontradas. Só não serve pra quem depende de ssh -L ou ssh -R por cima do Tailscale SSH.

Também vale fazer o que a página da investigação recomenda:

• Revise as políticas de SSH e deixe o acesso só para os usuários e dispositivos que realmente precisam.
• Aperte temporariamente o acesso a sistemas sensíveis, pra que só quem precisa consiga se conectar.

Para o Serve com backend em socket Unix (TS-2026-016) e o Serve com TLS (TS-2026-017), os boletins só indicam atualizar. Então priorize essas máquinas na fila do patch.

O que conferir depois do patch

1. Todas as máquinas na 1.104.4 ou mais nova. Use a coluna Version e o filtro Update available na página Machines. Não esqueça servidores esquecidos, VMs de laboratório e containers.
2. Configurações do Serve. Rode tailscale serve status em cada máquina e veja quais backends apontam para socket Unix e quem consegue escrever nesses caminhos.
3. Política de SSH. Se ninguém usa encaminhamento, deixe TS_SSH_DISABLE_FORWARDING=1 mesmo depois de atualizar. Menos recurso ligado é menos superfície de ataque.
4. Atualização automática. A documentação explica como ligar o auto-update por tailnet e por máquina. Segundo ela, atualizações de segurança importantes podem ser aplicadas mais rápido.

Se você usa SSH pra dar acesso a servidores, também vale ler como dar e tirar acesso à VM sem chave compartilhada e como acessar um banco em IP privado com túnel SSH. E, se você deixa o socket do Docker ao alcance de outros processos, este alerta é um bom lembrete do que está em jogo: quem chega no socket do Docker manda na máquina. Mais sobre isso em Docker no servidor: o primeiro container não é a arquitetura inteira.

Resumo

• O quê: 4 falhas no Tailscale SSH e no Tailscale Serve (TS-2026-014 a 017), corrigidas na versão 1.104.4, publicada em 27/10/2026.
• Gravidade: podem levar a acesso a sockets do root e à tomada da máquina, mas exigem acesso já autorizado ou operador local. Os boletins não citam exploração conhecida.
• O que fazer: rodar tailscale version, atualizar pelo apt, dnf, yum ou tailscale update, e recriar containers quando a imagem nova sair.
• Se não der hoje: TS_SSH_DISABLE_FORWARDING=1 no ambiente do tailscaled + sudo systemctl restart tailscaled, e apertar as políticas de SSH.

Fontes oficiais: boletins de segurança do Tailscale, atualização da investigação do Tailscale SSH, release v1.104.4 no GitHub, como atualizar o Tailscale e changelog.