Tailworm met Tailscale SSH sous surveillance : que faire en l’absence de correctif

J. Actualclo

X (Twitter) Facebook Pinterest LinkedIn Email

Les équipes qui utilisent Tailscale pour donner un accès SSH à leurs serveurs ont du travail cette semaine : le rapport Tailworm, publié le 25 octobre 2026 par Erica Windisch, de Cyberdione Labs, décrit 11 failles dans Tailscale et headscale qui, en laboratoire, ont permis de passer d’une machine compromise à root sur d’autres nœuds du réseau, sans mots de passe ni clés volées. Tailscale a reconnu qu’il corrigeait des problèmes dans ces domaines, mais il n’existe pas encore de bulletin, de CVE ni de version corrigée.

Les points clés de Tailworm pour les équipes qui utilisent Tailscale SSH en 20 secondes

Tailworm recense 11 failles prouvées dans Tailscale 1.104.2 et headscale 0.29.5.
Le risque principal est la redirection de sockets dans Tailscale SSH, gérée par un processus qui tourne en root.
Il n’y a ni correctif ni CVE ; Tailscale déconseille de désactiver SSH de façon générale.
Les règles par paires et les clés liées au matériel ont freiné l’attaque.

Tailscale s’est répandu comme alternative aux VPN classiques et aux bastions SSH parce qu’il connecte des machines via WireGuard avec des politiques d’accès centralisées, et de nombreuses équipes l’utilisent aussi pour accéder à des serveurs de production avec Tailscale SSH. C’est cette commodité qu’examine le rapport. Les résultats proviennent de tests en laboratoire d’une seule chercheuse et personne ne les a encore reproduits de manière indépendante ; il convient donc de les traiter comme des alertes sérieuses, non comme des incidents confirmés.

Où se situe le problème

Le cœur du rapport est architectural. Le serveur SSH de Tailscale vit à l’intérieur de tailscaled, le démon du client, qui dispose de privilèges root. Lorsqu’une règle autorise la redirection de ports ou de sockets Unix, c’est ce processus privilégié qui ouvre ou remplace les sockets, y compris ceux que seul root devrait toucher, comme celui de Docker. Lors des tests, un utilisateur avec une session SSH normale est parvenu à root et a lu /etc/shadow, et une autre variante de la faille a exécuté du code en tant que root via un démon local.

Les autres constats élargissent la portée à d’autres fonctions : les connecteurs d’applications expérimentaux, qui, selon le rapport, laissaient sortir vers les services de métadonnées du cloud ou de Kubernetes ; tailscale serve et Funnel lorsqu’ils pointent vers des sockets Unix ; le client des relais DERP ; et le serveur headscale, qui reçoit lui aussi un avertissement d’épuisement de ressources. Aucun n’est exploitable depuis internet sans autre condition : l’attaquant doit déjà contrôler un appareil du réseau, ce qui peut arriver par une application vulnérable, une dépendance empoisonnée ou un portable infecté.

Ce qui préoccupe les administrateurs, c’est la vitesse de propagation décrite. Chaque nœud connaît la liste complète de ses pairs, si bien que, dès la première machine, l’attaquant voit toutes les destinations possibles, et la chaîne du laboratoire a progressé en moins d’une seconde par saut. Avec Tailnet Lock activé, la dernière étape, qui consistait à inscrire un faux serveur dans le réseau, a échoué, selon The Hacker News.

La réponse de Tailscale et le débat sur la divulgation

Windisch affirme avoir envoyé le rapport et la preuve de concept au contact sécurité de Tailscale le samedi précédant la publication, sans attendre un processus coordonné, et cette décision a été critiquée sur des forums comme Hacker News. Certains chercheurs contestent aussi que l’attaque puisse être qualifiée de ver, tout en s’accordant sur la gravité de l’élévation à root.

Mike Shaver, vice-président ingénierie de Tailscale, a répondu sur Reddit que l’entreprise examinait déjà ces domaines avec des spécialistes externes et qu’elle travaillait sur des correctifs, tout en déterminant encore quelles configurations sont exposées. Sa recommandation est de réviser les politiques SSH, de limiter qui peut rediriger des ports, d’activer le mode check et de conserver les mises à jour automatiques, et non de désactiver Tailscale SSH partout. OpenSecurity détaille les 11 failles et les bulletins antérieurs de Tailscale dans Tailworm : 11 fallos sin parche en Tailscale podrían dar root en otros servidores (en espagnol).

Liste de contrôle pour les équipes systèmes

En attendant le correctif, le rapport propose des mesures que toute équipe peut passer en revue en une après-midi :

Auditer les règles SSH de la politique et remplacer les règles larges, par groupe ou par tag, par des autorisations d’une source vers une destination.
Refuser la redirection de ports dans chaque règle. Dans headscale 0.29.5, cette option n’existe pas, donc chaque permission SSH doit être traitée comme un accès root.
Désactiver Tailscale SSH sur les machines qui n’en ont pas besoin avec tailscale set --ssh=false, mais seulement après avoir vérifié qu’il reste un autre moyen d’y entrer.
Supprimer les permissions de connecteurs d’applications inutilisés et les redirections de serve vers des sockets Unix.
Activer l’expiration des clés de nœud et, face à une machine compromise, la supprimer du plan de contrôle : la réinstaller n’invalide pas les clés déjà copiées.

Ce cas rappelle qu’un réseau Zero Trust dépend autant de ses politiques que de son logiciel. La protection qui a le mieux fonctionné en laboratoire n’a pas été un correctif, mais une règle d’accès étroite. Pour qui préfère monter son propre réseau privé sans services tiers, Revista Cloud a expliqué comment transformer un Linux en VPN avec WireGuard, bien que cette option oblige à gérer à la main ce que Tailscale automatise.