« Tailworm » : des failles Tailscale SSH permettent une élévation vers root

Le 24 octobre 2026, la chercheuse Erica Windisch (Cyberdione Labs) a publié « Tailworm », un audit de sécurité de Tailscale et de headscale qui recense onze vulnérabilités. Le cœur du rapport concerne Tailscale SSH : un utilisateur autorisé à se connecter, même avec un compte ordinaire, pouvait obtenir les privilèges root sur le serveur cible en abusant du transfert de sockets Unix. Enchaînées, ces failles ont permis en laboratoire une propagation automatique de machine en machine, en moins d’une seconde par rebond. Le rapport ayant été rendu public environ deux heures après sa transmission à l’éditeur, Tailscale a dû livrer les correctifs dans l’urgence : ils sont disponibles depuis la version 1.104.4.

Ce qui s’est passé

Tailscale est un réseau privé maillé fondé sur WireGuard, largement utilisé pour l’accès à distance aux serveurs et aux environnements d’administration. Sa fonction Tailscale SSH remplace l’authentification SSH classique par l’identité de l’appareil et les règles d’accès définies dans le fichier de politique du tailnet. headscale est une implémentation open source et auto-hébergeable du serveur de contrôle.

Selon la chronologie publiée par Tailscale, des inquiétudes concernant Tailscale SSH ont circulé sur les réseaux sociaux le vendredi 23 octobre, et l’éditeur a commencé à enquêter. Il a reçu le rapport le samedi 24 octobre au matin ; la chercheuse l’a publié environ deux heures plus tard, avant toute correction. Cette divulgation non coordonnée a suscité des critiques, la chercheuse estimant qu’une sensibilisation rapide accélérerait la remédiation.

Les équipes de Tailscale ont travaillé sur les correctifs pendant le week-end. Le 26 octobre, l’éditeur a publié un premier point d’étape et ses bulletins de sécurité. La version 1.104.4 a été étiquetée le 27 octobre, et un article de synthèse a suivi le 28 octobre. La chercheuse salue d’ailleurs une réponse « rapide et substantielle » de l’éditeur.

Analyse technique

Une élévation vers root par le transfert de sockets

Les constats 1 à 3 du rapport forment le scénario le plus grave. Le transfert de sockets Unix demandé par un client SSH était exécuté par le processus tailscaled, qui tourne en root. La liste des chemins autorisés (répertoire personnel, /tmp, /run/user) était vérifiée de manière purement lexicale, si bien qu’une course de type TOCTOU par renommage permettait de la contourner.

D’après le rapport, un utilisateur SSH ordinaire pouvait ainsi :

• exécuter du code en root en atteignant le socket Docker appartenant à root ;
• remplacer le socket de contrôle de Tailscale et capturer une clé d’enrôlement (authkey) ;
• supprimer ou modifier les permissions de fichiers appartenant à root ;
• joindre en root le bus privé de systemd, et en tirer un shell root.

La chercheuse rappelle qu’OpenSSH abandonne ses privilèges avant de gérer le transfert, et que Dropbear a corrigé la même classe de défaut (CVE-2025-14282) dans sa version 2025.89. Tailscale résume le problème ainsi : une session authentifiée pouvait réaliser des opérations dépassant les privilèges de l’utilisateur local configuré, y compris via le transfert SSH.

Le « ver » : une propagation bornée par la politique d’accès

Le rapport décrit une chaîne complète : maintenir l’écoute sur le socket, intercepter le trafic de l’API locale, capturer une authkey, puis enrôler un nœud malveillant sous l’identité de la victime. Cette chaîne a été démontrée de bout en bout sur un tailnet où la fonction de verrouillage (Tailnet Lock) était désactivée. En laboratoire, la propagation automatique vers chaque serveur accessible selon la politique s’est faite en moins d’une seconde par rebond, sans identifiants utilisateur ni interaction.

Tailscale conteste le terme de ver autoréplicant : il s’agit, selon l’éditeur, d’un mouvement latéral limité aux connexions que la politique autorise. Les deux lectures convergent sur un point : l’étendue des dégâts dépend directement de la largeur des règles SSH. La chercheuse note que des autorisations par paire d’appareils ont stoppé la propagation, et que des identifiants d’appareil liés au matériel (TPM, Secure Enclave) empêchaient le vol d’identité.

Les autres constats

Qui est concerné ?

Sont exposées en priorité les organisations qui utilisent Tailscale SSH avec des règles autorisant le transfert local ou distant, en particulier lorsque ces règles sont larges (accès accordé à une identité ou à un tag entier, comptes cibles privilégiés). Les déploiements qui utilisent OpenSSH classique au-dessus de Tailscale ne sont pas concernés par la chaîne SSH. Les environnements auto-hébergés sous headscale 0.29.5 méritent une attention particulière : selon le rapport, le transfert ne peut pas y être désactivé par la politique.

Pourquoi c’est important

Les solutions d’accès de type « zero trust » concentrent l’autorisation sur l’identité de l’appareil. C’est une force, mais aussi un point de défaillance unique : un poste compromis par hameçonnage, une application web vulnérable ou un paquet logiciel malveillant suffit à hériter de toutes les autorisations de cet appareil. Si ces autorisations incluent un accès SSH à de nombreux serveurs, une élévation locale se transforme en compromission de flotte.

L’épisode rappelle aussi qu’un outil d’accès réseau est un composant critique de la chaîne d’administration, qui doit être inventorié, mis à jour et surveillé comme un VPN ou un bastion.

Lecture MITRE ATT&CK

Ni l’éditeur ni la chercheuse ne fournissent de correspondance ATT&CK. Le tableau ci-dessous est une lecture indicative de Defensy, établie à partir du scénario décrit en laboratoire.

Recommandations

1. ImmédiatMettre à jour vers Tailscale 1.104.4 ou ultérieure

   Priorisez les serveurs qui exposent Tailscale SSH, puis l’ensemble des nœuds. Vérifiez la version réellement déployée sur chaque appareil, y compris les conteneurs et images figées.

2. ImmédiatDésactiver le transfert SSH là où il n’est pas nécessaire

   Dans le fichier de politique, désactivez le transfert local et distant pour les règles qui n’en ont pas besoin. Sur un nœud non encore mis à jour, le bulletin TS-2026-014 indique de définir TS_SSH_DISABLE_FORWARDING=1 dans l’environnement du service tailscaled puis de redémarrer le service.

3. ImmédiatTraiter chaque autorisation SSH comme un accès root sous headscale

   Sur headscale 0.29.5, restreignez drastiquement les règles SSH, ou basculez temporairement vers OpenSSH classique au-dessus du tunnel jusqu’à correction.

4. Court termeResserrer la politique d’accès SSH

   Remplacez les règles accordées à une identité ou à un tag entier par des autorisations par paire source/destination, évitez les comptes cibles privilégiés et envisagez le mode « check » pour les systèmes sensibles, en gardant à l’esprit qu’il ne contrôle que l’établissement de la session, pas le transfert.

5. Court termeDurcir l’identité des nœuds

   Activez Tailnet Lock, l’expiration des clés de nœud sur les serveurs et, lorsque c’est possible, un stockage d’état lié au matériel. Faites tourner les authkeys accessibles depuis des hôtes potentiellement exposés.

6. Moyen termeSurveiller hors de l’hôte

   Centralisez dans votre SIEM les journaux du plan de contrôle (ajout de nœuds, changements de politique) et la télémétrie des serveurs (création de sockets, accès à docker.sock, shells inattendus). En cas de compromission, supprimez l’appareil côté plan de contrôle : une réinstallation ne révoque pas des clés copiées.