Tailscale 1.104.4 corrige les failles de privilèges SSH révélées par Tailworm

Tailscale a corrigé une série de failles dans Tailscale SSH et dans sa fonction Serve avec la version 1.104.4. Ces correctifs font suite au rapport « Tailworm ». Il a montré qu'un seul appareil compromis pouvait obtenir un accès root sur d'autres machines qu'il était autorisé à joindre. Tailscale a publié quatre bulletins de sécurité, de TS-2026-014 à TS-2026-017, et en a détaillé le contenu dans un billet de blog daté du 28 octobre 2026. Toute personne qui utilise Tailscale SSH avec la redirection de ports devrait mettre à jour.

Tailscale est un service VPN qui relie les appareils d'une entreprise en un seul réseau privé, appelé tailnet. Tailscale SSH lui permet de gérer les connexions à ces machines à la place des clés SSH habituelles.

Ce que corrigent les quatre bulletins

Bulletin	Ce qui n'allait pas	Qui est concerné
TS-2026-014	La redirection de sockets Unix via SSH s'exécutait en root et pouvait donc atteindre des sockets réservés à root	Tailscale SSH lorsque la politique autorise la redirection locale ou distante
TS-2026-015	La mémoire augmentait sans limite dans les sessions SSH, ce qui pouvait faire planter tailscaled	Les nœuds Tailscale SSH, depuis une session connectée et autorisée
TS-2026-016	Les backends Serve sur des sockets Unix pouvaient atteindre des sockets privilégiés, dont l'API locale de tailscaled	Les configurations qui dirigent Serve vers un socket Unix
TS-2026-017	Une situation de concurrence dans Serve en HTTP/2 faisait fuiter des en-têtes App Capabilities entre points de montage	Serve avec TLS et au moins deux points de montage aux exigences différentes

Les quatre sont corrigés dans la version 1.104.4 ou ultérieure, selon l'index des bulletins de Tailscale. Tailscale n'a attribué de niveau de gravité à aucun d'entre eux.

Un socket Unix est un canal local que les programmes d'une même machine utilisent pour communiquer entre eux. Certains, comme le socket Docker, donnent à quiconque les atteint le contrôle total de la machine.

Comment fonctionne l'attaque

La chercheuse à l'origine du rapport est Erica Windisch, de Cyberdione Labs, rapporte The Hacker News. Elle a testé Tailscale 1.104.2 et headscale 0.29.5, le serveur de contrôle open source, et a recensé 11 constats.

Dans son laboratoire, trois méthodes ont transformé une session SSH ordinaire en accès root. L'une envoyait une connexion redirigée, via un processus root, vers un socket réservé à root. Une autre substituait un socket appartenant à root. Une troisième exploitait une situation de course face à une vérification de sécurité des chemins de fichiers. Cette dernière chaîne a capturé une clé d'enrôlement et a fait entrer la machine d'un attaquant dans le réseau en tant que serveur de confiance. Elle ne fonctionnait que sur les réseaux sans Tailnet Lock, une fonction qui oblige les appareils de confiance à approuver les nouveaux.

Tailscale insiste sur les limites. L'exploitation des bugs nécessite « un point d'appui existant sur un pair autorisé du tailnet », avec SSH autorisé par la politique. L'entreprise affirme que les failles ne permettent pas à une personne extérieure de se connecter à n'importe quel serveur Tailscale SSH. Elle qualifie le risque de mouvement latéral limité par la politique, et non de ver capable de se propager tout seul.

Une divulgation contestée

Tout est allé vite. Selon Tailscale, des inquiétudes ont commencé à circuler sur les réseaux sociaux le vendredi 23 octobre, et l'entreprise a ouvert une enquête. Elle a reçu le rapport le matin du samedi 24 octobre, et la chercheuse l'a publié environ deux heures plus tard.

Windisch a déclaré à The Hacker News que le rapport avait été « signalé mais pas coordonné ». Elle a indiqué avoir d'abord envoyé le rapport et une preuve de concept à Tailscale. Certains chercheurs ont critiqué une publication sans correctif coordonné, selon The Hacker News et Brandefense.

Tailscale a aussi examiné un rapport distinct sur Serve et Funnel comportant cinq constats. L'entreprise en a corrigé trois en tant que bugs et a jugé que deux relevaient du fonctionnement prévu. Un connecteur d'applications non publié, Conn25, présente une faille. « Les connecteurs d'applications stables disponibles aujourd'hui ne sont pas concernés », indique Tailscale.

Ce que cela signifie pour les développeurs

Les équipes qui utilisent Tailscale SSH devraient appliquer cette mise à jour sans attendre. L'usage réseau classique, sans ces fonctions, n'est pas cité comme concerné.

• Mettez à jour les clients vers la version 1.104.4 ou ultérieure. Les correctifs se trouvent dans le client, donc chaque nœud qui accepte Tailscale SSH a besoin de la nouvelle version.
• Désactivez la redirection si vous ne pouvez pas encore appliquer le correctif. Définissez TS_SSH_DISABLE_FORWARDING=1 dans l'environnement du service tailscaled, puis redémarrez-le. Tailscale SSH continue de fonctionner sans redirection.
• Resserrez les règles SSH. Remplacez les règles larges par des autorisations individuelles d'une source vers une destination, et n'autorisez jamais de comptes cibles privilégiés, comme le conseillent The Hacker News et Brandefense.
• Auditez les configurations Serve. Supprimez toute redirection tailscale serve qui pointe vers un socket Unix dont vous n'avez pas besoin, surtout s'il est privilégié.
• Auto-hébergeurs, vérifiez headscale. Les deux médias rapportent que headscale 0.29.5 ne permet pas de désactiver la redirection, si bien que chaque autorisation SSH y équivaut de fait à root. La version 1.104.4 du client ne modifie pas le serveur.
• Activez Tailnet Lock. Selon The Hacker News, il a bloqué la dernière étape de la chaîne de la clé d'enrôlement en laboratoire.

Les conseils de Tailscale restent mesurés. « D'après notre évaluation actuelle, nous ne recommandons pas à tout le monde de désactiver Tailscale SSH », indiquait sa mise à jour du 26 octobre. Appliquer le correctif, puis limiter qui peut rediriger quoi, reste dans tous les cas la voie la plus sûre.