Le SSH de Tailscale transforme une machine compromise en accès root sur tout le maillage
Le 25 octobre 2026, la chercheuse Erica Windisch publie « Tailworm », un rapport qui montre que le SSH de Tailscale, combiné au transfert de port, donne un accès root sur chaque serveur joignable dès qu’un seul appareil du maillage est compromis. Sans correctif ni CVE à ce jour, la parade immédiate tient en trois réglages : règles d’accès par paires, transfert de port désactivé et Tailnet Lock.
25 octobre 2026. La chercheuse Erica Windisch, du laboratoire Cyberdione Labs, publie « Tailworm », un rapport de onze constats sur la pile réseau de Tailscale. 25 octobre 2026, même jour. Tailscale n’a publié ni bulletin de sécurité, ni CVE, ni version corrigée. 25 octobre 2026, encore. Le VP ingénierie Mike Shaver répond sur Reddit que l’entreprise examine déjà les mêmes zones et travaille à corriger des problèmes. Le point clé : le SSH de Tailscale, combiné au transfert de port, permet à un attaquant qui tient déjà une seule machine du maillage d’obtenir un accès root sur tous les serveurs que les règles d’accès l’autorisent à joindre — sans mot de passe volé et sans clé dérobée.
Pour un RSSI qui a remplacé ses VPN par un maillage Tailscale au nom du zero trust, le rapport n’est pas une condamnation de l’outil. C’est une leçon sur ce qui arrive quand un produit déplace la sécurité du réseau vers la politique d’accès, puis laisse un chemin privilégié traverser cette politique.
Comment le SSH de Tailscale diffère d’un SSH classique
Le SSH de Tailscale ne fonctionne pas comme un serveur SSH ordinaire. Au lieu de vérifier le mot de passe ou la clé d’un utilisateur, il identifie l’appareil qui se connecte, puis une règle d’accès unique décide si cet appareil peut ouvrir une session SSH vers une cible donnée. C’est précisément cette inversion — authentifier la machine plutôt que l’humain — qui ouvre la brèche : une fois qu’un attaquant tient un appareil autorisé, il n’a plus rien à voler pour avancer.
Windisch a testé Tailscale 1.104.2 et headscale 0.29.5 — le serveur de contrôle auto-hébergé que certains réseaux utilisent à la place du service hébergé — pendant trois jours en laboratoire. Le rapport décrit des tests sur logiciel, pas des attaques menées contre de vrais réseaux.
Trois méthodes d’escalade ressortent des essais. La première passe par un simple transfert de port SSH : une session ordinaire amène le processus Tailscale exécuté en root à se connecter à un socket système réservé au super-utilisateur, et le test obtient root puis lit le fichier des mots de passe « presque immédiatement ». La deuxième remplace un socket appartenant à root par celui de l’attaquant, ce qui permet l’exécution directe de commandes root contre certains services. La troisième contourne un contrôle censé limiter les fichiers accessibles par transfert en exploitant une course entre le moment où le système vérifie un chemin et celui où il l’utilise — un time-of-check/time-of-use classique.
Un rapport « wormable » : ce qu’il dit, et ce qu’il ne dit pas
La chaîne la plus grave décrite par Windisch va plus loin : elle capture une clé servant à inscrire de nouveaux appareils et l’utilise pour joindre une machine de l’attaquant au réseau en tant que serveur de confiance. Cette dernière étape ne fonctionne de bout en bout que sur les réseaux où Tailnet Lock n’est pas activé ; là où il l’est, les secrets nécessaires ont bien été capturés en transit, mais l’étape finale n’a pas abouti.
Le rapport qualifie le résultat global de « wormable » : en laboratoire, un appareil compromis pouvait se propager à chaque appareil autorisé, sans mot de passe, sans clé volée et sans action de l’utilisateur, en moins d’une seconde par étape. « Le maillage convertit un point d’appui ordinaire en accès privilégié à l’échelle de la flotte, à la vitesse de la machine », écrit Windisch.
Deux éléments ont freiné la propagation dans les tests : les règles d’accès écrites comme des paires source-destination uniques, qui l’ont stoppée d’elles-mêmes, et les clés d’appareil liées au matériel, comme un TPM ou une Secure Enclave.
Ce constat mérite d’être lu avec prudence. Le SSH n’est que l’un des onze constats du rapport, qui couvre aussi les app connectors, la fonction serve, le relais DERP et headscale. L’un d’eux, niché dans la fonction expérimentale conn25 des app connectors, permet à un utilisateur autorisé d’envoyer du trafic vers des destinations que l’équipe sécurité n’a jamais approuvées — y compris le service de métadonnées d’un fournisseur cloud, qui peut distribuer les credentials du serveur. Windisch juge même ce constat « potentiellement plus impactant pour certaines organisations » que l’escalade SSH. Aucun autre chercheur n’a reproduit publiquement les résultats, Tailscale n’a pas confirmé les affirmations techniques précises, et le code de preuve de concept n’est pas public : il a été remis au contact sécurité de l’entreprise. Plusieurs chercheurs ayant lu le rapport contestent le qualificatif « wormable », tandis que d’autres jugent le constat d’accès root sérieux.
La divulgation qui divise
La publication de Windisch a elle-même suscité une controverse de méthode. La chercheuse a décrit sa divulgation comme « reported but not coordinated » — signalée mais non coordonnée — sur Hacker News, et au moins un commentateur y a jugé irresponsable de publier sans avoir prévenu Tailscale au préalable.
Interrogée par The Hacker News, Windisch affirme avoir bel et bien remis à Tailscale une copie du rapport et du code de preuve de concept avant la publication, en les envoyant au contact sécurité de l’entreprise le samedi précédent. Elle dit aussi avoir évoqué ses inquiétudes sur l’architecture avec le CEO de l’entreprise plus tôt, et avoir publié un hash de fichier tout en conseillant de désactiver le SSH de Tailscale.
Du côté de Tailscale, Mike Shaver a reconnu sur Reddit avoir reçu le rapport, que l’entreprise examinait déjà les mêmes zones avec des spécialistes externes, et qu’elle avait trouvé des problèmes en cours de correction. Il précise que l’entreprise cherche encore à déterminer quelles configurations sont touchées et qu’elle « ne recommande pas à tout le monde de désactiver le SSH de Tailscale ».
Cet épisode s’inscrit dans une série. Plus tôt en 2026, Tailscale avait déjà corrigé plusieurs failles dans le même périmètre — le SSH et la gestion des sockets serveur — dont une où le transfert de socket Unix pouvait atteindre un socket privilégié, dans la version 1.98.9.
Ce qu’il faut faire maintenant
En l’absence de correctif, les parades disponibles sont des changements de configuration, et le rapport comme les conseils de Tailscale se rejoignent sur l’essentiel.
- Règles d’accès par paires. Réécrivez vos règles SSH en paires source-destination uniques — un appareil nommé vers une cible nommée — et supprimez les règles larges qui accordent l’accès par identité ou par tag.
- Transfert de port désactivé. Sur le service hébergé, coupez le transfert là où c’est possible par règle. Sur headscale 0.29.5, il ne peut pas être désactivé du tout : chaque octroi SSH doit alors être traité comme un octroi de root sur la cible.
- Tailnet Lock activé. Activez la fonction pour casser la dernière étape de la chaîne — l’inscription d’une machine attaquante comme serveur de confiance.
Ces trois réglages ne ferment pas la faille ; ils la rendent inexploitable de bout en bout tant qu’aucun correctif n’est publié.
Verdict
Le rapport n’efface pas la valeur de Tailscale : il précise la condition de sa sécurité. Si vous exploitez le SSH de Tailscale sur le service hébergé, durcissez immédiatement — paires source-destination, transfert de port désactivé, Tailnet Lock activé — et réduisez l’octroi SSH au strict minimum d’appareils qui en ont réellement besoin. Si vous auto-hébergez headscale, votre marge de manœuvre est plus mince : tant que le transfert de port reste non désactivable et qu’aucun correctif n’est publié, traitez chaque règle SSH comme un accès root, et surveillez le bulletin de sécurité que Tailscale finira par émettre. La leçon vaut pour tout maillage zero trust : la sécurité repose sur la politique d’accès, et une politique qui laisse un chemin privilégié traverser le contrôle n’est plus une politique — c’est un détail d’implémentation.