Failles Tailscale Tailworm - un appareil compromis peut ouvrir l’accès root à d’autres serveurs

D’après le rapport Tailworm, les failles Tailscale peuvent transformer un appareil déjà compromis en point de départ vers les privilèges root sur d’autres serveurs autorisés. Le sujet concerne notamment Tailscale SSH, le serveur SSH intégré à l’agent, et sa gestion des redirections.

Publié le 25 octobre, le rapport d’Erica Windisch, de Cyberdione Labs, s’appuie sur des essais menés avec Tailscale 1.104.2 et Headscale 0.29.5. Tailscale a répondu publiquement et travaille sur des correctifs. Rapport Tailworm et réponse de Mike Shaver, VP Engineering de Tailscale.

Pour une infrastructure de production, la question est immédiate : jusqu’où peut aller une machine qui perd sa fiabilité ? Un tunnel privé protège les échanges ; les autorisations et les privilèges doivent aussi limiter les conséquences d’une compromission.

Tailworm : du droit de connexion à l’accès root

Tailscale relie des appareils dans un réseau privé reposant sur WireGuard. Sa fonction Tailscale SSH ajoute un serveur intégré dont les autorisations sont pilotées par les politiques d’accès du réseau. Elle se distingue d’un serveur OpenSSH simplement joint à travers le tunnel. Documentation Tailscale SSH.

Dans les essais rapportés, certaines redirections SSH vers des sockets Unix, des points de communication entre processus locaux, utilisent les privilèges root de l’agent plutôt que ceux de l’utilisateur connecté. Elles permettraient d’atteindre des services locaux réservés à l’administration. Constats techniques de Tailworm.

Mike Shaver confirme que l’équipe a identifié des problèmes dans la gestion des privilèges Unix et du forwarding : certaines sessions peuvent effectuer davantage d’actions que leur utilisateur local ne devrait pouvoir en réaliser. Le périmètre exact reste en cours de validation. Communication de Tailscale.

Le scénario SSH nécessite déjà un appareil compromis et une autorisation de connexion vers la cible. Les démonstrations sont réalisées en laboratoire : elles ne constituent pas la preuve d’une campagne d’attaques en cours. Le rapport présente onze constats de nature différente, pas onze CVE critiques officiellement confirmées. Rapport de recherche.

Headscale et les services exposés demandent aussi une revue

Headscale est un serveur de coordination auto-hébergé pour les clients Tailscale. Le rapport relève aussi des risques de destinations réseau insuffisamment restreintes avec les connecteurs expérimentaux, d’exposition de l’API locale via Serve et d’épuisement de mémoire. Périmètre audité.

Pour l’exploitant, l’inventaire doit donc distinguer le tunnel, le serveur SSH intégré, les connecteurs et les services publiés. Cela permet de traiter les fonctions réellement utilisées, plutôt que de raisonner sur le seul nom du VPN.

Ce que Tailscale recommande en attendant les correctifs

Au 26 octobre 2026, les pages officielles consultées affichent toujours Tailscale 1.104.2 et aucun bulletin dédié à Tailworm. Cette version précède le rapport ; son numéro ne permet pas de conclure que ces problèmes sont corrigés. Changelog et bulletins de sécurité Tailscale.

L’éditeur ne recommande pas une désactivation générale de Tailscale SSH. Il demande de revoir les autorisations et de désactiver le forwarding lorsqu’il n’est pas nécessaire. Son instruction consiste à définir TS_SSH_DISABLE_FORWARDING=1 dans l’environnement du service tailscaled, puis à redémarrer celui-ci. Préparez un autre accès d’administration avant cette intervention. Recommandations de Tailscale.

Le mode SSH « check » ajoute une étape d’authentification, mais ne corrige pas le défaut de privilèges. Il complète la réduction des accès, sans la remplacer. Le suivi des prochaines publications reste nécessaire pour déployer les correctifs dès leur disponibilité.

Attention à ne pas confondre les mises à jour : Headscale 0.29.6, publié le 24 octobre, documente des changements de certificats, de dépendances et de fonctionnement, sans annoncer de correction Tailworm. Notes officielles Headscale 0.29.6.

Un accès au réseau ne doit pas ouvrir toute l’administration

Une machine applicative, un poste d’administration, un hyperviseur et un serveur de sauvegarde n’ont pas besoin des mêmes droits. Leur présence dans un réseau privé ne justifie pas des accès identiques.

La revue doit répondre à des questions simples : qui peut joindre chaque serveur, avec quel compte, pour quelle opération et pendant combien de temps ? Les fonctions de redirection, les comptes privilégiés et les services d’administration accessibles méritent une vérification distincte.

Cette démarche rejoint nos principes de segmentation et de maîtrise des accès réseau. Elle doit aussi préserver la capacité d’intervention : réduire les droits sans conserver un chemin de secours peut transformer une opération de sécurité en perte d’accès. Nous détaillons cette préparation dans notre article sur la maintenance des accès distants Linux.

Le bon objectif est de contenir l’incident au plus près de son point de départ. Dans notre infogérance de serveurs Linux, la connaissance des dépendances, la maîtrise des accès et la préparation des maintenances servent précisément à éviter qu’un problème local ne s’étende au reste de la production.

Questions sur Tailworm et Tailscale SSH

Le SSH classique utilisé à travers Tailscale est-il concerné ?

Le problème de privilèges décrit ici vise le serveur intégré Tailscale SSH. Mike Shaver, VP Engineering de Tailscale, le distingue d’un serveur OpenSSH classique accessible à travers le tunnel.

Faut-il désactiver Tailscale SSH sur tous les serveurs ?

Au 26 octobre 2026, Tailscale ne recommande pas une désactivation générale. L’éditeur préconise de restreindre les accès et de désactiver le forwarding SSH lorsqu’il n’est pas nécessaire, en attendant les correctifs.