Tailscale, Tailworm e le 11 falle: quanto è davvero grave il rischio

Un totale di 11 vulnerabilità, accesso root ai server e un attacco in grado di propagarsi automaticamente attraverso una rete Tailscale. Presentata così, Tailworm sembra quasi una nuova epidemia informatica pronta a diffondersi tra i sistemi collegati tramite la nota VPN mesh. La realtà tecnica è più articolata e, soprattutto, meno catastrofica.

La ricerca pubblicata da Erica Windisch di Cyberdione Labs descrive effettivamente diversi problemi verificati in laboratorio su Tailscale 1.104.2 e headscale 0.29.5.

Tailscale è una soluzione VPN mesh basata su WireGuard che collega dispositivi e server attraverso una rete privata cifrata, chiamata tailnet, applicando regole di accesso centralizzate. headscale è invece un’implementazione open source e self-hosted del control server Tailscale: consente di usare client compatibili senza affidare il piano di coordinamento all’infrastruttura cloud di Tailscale.

Il punto da chiarire subito è però uno: Tailworm non permette a un aggressore casuale su Internet di entrare in una rete Tailscale e ottenere automaticamente privilegi root sui server!

Tailworm NON è una RCE pre-auth da Internet

Gli scenari più seri descritti dalla ricerca presuppongono generalmente che l’attaccante abbia già compromesso un dispositivo appartenente alla tailnet oppure disponga comunque di un’identità autorizzata. Per sfruttare la principale catena relativa a Tailscale SSH, inoltre, le policy devono consentire al nodo sorgente di aprire una sessione SSH verso il sistema bersaglio. Anche il port forwarding assume un ruolo importante nella catena descritta.

La vulnerabilità non rompe WireGuard, non permette di indovinare le chiavi crittografiche e non annulla automaticamente le Access Controls di Tailscale. Il problema riguarda invece cosa può fare una macchina che ha già ottenuto una posizione legittima all’interno della rete.

Il problema più serio: da utente normale a root

Una delle scoperte più “sinistre” riguarda il forwarding verso Unix domain socket (inoltro di una connessione SSH non verso una porta TCP, ma direttamente verso un socket locale Unix, cioè un file speciale usato dai processi per comunicare tra loro).

Il servizio tailscaled è infatti caricato con privilegi elevati perché deve amministrare networking, routing e altre funzioni di sistema. Secondo la ricerca Tailworm, determinate operazioni di forwarding possono sfruttare proprio il daemon privilegiato per raggiungere socket ai quali l’utente della sessione SSH non dovrebbe avere accesso.

Lo scenario è delicato perché su Linux alcuni socket concedono di fatto capacità amministrative: un esempio classico è /var/run/docker.sock.

Chi riesce a interagire liberamente con il socket Docker può creare container privilegiati, montare il filesystem dell’host e arrivare rapidamente a privilegi equivalenti a root.

Tailscale aveva già corretto a giugno 2026 un problema nel quale Tailscale SSH non verificava correttamente i collegamenti simbolici durante il forwarding dei Unix socket: un utente sprovvisto di diritti poteva così raggiungere risorse protette come docker.sock. La vulnerabilità era stata corretta con Tailscale 1.98.9 ma le ricerche alla base di Tailworm mettono in evidenza l’esistenza di ulteriori strade attraverso cui aggirare le protezioni introdotte.

Quanto è davvero “wormable”?

Un worm classico, come WannaCry, può compromettere autonomamente una macchina vulnerabile e utilizzarla immediatamente per attaccarne altre. Non è ciò che Tailworm sembra poter fare su Internet.

La propagazione automatica descritta dalla ricercatrice avviene piuttosto all’interno del grafo delle autorizzazioni della tailnet. Supponiamo che il PC-A sia autorizzazione ad accedere a Server-B via SSH e che Server-B possa a sua volta accedere via SSH a Server-C.

Se PC-A viene compromesso e la prima escalation riesce, un attaccante potrebbe tentare automaticamente di proseguire verso Server-B e successivamente Server-C.

Qualora le policy stabilissero che PC-A può effettivamente connettersi con Server-B ma quest’ultimo non può raggiungere Server-C, la catena si interromperebbe.

La wormability dipende quindi dalle relazioni di fiducia definite nelle Access Controls, dal numero di sistemi raggiungibili, dall’uso di Tailscale SSH e dalle funzioni di forwarding abilitate. Definire Tailworm come “worm che infetta tutte le macchine Tailscale” è quindi tecnicamente scorretto.

Come ridurre subito il rischio con Tailscale

Tailscale SSH è la funzione che permette di aprire sessioni SSH verso i dispositivi della propria tailnet usando l’identità e le Access Controls di Tailscale, senza dover gestire chiavi SSH tradizionali o esporre la porta 22 su Internet. È Tailscale a stabilire chi può collegarsi, a quale macchina e con quale utente.

Chi non utilizza Tailscale SSH può semplicemente lasciarlo disabilitato. Se è già attivo ma non indispensabile, sul server è possibile eseguire il comando seguente:

tailscale set --ssh=false

Ovviamente è essenziale verificare di disporre di un altro metodo per amministrare la macchina, altrimenti si rischia di perdere l’accesso remoto.

Per isolare completamente un nodo dalle connessioni in ingresso provenienti dalla tailnet è invece disponibile il comando seguente:

tailscale set --shields-up

Il dispositivo continua a poter iniziare connessioni verso la rete Tailscale, ma non accetta quelle in ingresso. Chi deve mantenere Tailscale SSH dovrebbe rivedere attentamente le Access Controls, eliminando regole che consentono a molti dispositivi di collegarsi indiscriminatamente a molti server (segmentazione).

Usare check mode per gli accessi più critici

Tailscale SSH supporta anche action: "check" al posto del semplice accept. Questa modalità obbliga l’utente a riautenticarsi prima di aprire la sessione SSH e può attivare anche MFA (multi-factor authentication) o altri controlli previsti dall’Identity Provider.

In ambienti particolarmente sensibili è possibile utilizzare la seguente direttiva così da richiedere una nuova verifica a ogni connessione:

"checkPeriod": "always"

Tailscale precisa che questa opzione è disponibile nei piani Premium ed Enterprise e può interferire con strumenti che aprono molte sessioni automaticamente, come Ansible. L’utilizzo di check mode non corregge una vulnerabilità che agisca dopo l’autenticazione, ma rende più difficile sfruttare automaticamente le credenziali di una macchina compromessa.

Tailworm è grave, ma il problema reale è il movimento laterale

Diversamente rispetto a quanto rappresentato in alcune ricostruzioni, Tailworm non appare come una vulnerabilità capace di trasformare qualunque installazione Tailscale in una porta aperta verso Internet.

Il rischio reale è più sottile: un endpoint già compromesso può diventare molto più pericoloso se le policy Tailscale gli concedono accesso SSH verso numerosi server e una vulnerabilità consente di oltrepassare il confine tra utente normale e root.

In una tailnet ben segmentata la propagazione può fermarsi molto presto; in una rete dove qualsiasi macchina può raggiungere praticamente qualsiasi server, lo stesso problema può invece assumere conseguenze ben più serie.

La lezione da “portare a casa” è la seguente: utilizzare una VPN mesh e adottare un modello Zero Trust non basta se le policy finiscono, nei fatti, per creare una rete interna in cui ogni host si fida automaticamente di tutti gli altri presenti.