Tailworm: falle in Tailscale SSH danno root da un nodo violato

Nel fine settimana del 24-25 ottobre 2026 Cyberdione Labs ha pubblicato i dettagli di 11 vulnerabilità in Tailscale, la VPN mesh basata su WireGuard, e in headscale, il server di controllo open source che le aziende possono ospitare da sé. I ricercatori le chiamano nel complesso Tailworm. Le hanno trovate durante un audit di Tailscale 1.104.2 e headscale 0.29.5 e le hanno riprodotte in laboratorio su software rilasciato e non modificato (BleepingComputer).

La pubblicazione è avvenuta prima che esistessero patch. Secondo SecurityWeek la scelta ha attirato critiche sui social, mentre la fondatrice di Cyberdione Labs, Erica Windisch, sostiene che far conoscere subito le falle accelera la correzione e che sono state trovate «con poco sforzo». Alla data degli articoli non risultano CVE assegnate e né Tailscale né il rapporto parlano di sfruttamenti in corso (SecurityWeek).

Il problema principale: Tailscale SSH

Tailscale SSH è il server SSH integrato in tailscaled: gira come root e concede l’accesso in base all’identità del dispositivo e alle policy della tailnet, senza password né chiavi. Secondo il rapporto citato dalle due testate, l’inoltro di socket Unix (ssh -R e ssh -L) esegue i controlli sui percorsi e le operazioni sui file con privilegi di root. Race condition e la mancata riduzione dei privilegi permettono a una sessione ordinaria di sostituire, aprire o cancellare risorse privilegiate.

Dei sei problemi di gravità alta, quattro riguardano Tailscale SSH (SecurityWeek). Gli esiti dimostrati in laboratorio:

• esecuzione di codice come root sui server di destinazione;
• furto delle chiavi di registrazione, con cui aggiungere dispositivi abusivi alla tailnet;
• cancellazione di file arbitrari con privilegi di root.

Il requisito è un dispositivo approvato più una regola SSH che consenta l’inoltro. Su headscale l’inoltro è concesso in automatico, sul servizio SaaS di Tailscale dipende dalla singola regola (BleepingComputer).

Una catena che si propaga da sola

Secondo SecurityWeek, i ricercatori hanno dimostrato che le falle sono wormable: non servono credenziali dell’utente, e un attacco automatico che concatena i bug si è spostato da una macchina all’altra su tutti i server raggiungibili via Tailscale SSH secondo la policy, in meno di un secondo per passaggio e senza interazione. Il punto d’ingresso può essere qualunque compromissione di un nodo: phishing, un’applicazione web vulnerabile, un pacchetto software malevolo. Il titolo di The Hacker News descrive lo stesso scenario: un dispositivo violato che arriva a root su altri server.

Tecniche MITRE ATT&CK pertinenti (nostra classificazione): T1021.004 (SSH come servizio remoto), T1068 (sfruttamento per l’elevazione dei privilegi) e T1210 (sfruttamento di servizi remoti) per la propagazione.

Le altre falle

Il rapporto descrive anche (BleepingComputer, SecurityWeek):

• app connector (conn25, funzione sperimentale): il traffico viene tradotto verso destinazioni scelte dall’attaccante senza validazione, e le ACL non vengono applicate alla destinazione reale. Con un dispositivo che ha la capability del connettore si raggiungono i servizi di metadati del cloud (furto di credenziali, T1552.005), le LAN interne e, in Kubernetes, ogni servizio del cluster;
• headscale: esaurimento delle risorse senza autenticazione (crescita della memoria, svuotamento della cache), alla portata di chiunque raggiunga il server. Esito: crash a ripetizione del server di controllo e blocco della registrazione di nuovi dispositivi in tutta l’organizzazione;
• client DERP (il relay presente in ogni agent): lettura senza limiti della risposta di un relay malevolo, con esaurimento della memoria del client;
• tailscale serve: l’inoltro TCP verso un socket Unix non ha una protezione che c’è invece sul percorso HTTP, e una race nell’autorizzazione dei singoli mount lascia passare una parte delle richieste. Esito: accesso remoto all’API di amministrazione del nodo.

La risposta di Tailscale

Mike Shaver, VP of Engineering di Tailscale, ha scritto su Reddit che l’azienda stava già conducendo un’indagine propria, con specialisti esterni, quando è arrivato il rapporto. Secondo Tailscale la maggior parte dei problemi riguarda ciò che accade dopo che qualcuno è autorizzato a connettersi: una sessione può fare più di quanto consentito all’utente locale configurato. È un problema serio, ma non equivale a un attaccante non autenticato che si collega a macchine arbitrarie; l’impatto dipende da come è configurato l’accesso SSH (SecurityWeek, BleepingComputer).

Tailscale non raccomanda di disattivare Tailscale SSH e puntava a rilasciare il client corretto entro martedì 27 ottobre. Secondo l’aggiornamento di SecurityWeek, l’azienda ha poi pubblicato i dettagli completi, le correzioni distribuite e quattro bollettini di sicurezza con le indicazioni di rimedio. Le fonti non riportano il numero della versione corretta: va verificato nei bollettini di Tailscale. Per headscale le fonti non indicano una versione corretta.

Impatto per le aziende europee e italiane

Tailscale è usato per l’accesso remoto di amministratori, sviluppatori e fornitori: un solo portatile compromesso con accesso SSH a molti server diventa il punto di partenza per arrivare a root su tutti. Le chiavi di registrazione rubate permettono di restare nella rete anche dopo la bonifica del primo dispositivo. Per i soggetti NIS2 il caso tocca la gestione delle vulnerabilità e il controllo degli accessi privilegiati, compresi quelli di fornitori e manutentori. Nella sanità vanno verificati per primi i nodi che danno accesso a sistemi clinici.

Cosa fare subito

1. Aggiorna i client Tailscale alla versione indicata nei bollettini di Tailscale, a partire dai server che accettano Tailscale SSH.
2. Disattiva l’inoltro SSH dove non serve: TS_SSH_DISABLE_FORWARDING=1 nell’ambiente del servizio tailscaled, poi riavvia il servizio. Tailscale SSH resta attivo e, secondo Tailscale, si mitigano diverse delle falle più gravi.
3. Restringi le policy SSH ai soli utenti e dispositivi che ne hanno bisogno, almeno finché l’analisi non è chiusa.
4. headscale: non esporre il server di controllo più del necessario e segui gli aggiornamenti del progetto; ricorda che lì l’inoltro è concesso in automatico.
5. App connector e serve: verifica chi ha la capability dei connettori e quali inoltri verso socket Unix sono configurati.
6. Rilevamento: cerca nella tailnet dispositivi registrati di recente e non riconosciuti, sessioni SSH con inoltro di socket Unix, file di sistema cancellati o sostituiti. In caso di dubbio ruota le chiavi di registrazione.

Come aiuta ARXDOME

ARX Sentry raccoglie dai server Linux eventi di sicurezza, inventario del software e controllo dell’integrità dei file nelle cartelle stabilite: aiuta a trovare le macchine con Tailscale, a vederne la versione e a notare accessi privilegiati o file di sistema modificati. Se un nodo è sospetto, ARX Shield lo isola dalla rete fino alla verifica.

Ultimo aggiornamento: 27 ottobre 2026