Tailscale SSH : root possible, aucun correctif

Ce qui se passe

Le 25 octobre 2026, Erica Windisch (Cyberdione Labs) a publié Tailworm, un rapport de 11 constats sur Tailscale et sur headscale, le serveur de contrôle auto-hébergé. Le plus lourd : sur un réseau où Tailscale SSH autorise le transfert de port, un appareil déjà piraté peut obtenir root sur les serveurs que les règles d'accès lui permettent de joindre. Les essais, menés trois jours en laboratoire, portent sur Tailscale 1.104.2 et headscale 0.29.5.

À la date de la source, Tailscale n'a émis ni bulletin de sécurité, ni CVE, ni version corrigée.

Le mécanisme

Tailscale SSH ne vérifie ni mot de passe ni clé : il identifie l'appareil, et une règle d'accès décide s'il peut ouvrir une session. L'attaque suppose donc un premier pied dans le réseau (application web vulnérable, paquet piégé, hameçonnage, identifiants volés) que Tailscale ne fournit pas.

Du premier appareil piraté à root, puis à une machine admise dans le réseau (en laboratoire)

Trois méthodes sont décrites :

une session ordinaire avec redirection de port fait se connecter le processus Tailscale, qui tourne en root, à un socket système réservé à root : root et lecture du fichier des mots de passe presque aussitôt ;
un socket appartenant à root, remplacé par celui de l'attaquant, permet d'exécuter des commandes en root contre certains services ;
une course entre la vérification et l'usage d'un chemin de fichier contourne le contrôle qui limite les fichiers accessibles. La chaîne capture une clé d'enrôlement et inscrit la machine de l'attaquant comme serveur de confiance, sauf si Tailnet Lock est activé.

Dans le rapport, un appareil compromis se propage ainsi à tous ceux que les règles autorisent, en moins d'une seconde par étape : le rapport parle de « wormable ». Mesuré en laboratoire, pas observé sur de vrais réseaux. Deux choses l'ont freiné : des règles écrites en paires source-destination, et des clés d'appareil liées au matériel (TPM, Secure Enclave).

Ce qui n'est pas établi

Tout repose sur ce rapport. Personne ne l'a reproduit publiquement, le code de démonstration n'est pas public (transmis au seul contact sécurité de Tailscale) et Tailscale n'a pas confirmé les détails techniques.
Mike Shaver, vice-président ingénierie de Tailscale, a écrit sur Reddit que l'entreprise a reçu le rapport, examinait déjà ces zones avec des spécialistes externes et corrige des problèmes trouvés. Tailscale ne recommande pas de désactiver SSH pour tout le monde ; Windisch conseille au contraire de le désactiver.
Des chercheurs contestent le terme « wormable » ; d'autres jugent l'accès root sérieux. La divulgation est décrite comme « signalée mais non coordonnée ».

Comment s'y prendre

Le rapport et Tailscale se recoupent sur l'essentiel :

Écrire les règles SSH en paires source-destination (un appareil, une cible) et retirer les règles larges par identité ou par étiquette : c'est la seule mesure qui a arrêté la propagation.
Couper le transfert de port SSH. Réglage par règle sur le service hébergé ; impossible sur headscale 0.29.5, où chaque accès SSH doit être traité comme un accès root sur la cible.
Retirer les permissions d'app connector aux appareils qui n'en ont pas besoin (le constat sur conn25, fonction expérimentale, laisse envoyer du trafic vers des destinations non approuvées, dont le service de métadonnées d'un fournisseur cloud).
Retirer tout tailscale serve qui pointe vers un socket Unix.
Activer l'expiration des clés de nœud.
Appareil compromis : le supprimer du plan de contrôle. Le réinstaller ne révoque pas des clés déjà copiées.

Tailscale ajoute le mode SSH check (une étape de connexion avant la session) et les mises à jour automatiques. Le mode check ne corrige pas l'élévation, il ajoute une barrière. Précédent : le bulletin TS-2026-004, corrigé en 1.98.9, portait sur un socket privilégié atteint par le transfert de socket Unix.

Source : The Hacker News, 25 octobre 2026. Source en anglais. Rapport d'origine : Tailworm. Réponse de Tailscale : r/Tailscale.