Tailscale a publié une série de constats de sécurité touchant Tailscale SSH, ainsi que Serve et Funnel, deux fonctionnalités qui s’appuient sur le même mécanisme. Les correctifs sont déjà disponibles, dans la version 1.104.4. Si Tailscale tourne sur votre homelab ou votre tailnet auto-hébergé, voici ce qui s’est passé, ce que ça change réellement pour votre installation, et surtout ce que ça ne change pas.
Ce que Tailscale a révélé
Le 28 octobre 2026, Tailscale a publié sur son blog un article intitulé « Tailscale SSH: Findings and fixes », signé par Mike Shaver, avec Mike Jensen, Jim Scott et Sal Dazzo. Le texte revient sur un rapport de sécurité consacré à Tailscale SSH, Serve et Funnel, et liste cinq constats distincts issus de cette revue.
Deux de ces cinq constats, une fois l’enquête menée, se sont révélés être des comportements voulus : étranges à première vue, mais pas des bugs. Les trois autres, en revanche, sont bien réels, et tous trois sont corrigés dans Tailscale v1.104.4.
Tailscale publie quatre bulletins de sécurité séparés pour ces constats confirmés, numérotés de TS-2026-014 à TS-2026-017. Et on ne trouvera aucun numéro CVE associé, nulle part dans l’article. Aucun des constats n’en a reçu, pour l’instant en tout cas.
Ce que la faille est vraiment, et ce qu’elle n’est pas
C’est le passage à lire sans se presser, parce que ce type de divulgation finit souvent déformé au bout de quelques partages. Le problème que décrit Tailscale, en substance : sous certaines conditions, une session SSH déjà authentifiée pouvait agir au-delà des droits de son utilisateur local, y compris via le forwarding SSH. Autrement dit, on parle d’une élévation de privilèges après authentification, pas d’une porte d’entrée sans identifiants.
Cette nuance change tout sur la façon d’évaluer le risque. On n’est pas sur un contournement distant sans authentification, et il n’y a pas de ver qui se propagerait seul sur le réseau. Pour exploiter l’un des trois constats confirmés, deux conditions doivent déjà être réunies :
- Un attaquant a déjà pris pied sur un appareil qui est un pair autorisé de votre tailnet.
- L’accès Tailscale SSH est explicitement autorisé pour ce pair dans le fichier ACL (la politique) de votre tailnet.
Il s’agit donc d’un risque de mouvement latéral, pas d’un problème d’accès initial. Si une de vos machines est déjà compromise, et que votre politique de tailnet lui permet de se connecter en SSH vers d’autres pairs, la faille pourrait lui laisser faire plus que ce que son compte utilisateur devrait normalement permettre sur la machine ciblée. Ça vaut la peine d’être corrigé, et compris, mais c’est quand même loin du scénario « n’importe qui depuis internet peut entrer dans votre tailnet ».
Un sujet à part, sans lien avec le reste : Conn25
L’article mentionne aussi, en passant, un problème sans rapport dans un composant appelé « Conn25 », décrit comme une fonctionnalité en pré-production qui n’a jamais été déployée. Tailscale est clair là-dessus : les connecteurs d’applications stables, ceux qui existent aujourd’hui, ne sont pas concernés. Si vous utilisez les connecteurs actuels de Tailscale, rien de tout ça ne vous touche. Cette mention figure dans l’article pour être transparent sur le périmètre complet de la revue de sécurité, pas parce qu’il y a quoi que ce soit à corriger chez vous.
Ce qu’il y a à faire, concrètement
Les recommandations de Tailscale sont courtes, et elles méritent d’être suivies même sur un tailnet d’une seule personne.
D’abord, mettre à jour vers Tailscale v1.104.4 ou une version plus récente : c’est cette version qui embarque les correctifs des trois constats confirmés. Vérifiez la version sur chaque appareil, pas uniquement sur ceux que vous rangez mentalement dans la case « serveur ». Un NAS qui fait tourner Tailscale compte autant qu’un VPS dans cette histoire.
Ensuite, relisez vos politiques Tailscale SSH dans le fichier ACL du tailnet. Comme l’exploitation suppose que le SSH soit déjà autorisé entre pairs, c’est une bonne excuse pour aller vérifier qui peut se connecter en SSH vers quoi. Si votre ACL s’est élargi au fil des mois par confort, c’est le moment de le resserrer vers le moindre privilège.
Enfin, pensez au mode de vérification SSH (check mode) pour tout ce qui est sensible. Ce mode impose une ré-authentification avant d’accorder une session, ce qui complique les choses même si l’appareil d’un pair est déjà compromis. Sur un NAS, un serveur de sauvegarde, ou toute machine qui stocke des mots de passe, c’est une couche de protection qui ne coûte presque rien à activer.
Pourquoi ça vaut le coup de s’y arrêter
On installe des outils comme Tailscale sur un homelab justement pour éviter d’exposer son infrastructure directement sur internet. Un VPN en maillage construit sur WireGuard, et c’est exactement ce qu’est Tailscale sous le capot, reste une excellente base pour ça. Mais réduire sa surface d’attaque ne rend immunisé contre aucun bug, et cette divulgation rappelle que la politique du tailnet, autrement dit qui peut atteindre quoi et comment, continue de compter une fois les services sortis d’internet.
Pour résumer : une élévation de privilèges après authentification, limitée par vos propres réglages ACL, ni exploit distant ni ver. Mettez à jour vers v1.104.4, passez dix minutes sur vos règles ACL SSH, et envisagez le mode de vérification pour vos machines les plus sensibles. Pour tous les détails, le mieux reste de lire directement l’article de blog de Tailscale ; et si vous voulez en savoir plus sur l’outil lui-même, notre fiche Tailscale fait le point.
Source : Mike Shaver et al., « Tailscale SSH: Findings and fixes », Tailscale Blog, 28 octobre 2026.