Tailworm : élévation de privilèges vers root dans Tailscale SSH

En bref

• Le serveur intégré de Tailscale SSH s'exécute dans tailscaled, un démon exécuté en tant que root, et effectue les opérations de transfert de sockets Unix — connexion, liaison et suppression — avec les privilèges de root. Une session SSH approuvée peut ainsi atteindre des sockets réservés à root : les chercheurs ont démontré l'exécution de commandes root via docker.sock, un shell root via le socket de contrôle de systemd et la capture des clés d'inscription de nouveaux appareils.
• L'audit a testé des logiciels publiés : le client Tailscale 1.104.2, headscale 0.29.5 et la bibliothèque gliderssh intégrée à Tailscale. Tailscale a livré les correctifs dans la version 1.104.4 le 27 octobre et publié ses conclusions ainsi que quatre bulletins de sécurité le 28 octobre.
• Les chercheurs classent six des onze constats comme élevés, dont la catégorie des transferts de sockets. Les bulletins Tailscale TS-2026-014 à TS-2026-017 couvrent les problèmes SSH et Serve confirmés ; ils ne mentionnent aucun identifiant CVE ni score CVSS au 28 octobre. L'exploitation a uniquement été démontrée en laboratoire : une propagation automatisée mesurée, limitée par la politique, en moins d'une seconde par saut, sans mot de passe ni clé volée. Aucune attaque dans la nature n'est connue.
• Définissez immédiatement TS_SSH_DISABLE_FORWARDING=1 dans l'environnement du service tailscaled et redémarrez-le, réécrivez les règles SSH sous forme d'autorisations par paire et mettez les clients à niveau vers 1.104.4 ou une version ultérieure. Les constats concernant le serveur headscale restent distincts : mettre à jour les clients Tailscale ne corrige pas les problèmes du serveur de contrôle headscale.

Le rapport numérote ses constats comme suit ; les niveaux de gravité sont ceux des chercheurs :

L'évaluation de Tailscale distingue les bogues des comportements prévus : les constats 9 et 10 correspondent au fonctionnement prévu, et le constat 4 concerne conn25 en préproduction, pas les connecteurs d'applications stables.

Suis-je concerné ?

Élévation de privilèges via le transfert de sockets Tailscale SSH. Sur un client non corrigé, vous êtes concerné si toutes ces conditions sont réunies :

• Vous exécutez le client Tailscale avec Tailscale SSH activé sur un nœud cible.
• Votre politique SSH autorise l'utilisateur ou l'appareil qui se connecte à atteindre la cible avec le transfert activé, via une règle accept ou une session check approuvée. headscale 0.29.5 autorise le transfert sur les sessions acceptées sans option de désactivation par règle.
• L'appareil qui se connecte est compromis, ou son utilisateur est un attaquant : les constats s'appliquent depuis des comptes entièrement non privilégiés et ne nécessitent ni mot de passe, ni clé, ni sudo sur la cible.

Déni de service du serveur de contrôle headscale (constat 6). Un point de terminaison d'inscription headscale 0.29.5 accessible depuis Internet peut être attaqué sans compte ni accès SSH. Le rapport exige séparément un initié authentifié pour épuiser la mémoire du DERP intégré ; un relais hostile est le préalable à l'attaque du corps de réponse du client Tailscale.

Vérifiez les versions utilisées et ce que votre politique autorise :

tailscale version                     # client version on every node
tailscale status                      # the peers this device can see
headscale version                     # self-hosted control server, if you run one
sudo systemctl show tailscaled --property=Environment   # is TS_SSH_DISABLE_FORWARDING set?

L'audit indique que les nœuds pouvaient énumérer les pairs du tailnet dans son environnement de test. Ne comptez pas sur le secret de la politique : examinez les règles SSH dans votre fichier de politique, dans la console d'administration Tailscale pour les déploiements SaaS ou dans votre fichier de politique headscale, et comptez celles qui accordent un accès à toute une identité ou une étiquette plutôt que d'un appareil source précis à un appareil destinataire précis.

Comment corriger le problème ?

Mettez les clients Tailscale à niveau vers 1.104.4 ou une version ultérieure. En attendant cette mise à jour, réduisez l'exposition liée au transfert et limitez l'accès SSH ; le durcissement du serveur de contrôle headscale reste une tâche distincte.

1. Désactivez le transfert SSH sauf si vous en avez un besoin documenté. Dans l'environnement du service tailscaled, définissez :

sudo mkdir -p /etc/systemd/system/tailscaled.service.d &&
  printf '[Service]\nEnvironment=TS_SSH_DISABLE_FORWARDING=1\n' |
  sudo tee /etc/systemd/system/tailscaled.service.d/disable-forwarding.conf &&
  sudo systemctl daemon-reload &&
  sudo systemctl restart tailscaled

La mise à jour de Tailscale du 26 octobre indique que cela « atténue plusieurs des constats les plus graves » sans désactiver entièrement Tailscale SSH. Sur le plan de contrôle SaaS, vous pouvez également définir les champs de transfert par règle sur refusé ; headscale 0.29.5 ne possède pas d'option équivalente par règle. Le paramètre d'environnement du service s'applique sur chaque client Tailscale.

1. Réécrivez les règles SSH sous forme d'autorisations par paire : une source précise vers une destination précise, jamais de règles d'acceptation couvrant toute une identité ou une étiquette, ni de comptes cibles privilégiés ; restreindre SSH à des comptes non privilégiés n'apporte qu'une défense en profondeur, puisque les constats s'appliquent depuis des comptes entièrement non privilégiés.
2. Installez Tailscale 1.104.4 ou une version ultérieure sur chaque client, puis vérifiez avec tailscale version. L'article du 28 octobre sur les constats et correctifs de Tailscale renvoie aux bulletins TS-2026-014 à TS-2026-017.
3. Pour les serveurs headscale auto-hébergés, appliquez le durcissement préconisé par le rapport jusqu'à la publication d'une version corrigée : MemoryMax de systemd, supervision des redémarrages, limitation du débit devant les points de terminaison d'inscription et aucune exposition à l'Internet public.
4. Si vous utilisez tailscale serve, supprimez tout transfert TCP ciblant un socket Unix (serve --tcp <port> unix:<path>).
5. Si vous testez conn25 expérimental, retirez cette capacité aux clients qui n'en ont pas besoin, appliquez des NetworkPolicies de sortie avec refus par défaut aux espaces de noms des connecteurs dans Kubernetes et imposez une liste de destinations autorisées au niveau du noyau sur les hôtes connecteurs, pour laquelle le rapport fournit un script. Tailscale indique que les connecteurs d'applications stables ne sont pas affectés.

Quelle est la cause profonde ?

Les opérations de transfert de Tailscale SSH s'exécutent avec les privilèges du démon root : chaque contrôle de chemin visant à les restreindre devient donc une course que la session non privilégiée peut gagner.

Deux choix de conception se combinent. D'abord, Tailscale SSH n'effectue aucune authentification au niveau utilisateur : l'authentification aboutit avec la méthode none, car la couche WireGuard a déjà identifié l'appareil. La politique évalue cette identité d'appareil, et non un justificatif utilisateur ; une session conserve donc l'intégralité des autorisations de l'appareil pendant toute sa durée.

Ensuite, le serveur SSH intégré réside dans tailscaled, qui s'exécute en tant que root, et sa bibliothèque gliderssh effectue les opérations de transfert de sockets Unix, connexion pour ssh -L, liaison et suppression pour ssh -R, en tant que root.

La bibliothèque tente de limiter les destinations du transfert. Dans streamlocal.go de tailscale/gliderssh, les fonctions validateAndResolveSocketPath et validateAndResolveListenPath contrôlent le chemin par rapport à une liste de répertoires autorisés avant l'opération, en résolvant les liens symboliques, car c'est le noyau, et non le validateur, qui effectue la connexion finale :

// validateAndResolveSocketPath validates socketPath lexically, then resolves
// its symlinks and re-checks that the real destination is still within
// opts.AllowedDirectories and not excluded by opts.DeniedPrefixes. It returns
// the resolved path to dial.
//
// The lexical check alone is insufficient because the kernel connects to the
// symlink target: a symlink inside an allowed directory could otherwise
// redirect the connection to a socket outside it (e.g. a link in the user's
// home dir pointing at /var/run/docker.sock).

Tailscale 1.104.2 embarque gliderssh en version v0.3.4-0.20260716005906-1a0f895faf28, selon son fichier go.mod, et la liste d'autorisation couvre le répertoire personnel de l'utilisateur, /tmp et /run/user/<uid>. Mais la validation intervient au moment du contrôle, tandis que la suppression, la liaison et la connexion surviennent plus tard, lorsque le noyau résout à nouveau le chemin.

Le constat 3 montre cet écart : une boucle de concurrence rename(2) dans la propre session SSH de l'attaquant, mesurée à environ 170 000 changements d'état du chemin par seconde, présente un chemin bénin au contrôle, puis bascule le répertoire vers la cible avant l'opération du démon root. La conclusion du rapport tient en une phrase : la liste d'autorisation {home, /tmp, /run/user} « n'est pas une frontière de sécurité ».

Cette catégorie possède un précédent reconnu par une CVE et une correction connue. CVE-2025-14282 dans Dropbear en était la variante côté connexion, corrigée dans 2025.89 par un appel à setuid() vers l'utilisateur de la session avant toute opération de transfert, ce qui rend tout contrôle de chemin inutile. OpenSSH est le contre-exemple sûr audité par le rapport : son processus enfant post-authentification abandonne ses privilèges au profit de l'utilisateur de la session avant la boucle serveur ; il n'y a donc ni phase de contrôle ni intervalle entre contrôle et utilisation.

Comment la faille est-elle exploitée ?

La démonstration la plus simple, le constat 1, nécessite une seule règle de politique SSH autorisant le transfert local ; elle montre la connexion en tant que root sans aucune course. Les commandes proviennent du kit public de reproduction du rapport :

ssh -fNT -L /tmp/relay.sock:/tmp/docker.sock user@target   # dockerd at an allowlisted-dir socket
docker -H unix:///tmp/relay.sock run --rm -v /:/host busybox sh -c 'id; head -c 40 /host/etc/shadow'

La connexion est effectuée par tailscaled : les identifiants du pair présentés au socket sont donc ceux de root. Le résultat vérifié était uid=0(root) et le contenu de /etc/shadow, sans sudo ni appartenance au groupe Docker. Cette démonstration utilise le dockerd standard de la cible via tailscaled ; elle ne nécessite ni démon implanté ni vulnérabilité distincte de dockerd. La chaîne la plus puissante, le constat 3, exploite l'intervalle entre contrôle et utilisation :

1. L'attaquant dispose d'un accès initial sur un appareil autorisé par la politique, via une application web exploitée, une dépendance malveillante, un implant d'hameçonnage ou des identifiants volés, et se connecte via Tailscale SSH à une cible sous une règle autorisant le transfert.
2. Dans la session, il exécute une boucle de concurrence rename(2) sur un répertoire de la liste d'autorisation, en changeant l'état du chemin environ 170 000 fois par seconde, afin que le contrôle lexical voie un chemin bénin et que le noyau le résolve vers la cible au moment de l'opération.
3. Le démon root supprime le socket actif appartenant à root au chemin réel, par exemple /run/docker.sock, le socket localapi de tailscaled ou le socket de contrôle de headscale, et y lie le point d'écoute de transfert de l'attaquant.
4. L'attaquant maintient cette nouvelle liaison ouverte pendant au moins 4 minutes, durée vérifiée, et agit comme intermédiaire sur le service. Sur le socket localapi, le trafic capturé comprenait un POST /localapi/v0/start reproduit octet pour octet contenant une authkey, le justificatif qui inscrit de nouveaux appareils.
5. L'attaquant utilise l'authkey capturée sur un nœud temporaire et le joint au tailnet sous l'identité de la victime : un nœud malveillant qui ressemble à un serveur légitime étiqueté avec des routes automatiquement approuvées, démontré de bout en bout en laboratoire.

Un constat annexe étend les primitives : la garde de suppression et le chmod après mise en écoute suivent le chemin lexical au moment de l'utilisation. La session concurrente peut donc faire supprimer par root des fichiers ordinaires arbitraires et leur appliquer le mode 0600, causant une destruction sans modification du contenu.

Quel est le déroulement de l'attaque ?

Un appareil compromis disposant d'une règle SSH approuvée obtient root sur les serveurs cibles, puis devient un nœud persistant du réseau, sans vol de mot de passe ni de clé à aucun stade de la chaîne.

Que peut faire un attaquant ?

La prise de contrôle des sockets atteint les services privilégiés qui utilisent des sockets Unix. Le rapport démontre les éléments suivants, preuves à l'appui :

• Exécution de commandes root via une course sur un dockerd standard : une seule connexion persistante gagnant la course a réalisé la création d'un conteneur avec / monté par liaison et l'exécution de commandes avec l'uid 0.
• Shell root via le socket de contrôle de systemd : systemd a autorisé les connexions à /run/systemd/private présentant les identifiants de root, et des octets D-Bus rejoués ont démarré une unité transitoire produisant un shell inversé root, avec une réussite intermittente de la course. Les connexions concurrentes à un socket kubelet factice ont également toutes été acceptées en présentant l'uid 0.
• Vol de justificatifs d'inscription d'appareils : la chaîne allant de la prise de contrôle du socket à l'inscription transforme une nouvelle liaison en nœud malveillant avec routes automatiquement approuvées. Cette persistance survit à la réinstallation de l'hôte d'origine, tandis que la suppression arbitraire de fichiers root et le chmod 0600 forcé compromettent la disponibilité.
• Propagation à l'ensemble du parc : avec un chemin SSH autorisé par la politique, le rapport a mesuré une propagation automatisée vers chaque appareil permis, sans mot de passe, clé volée ni interaction utilisateur, en moins d'une seconde par saut. Deux limites structurelles ont tenu : les autorisations par paire ont stoppé la propagation, et les justificatifs d'appareil liés au matériel ont empêché la persistance du vol d'identité.
• Épuisement de la mémoire du démon root, constat 5 : des changements répétés de taille de fenêtre et des ajouts illimités à l'environnement ont alloué environ 536 Mo en 7 secondes, persistant après la déconnexion, une faille héritée de gliderlabs/ssh v0.3.8 en amont.
• Validation des sorties des connecteurs d'applications, constat 4 : conn25 expérimental permet à un utilisateur ordinaire habilité pour une application de choisir des destinations de sortie arbitraires via le connecteur, y compris les métadonnées cloud et les services Kubernetes, car la destination déclarée par le client n'est jamais vérifiée par rapport aux backends configurés de l'application. Tailscale indique que cela n'affecte pas les connecteurs d'applications stables.
• Déni de service headscale, constat 6 : l'éviction non authentifiée du cache d'inscription peut bloquer l'intégration d'appareils à l'échelle de l'organisation ; l'épuisement de mémoire du DERP intégré nécessite un initié authentifié. Le sous-constat relatif au client Tailscale nécessite un relais hostile.

Pour le transfert de sockets, les conditions sont un appareil approuvé ou compromis disposant d'un accès SSH autorisé par la politique et du transfert activé sur un client non corrigé. headscale 0.29.5 accorde le transfert sans option de désactivation par règle. Le mode check, la réauthentification SSH de Tailscale dans le navigateur, ne contrôle pas le transfert : il approuve l'établissement de la session, puis les constats sur le transfert de sockets s'appliquent pendant toute la durée de cette session approuvée.

Pourquoi le correctif fonctionne-t-il ?

Les correctifs du transfert SSH pour les constats 1–3 exécutent les opérations sur les sockets sous l'utilisateur de la session, appliquant la séparation des privilèges recommandée par le rapport et déjà utilisée dans le correctif Dropbear de CVE-2025-14282. Les constats Serve et d'épuisement de ressources ont des correctifs distincts. D'après la section du rapport sur les réponses en amont et les bulletins de sécurité de Tailscale :

• Constats 1 à 3 : le transfert SSH a été réorganisé autour d'un moniteur par connexion avec des processus enfants non privilégiés dotés des identifiants appropriés. La connexion, la liaison et la suppression des sockets transférés s'exécutent désormais avec les identifiants de l'utilisateur authentifié de la session, et les identifiants du pair de la charge utile désignent cet utilisateur plutôt que le démon root. La revalidation lexicale des chemins contournée par la course a été supprimée au profit des contrôles d'accès discrétionnaires du noyau comme frontière.
• Constat 5 : les envois de changements de fenêtre dans gliderssh sont non bloquants et conservent la valeur la plus récente, et les modifications répétées de l'environnement sont bornées (PR #21945 et #21953 ; le message de commit amont cite les mesures de l'audit).
• Constat 7 : le transfert TCP serve vers le socket localapi est refusé à la configuration et à chaque connexion (PR #21966).
• Constat 8 : les cibles des backends Unix du proxy HTTP Serve sont revalidées à chaque connexion, remplaçant la garde de liens symboliques limitée au rechargement de configuration. Tailscale identifie ce correctif dans TS-2026-016, livré dans 1.104.4.
• Constat 11 : la gestion des capacités passe à un contexte par requête (PR #21931).
• Constat 6 (client) : le relais borne la lecture du corps de réponse (PR #21980).

Pour le transfert SSH, dès que la connexion, la liaison et la suppression s'exécutent sous l'utilisateur de la session, les propres contrôles de permission du noyau déterminent ce que la session peut toucher. Il n'y a plus d'intervalle entre contrôle et utilisation, car aucun contrôle privilégié n'est nécessaire. Tailscale 1.104.4 a livré ces correctifs clients le 27 octobre ; l'éditeur a confirmé leur disponibilité le 28 octobre. Le rapport a testé headscale 0.29.5 et indique toujours que ses correctifs côté serveur sont en attente. Mettre à jour le client Tailscale ne corrige pas ces constats headscale.

Comment vérifier si j'ai été compromis ?

Aucune attaque réelle n'est connue. Voici les recommandations de détection du rapport pour examiner les systèmes non corrigés :

• Audit du cycle de vie des sockets : règles auditd sur les opérations de suppression, liaison et chmod des sockets Unix dans les répertoires où le transfert est autorisé, /tmp, les répertoires personnels et /run/user, ainsi que sur les chemins des sockets de l'agent, avec un périmètre par objet, chemin et opération plutôt que par nom d'appel système. Un socket en mode 0755 à un emplacement devant être en 0600 est une signature forensique d'une liaison ayant gagné la course et dont le chmod après mise en écoute a été redirigé.
• Détection des rafales de renommage : la course exige des boucles soutenues de renommage de répertoires de l'ordre de 100 000 par seconde. Une surveillance inotify ou audit avec alerte de débit sur les répertoires candidats permet donc de la détecter.
• Surveillance des inscriptions et des clés : déclenchez une alerte lors de l'émission ou de l'utilisation d'une authkey hors des fenêtres de changement, ou lorsqu'un nœud rejoint le réseau avec une clé jamais vue sous une identité étiquetée. Traitez comme un incident le signalement d'une demande d'authentification Tailscale non sollicitée, car la connexion d'un attaquant peut déclencher l'invite check. Pour headscale, surveillez la mémoire résidente, l'activité du cache d'inscription et la latence d'inscription.

Si vous trouvez des preuves de compromission, une réinstallation ne suffit pas à contenir l'incident : l'identité d'un nœud est un ensemble de clés stocké dans un fichier d'état, qu'un attaquant disposant de root peut avoir copié hors de la machine. Ces clés restent valides jusqu'à la suppression de l'appareil dans le plan de contrôle ou leur expiration. Supprimez l'appareil, renouvelez les authkeys et identifiants accessibles depuis l'hôte affecté, et renouvelez Tailnet Lock si un nœud signataire a été compromis.

Chronologie

• 2026-10-22 à 2026-10-24 : Cyberdione Labs teste les versions publiées Tailscale 1.104.2, headscale 0.29.5 et la bibliothèque gliderssh intégrée ; les constats sur les connecteurs concernent conn25 expérimental en préproduction.
• 2026-10-25 : publication du rapport Tailworm avec onze constats et des kits de reproduction ; The Hacker News le couvre le même jour.
• 2026-10-26 : Tailscale publie « Tailscale SSH : point sur l'enquête et la remédiation », confirmant une grave élévation de privilèges au-delà de l'utilisateur local configuré et visant un client corrigé avant la fin du 27 octobre, sous réserve des tests. Les correctifs des constats 1 à 3 et 5 arrivent dans les branches principales de tailscale et gliderssh.
• 2026-10-27 : les correctifs des constats 7, 11 et du composant relais client sont fusionnés (PR #21966, #21931, #21980) ; une refonte du cache d'inscription headscale, PR #3586, reste en attente. Tailscale étiquette le client corrigé en version 1.104.4.
• 2026-10-27 : publication de cet article.
• 2026-10-28 : Tailscale publie ses constats et correctifs avec les bulletins TS-2026-014 à TS-2026-017 ; cet article est mis à jour pour refléter la disponibilité de 1.104.4 et le périmètre restant.

FAQ

Tailscale demande-t-il à tout le monde de désactiver Tailscale SSH ?

Non. La mise à jour du 26 octobre de Tailscale indique qu'il « ne recommande pas à tout le monde de désactiver Tailscale SSH », car l'exploitation dépend des permissions accordées à l'utilisateur ou à l'appareil qui se connecte et de la configuration du système. Pour les clients non corrigés, Tailscale préconise provisoirement de désactiver le transfert, de revoir les politiques d'accès SSH et de restreindre l'accès aux systèmes sensibles. Sa recommandation du 28 octobre est de passer à 1.104.4 ou une version ultérieure.

Le mode check me protège-t-il ?

Non. Le mode check ne contrôle que l'établissement de la session ; le transfert de ports se déroule dans une session établie et approuvée, et tous les constats sur le transfert de sockets s'appliquent pendant toute sa durée. Le rapport a aussi mesuré que, sur le plan de contrôle SaaS, une seule vérification réussie couvre toutes les destinations en mode check jusqu'à l'expiration de la fenêtre d'approbation. L'autorisation habituelle d'un utilisateur peut donc rendre exploitables les destinations qui intéressent l'attaquant.

Tailnet Lock empêche-t-il l'inscription du nœud malveillant ?

Il élève la difficulté, mais n'a pas constitué un blocage complet en laboratoire. Avec Tailnet Lock désactivé, configuration par défaut, la chaîne complète de l'authkey capturée au nœud malveillant en ligne a fonctionné de bout en bout ; avec le verrou activé, le secret de désactivation et les clés du signataire ont été capturés en transit, bien qu'aucune désactivation réelle n'ait été exécutée. Traitez la compromission d'un nœud signataire comme un besoin de renouveler le verrou, pas comme un simple nettoyage. Le rapport documente des kits de reproduction pour chaque constat, et aucun exploit fonctionnel contre un déploiement réel n'est connu.

Ces failles sont-elles exploitables depuis Internet ?

Pas directement pour les constats SSH : l'attaquant a besoin d'un accès initial sur un appareil déjà autorisé par la politique, ou d'un compte approuvé. Dans le laboratoire du rapport, le maillage a transformé un seul accès initial en accès privilégié aux destinations autorisées par la politique, à vitesse machine. Les constats headscale sont différents : un utilisateur Internet non authentifié peut perturber l'inscription de nouveaux appareils via un point de terminaison d'inscription accessible depuis Internet, d'où la nécessité de ne pas l'exposer.

Quelle version du client corrige ces problèmes ?

Installez Tailscale 1.104.4 ou une version ultérieure et confirmez avec tailscale version sur chaque nœud. L'article de Tailscale du 28 octobre sur les constats et correctifs et les bulletins TS-2026-014 à TS-2026-017 confirment cette version. Tant que chaque client n'est pas mis à jour, désactivez le transfert SSH et utilisez des autorisations SSH par paire. Les correctifs du serveur de contrôle headscale restent distincts.

Analysez votre surface d'attaque externe avec Ostorlab pour repérer les serveurs de contrôle headscale exposés sur Internet et les autres infrastructures auto-hébergées qui ne devraient pas être accessibles depuis l'Internet public.

Références

• Cyberdione Labs, « Tailworm : rapport d'évaluation de sécurité, Tailscale v1.104.2 et headscale v0.29.5 », publié le 25 octobre 2026, avec les onze constats, les reproductions vérifiées, les mesures de propagation et les recommandations de détection, ainsi que la matrice d'atténuation mise à jour le 28 octobre : https://tailworm.com/ (consulté le 28 octobre 2026)
• Tailscale, « Tailscale SSH : point sur l'enquête et la remédiation », 26 octobre 2026, confirmant les constats, l'atténuation TS_SSH_DISABLE_FORWARDING=1 et l'objectif d'un client corrigé pour la fin du 27 octobre : https://tailscale.com/ssh-investigation-update (consulté le 27 octobre 2026)
• Pull requests de correction tailscale/tailscale : #21941, #21942, #21943, #21944, #21945, #21953, #21959, #21963, #21966, #21931, #21980 (consulté le 28 octobre 2026)
• streamlocal.go de tailscale/gliderssh, fonctions validateAndResolveSocketPath et validateAndResolveListenPath, la validation lexicale puis résolue que la course contourne : https://github.com/tailscale/gliderssh/blob/master/streamlocal.go (consulté le 27 octobre 2026)
• go.mod de Tailscale 1.104.2, fixant gliderssh à v0.3.4-0.20260716005906-1a0f895faf28 : https://github.com/tailscale/tailscale/blob/v1.104.2/go.mod (consulté le 27 octobre 2026)
• CVE-2025-14282 de Dropbear, le précédent de cette catégorie corrigé dans 2025.89 en définissant l'uid de session avant toute requête de canal ou globale : https://nvd.nist.gov/vuln/detail/CVE-2025-14282 (référencé via le rapport Tailworm, consulté le 27 octobre 2026)
• Refonte du cache d'inscription headscale, PR #3586, adoptant le contrôle d'admission plutôt que l'éviction et citant le rapport : https://github.com/juanfont/headscale/pull/3586 (référencé via la réponse amont Tailworm, consulté le 27 octobre 2026)
• Couverture des constats Tailworm par The Hacker News, 25 octobre 2026 : https://thehackernews.com/2026/10/unpatched-tailscale-ssh-flaws-could-let.html (consulté le 27 octobre 2026)
• Version Tailscale 1.104.4 : https://github.com/tailscale/tailscale/releases/tag/v1.104.4; constats et correctifs de l'éditeur, 28 octobre 2026 : https://tailscale.com/blog/tailscale-ssh-findings-fixes; bulletins de sécurité TS-2026-014 à TS-2026-017 : https://tailscale.com/security-bulletins (consulté le 28 octobre 2026)