Tailscale 1.104.4 corrige le root via SSH

Ce qui se passe

Notre fiche du 26 octobre signalait des défauts de Tailscale SSH sans correctif disponible. Le correctif existe : Tailscale 1.104.4.

Il couvre quatre bulletins :

Bulletin	Objet
TS-2026-014	transfert de sockets SSH : une session autorisée atteignait des sockets réservés à root (socket Docker, API locale de `tailscaled`)
TS-2026-015	une session autorisée pouvait épuiser la mémoire du serveur et faire tomber le processus Tailscale, coupant tout le réseau Tailscale du nœud
TS-2026-016	dans `tailscale serve`, un transfert vers un socket Unix pouvait atteindre l'API locale de `tailscaled`, donnant le contrôle du nœud
TS-2026-017	avec TLS et au moins deux montages, une requête pouvait recevoir les en-têtes d'autorisation d'un autre montage

Le serveur Tailscale SSH ne tourne que sous Linux et dans la version open source pour macOS ; la machine de l'attaquant, elle, peut être de n'importe quelle plateforme.

Le mécanisme, et ce que le correctif change

Le transfert de connexions est réalisé par le processus Tailscale, qui tourne avec les privilèges de root. Quand une session SSH autorisée demandait un transfert vers un socket Unix, le processus vérifiait le chemin, puis agissait en root — contrôle et action séparés, donc garde-fou contournable.

Dans les essais d'Erica Windisch (Cyberdione Labs), viser le socket de contrôle de Docker donnait un accès root et la lecture de /etc/shadow, sans droits d'administrateur. Tailscale décrit une portée plus étroite : l'accès à des sockets réservés à root.

En 1.104.4, le transfert s'effectue avec les droits de l'utilisateur connecté, et ce sont les permissions du système de fichiers qui décident, à la place du contrôle de chemin précédent.

Les limites à connaître

Aucun identifiant de suivi. À la publication, les quatre bulletins n'ont ni CVE, ni score de gravité, et aucun n'indique la plus ancienne version touchée.
Le mode check ne protège pas. Il exige une nouvelle authentification avant le début d'une session ; le transfert, lui, se produit dans une session déjà approuvée.
headscale est plus exposé. Sur ce serveur de contrôle auto-hébergé, le transfert SSH est accordé à chaque session acceptée et ne peut pas être désactivé par la politique. Le rapport conclut que toute autorisation SSH y équivaut à un accès root. La dernière version, 0.29.5 du 13 octobre, ne corrige pas les problèmes signalés.
Une clé volée reste valide. Réinstaller la machine ne la révoque pas : il faut supprimer l'appareil côté plan de contrôle. Les avis de Tailscale ne traitent pas ce cas.

Ni Tailscale ni le rapport ne font état d'attaques réelles. Le code de démonstration n'est pas public ; il a été remis à l'équipe sécurité de Tailscale.

Comment s'y prendre

Passer les serveurs Tailscale SSH en 1.104.4 ou plus récent.
Sur un serveur qui ne peut pas être mis à jour tout de suite, poser TS_SSH_DISABLE_FORWARDING=1 dans l'environnement du service tailscaled et redémarrer : le transfert est coupé sans désactiver Tailscale SSH.
Revoir les règles d'accès SSH pour n'autoriser que les utilisateurs et appareils qui en ont besoin. Dans les essais, deux mesures ont contenu la propagation : des règles écrites en paires d'appareils et des clés liées au matériel (TPM).
En cas de doute sur une machine, la supprimer du plan de contrôle.

Sur le mot « ver »

Windisch qualifie la chaîne de « wormable » : dans ses tests, un appareil compromis atteignait tous ceux que la politique autorisait, en moins d'une seconde par étape. Tailscale rejette le terme — déplacement latéral borné par la politique, pas logiciel auto-répliquant — tout en parlant de « problèmes de sécurité sérieux ». Le rapport a été publié sans coordination, reçu environ deux heures avant sa parution. C'est le deuxième correctif de l'année dans cette partie du code, après un défaut voisin corrigé en juin en 1.98.9 (TS-2026-004).

Source : The Hacker News, 28 octobre 2026. Source en anglais, citant les bulletins de sécurité Tailscale et le rapport Tailworm d'Erica Windisch.