Un utilisateur autorisé du VPN Tailscale pouvait prendre la main sur vos serveurs
Le réseau privé Tailscale a publié la version 1.104.4, qui corrige des failles de sa fonction SSH révélées par un audit. Qui est concerné, et le réglage qui protège si la mise à jour doit attendre.

Onze failles, un audit et un surnom : « Tailworm ». Le samedi 24 octobre au matin, Tailscale reçoit les résultats de l'examen qu'Erica Windisch, fondatrice du cabinet Cyberdione Labs, a mené sur la version 1.104.2 du logiciel et sur headscale 0.29.5. headscale est un serveur de contrôle libre que certaines organisations hébergent elles-mêmes à la place du service commercial. La chercheuse rend les détails publics deux heures plus tard. « Toutes les découvertes ont été vérifiées en laboratoire, sur des logiciels publiés et non modifiés », écrit-elle.
Tailscale est un réseau privé virtuel (VPN) très utilisé par les équipes techniques pour relier ordinateurs et serveurs. Sa fonction « Tailscale SSH » permet de se connecter à distance aux machines du réseau en s'appuyant sur les règles d'accès de Tailscale. C'est elle qui concentre les problèmes les plus graves. L'éditeur a publié quatre bulletins de sécurité, datés du 26 octobre, et une version corrigée, la 1.104.4. Aucune exploitation par des pirates n'a été signalée.
Comment une session ordinaire pouvait agir en administrateur
Le cœur du problème tient au transfert de « sockets Unix », ces points de connexion locaux qu'utilisent de nombreux services. Quand un utilisateur demandait ce transfert par SSH, le service de Tailscale, qui tourne avec les droits maximaux (root), se contentait de vérifier le nom des chemins, puis agissait en root. Selon Cyberdione Labs, une session ordinaire pouvait ainsi remplacer, joindre ou supprimer des ressources privilégiées, jusqu'à exécuter du code en root sur le serveur. Le bulletin TS-2026-014 de Tailscale cite le socket de Docker et l'interface locale de Tailscale parmi les cibles possibles.
Il fallait toutefois réunir des conditions : disposer d'un appareil approuvé sur le réseau et d'une règle d'accès SSH autorisant le transfert. Sur headscale, ce transfert est accordé d'office. Sur le service commercial, il dépend de chaque règle. Tailscale juge ces failles « sérieuses » et précise que leur exploitation dépend des droits accordés à l'utilisateur ou à l'appareil, et de la configuration du système.
D'autres failles, jusque dans le serveur de contrôle
L'audit touche d'autres briques. La commande tailscale serve, qui publie un service sur le réseau, pouvait elle aussi atteindre des sockets privilégiés (TS-2026-016). Une session SSH autorisée pouvait épuiser la mémoire de la machine, jusqu'à faire tomber Tailscale (TS-2026-015). Côté headscale, Cyberdione décrit une saturation possible sans aucun compte, qui bloquerait l'ajout de nouveaux appareils dans toute l'organisation. Enfin, la fonction expérimentale de connecteurs d'applications permettait à un utilisateur autorisé pour une application de joindre d'autres destinations internes, jamais comparées à celles prévues pour cette application. Selon Cyberdione, la version 1.104.4 ne le corrige pas. Tailscale précise que cette fonction n'est pas encore publiée et que les connecteurs d'applications actuels ne sont pas concernés.
Que faire ?
La correction tient en une mise à jour, à condition qu'elle atteigne chaque machine qui accepte des connexions Tailscale SSH.
- Installez Tailscale 1.104.4 ou plus récent, en commençant par les serveurs où Tailscale SSH est activé.
- Si la mise à jour doit attendre, ajoutez
TS_SSH_DISABLE_FORWARDING=1dans l'environnement du service tailscaled, puis redémarrez-le. Le transfert est coupé sans désactiver Tailscale SSH, ce qui atténue plusieurs des failles les plus graves. - Réservez l'accès SSH aux seuls utilisateurs et appareils qui en ont besoin.
- Si vous hébergez headscale, surveillez la publication d'un correctif par ce projet libre et limitez son exposition sur Internet.
Tailscale ne recommande pas de couper Tailscale SSH partout, a précisé Mike Shaver, son vice-président chargé de l'ingénierie, cité par BleepingComputer. Le 27 octobre, l'éditeur disait vérifier encore toute l'étendue des découvertes. Ses quatre bulletins décrivent désormais, pour chaque faille, les configurations concernées.
Méthode : veille assistée par intelligence artificielle, faits vérifiés par un second modèle d’IA, article publié automatiquement puis relu et validé par Frédéric LENQUETTE le 12 novembre 2026. Notre charte éditoriale.
Partager cet article