Onze problèmes de sécurité découverts en trois jours, dont plusieurs élévations de privilèges confirmées par l’éditeur. En laboratoire, la fonction Tailscale SSH a pu servir de vecteur à une attaque capable de se propager seule, de serveur en serveur. Aucune exploitation réelle n’a été signalée, mais les administrateurs disposent dès maintenant de leviers concrets pour réduire leur exposition.

Onze problèmes en trois jours de tests

Le réseau maillé « zero trust » de Tailscale s’est imposé dans de nombreuses équipes d’infrastructure comme une alternative légère au VPN traditionnel, notamment pour l’administration à distance. C’est précisément cette brique d’administration qui est aujourd’hui en cause. La chercheuse Erica Windisch, de Cyberdione Labs, a recensé onze problèmes de sécurité dans Tailscale et dans headscale, l’implémentation open source qui permet d’héberger soi-même le serveur de coordination du réseau. Ses tests, menés sur Tailscale 1.104.2 et headscale 0.29.5, n’ont duré que trois jours.

Sa démonstration est simple à résumer et inquiétante à lire : à partir d’une machine déjà compromise, il est possible d’obtenir des droits administrateur sur d’autres machines du réseau, sans disposer de leurs identifiants. Tailscale a confirmé plusieurs failles d’élévation de privilèges et reconnu leur gravité.

Quand tailscaled agit en root à la place de l’utilisateur

Les failles les plus sérieuses concernent Tailscale SSH, la fonction d’administration à distance intégrée à l’outil. Point important pour évaluer son exposition, cette fonction est désactivée par défaut, et les connexions SSH classiques qui se contentent de traverser le réseau privé ne sont pas visées.

Le problème apparaît lorsque la redirection (forwarding) SSH est autorisée. Les accès sont régis par des règles définies à l’avance, mais dans cette configuration, le processus tailscaled exécute certaines opérations avec les privilèges root, même lorsque le compte connecté ne dispose pas de ces droits. Un attaquant qui contrôle un appareil déjà autorisé peut alors atteindre des ressources réservées aux administrateurs et, dans certains cas, exécuter des commandes avec les privilèges les plus élevés du système.

Une propagation « wormable »… et ce qui l’a arrêtée

Le scénario devient franchement préoccupant lorsqu’on l’enchaîne, les failles peuvent être exploitées de serveur en serveur, tant que les règles d’accès le permettent. En laboratoire, la chercheuse a automatisé ce mouvement latéral, avec moins d’une seconde par étape. Le terme employé est « wormable » : une attaque capable de se propager sans nouvelle intervention des victimes.

Le même test met également en évidence une mesure de protection essentielle. En limitant les connexions à des paires d’appareils autorisées, les règles d’accès ont empêché la propagation de l’attaque. La précision des ACL constitue donc un véritable rempart contre les compromissions en cascade à l’échelle du tailnet.

Tailnet Lock : la protection qu’on oublie d’activer

Un autre résultat mérite l’attention. Lorsque Tailnet Lock était désactivé, la chercheuse a pu intercepter une clé d’enregistrement et l’utiliser pour inscrire une machine malveillante sur le réseau. Cette fonction, qui fait valider l’ajout de nouveaux nœuds par des appareils de confiance, n’a rien d’accessoire dans un réseau où l’enrôlement d’une machine ouvre potentiellement la porte à toutes les autres.

Ce qu’il faut faire dès maintenant

En attendant les correctifs, plusieurs mesures à prendre :

• Inventorier l’usage de Tailscale SSH : la fonction étant désactivée par défaut, la première question est de savoir où elle a été activée.
• Restreindre les autorisations SSH aux seuls appareils qui en ont réellement besoin, idéalement par paires d’appareils, la configuration qui a bloqué la propagation lors des tests.
• Couper la redirection SSH lorsqu’elle n’est pas indispensable. Pour garder Tailscale SSH tout en bloquant les redirections, ajouter la variable TS_SSH_DISABLE_FORWARDING=1 à l’environnement du service tailscaled, puis redémarrer ce service. Selon l’éditeur, cette option fonctionne aussi avec headscale, dont la version testée ne permet pas de désactiver la redirection règle par règle.
• Activer Tailnet Lock pour empêcher l’inscription d’une machine à partir d’une clé interceptée.
• Installer les correctifs dès leur publication.

Correctifs : où en est-on ?

Le lendemain des révélations, Tailscale indiquait avoir développé des correctifs pour la majorité des problèmes, dont certains déjà intégrés au code source. L’éditeur finalisait ses tests avant de publier une version corrigée, annoncée pour la fin de la journée, et promettait un bulletin de sécurité précisant les versions concernées et les configurations exposées.

À l’heure où nous écrivons, la page publique des bulletins de sécurité de Tailscale ne mentionne pas encore ces failles SSH. Ses deux bulletins d’octobre 2026 portent sur d’autres sujets : la compromission de certificats intermédiaires TLS d’eMudhra (TS-2026-013, corrigé à partir de la version 1.104.2) et un bogue de descripteurs de fichiers dans libtailscale (TS-2026-012). Les équipes ont donc intérêt à surveiller cette page de près, et à ne pas considérer la version 1.104.2, celle testée par la chercheuse, comme un refuge.

Le zero trust se configure, il ne se décrète pas

Cette affaire rappelle une réalité que les équipes réseau connaissent bien : un outil « zero trust » n’apporte ses garanties que si sa configuration les applique. Ici, ce n’est pas le chiffrement du maillage qui est en cause, mais la manière dont une fonction d’administration hérite de privilèges qu’elle ne devrait pas avoir. Les mesures les plus efficaces (ACL par paires, redirection coupée, Tailnet Lock activé) ne demandent pas d’attendre l’éditeur. Elles relèvent de l’hygiène d’administration, et le test de laboratoire a montré qu’elles suffisaient à casser la chaîne de propagation.