Tailscale SSH e falle Tailworm: aggiornare alla 1.104.4 e disattivare l’inoltro

Articolo aggiornato al 29 ottobre 2026. La situazione è ancora in evoluzione: lo aggiornerò se Tailscale rilascia nuove correzioni.

Se usate Tailscale per raggiungere i server dei clienti senza aprire porte sul firewall, e in particolare se avete attivato Tailscale SSH per non dover più distribuire chiavi, in questi giorni c’è un aggiornamento da non rimandare. Il 26 ottobre Tailscale ha pubblicato quattro bollettini di sicurezza, da TS-2026-014 a TS-2026-017, relativi a una serie di falle che i ricercatori hanno battezzato “Tailworm”.

La più seria riguarda proprio Tailscale SSH: un utente già autorizzato a collegarsi con un account locale limitato poteva, sfruttando l’inoltro delle connessioni (il classico ssh -L o ssh -R), arrivare a eseguire operazioni come root sul server di destinazione. Tutte e quattro le falle sono corrette nella versione 1.104.4 del client.

Chi è coinvolto

Il punto chiave è che per sfruttare queste falle serve già un piede dentro la tailnet: un dispositivo autorizzato e una regola SSH che gli permetta di collegarsi. Non è quindi un attacco da Internet contro chiunque abbia Tailscale installato. Il rischio però è concreto proprio negli ambienti tipici delle PMI, dove un portatile compromesso di un collaboratore o di un fornitore con accesso SSH “da utente normale” può diventare la porta per prendere il controllo dei server.

In sintesi, i quattro bollettini:

• TS-2026-014: Tailscale SSH controllava i percorsi dei socket Unix con i permessi dell’utente ma poi li apriva come root. Riguarda chi usa Tailscale SSH con l’inoltro consentito dalle policy; tra i bersagli più pericolosi c’è il socket di Docker.
• TS-2026-015: un peer autenticato in una sessione SSH poteva far crescere senza limiti la memoria di tailscaled fino a farlo terminare, con il nodo che perde la connettività.
• TS-2026-016: tailscale serve con backend su socket Unix poteva raggiungere socket privilegiati, compreso quello dell’API locale di tailscaled.
• TS-2026-017: con Serve in TLS e più mount sullo stesso nodo, una race condition su HTTP/2 poteva applicare a una richiesta le capability destinate a un altro mount.

Se usate Tailscale solo come VPN, senza Tailscale SSH e senza Serve, l’esposizione è molto più bassa. L’aggiornamento resta comunque consigliato.

Prima di iniziare

Fate un inventario dei nodi. Dalla console di amministrazione, nella pagina Machines, vedete la versione del client di ogni dispositivo: segnatevi quelli sotto la 1.104.4, partendo dai server che accettano Tailscale SSH. Sul singolo nodo potete verificare la versione e se Tailscale SSH è attivo così:

tailscale version
tailscale debug prefs | grep RunSSH

Se compare "RunSSH": true, quel nodo fa da server Tailscale SSH ed è il primo da aggiornare.

Attenzione: aggiornare tailscaled fa cadere per qualche secondo le connessioni che passano dalla tailnet, compresa la sessione SSH da cui state lavorando. Su un server che raggiungete solo via Tailscale, tenete a portata di mano un accesso alternativo (console dell’hypervisor, iDRAC/iLO, una sessione dalla LAN) prima di procedere.

Aggiornare il client alla 1.104.4

Sui server Debian e Ubuntu installati dal repository ufficiale di Tailscale io preferisco passare dal gestore pacchetti, così l’aggiornamento resta tracciato come tutti gli altri:

sudo apt update && sudo apt install --only-upgrade tailscale
tailscale version

In alternativa, su Linux, Windows e sulle versioni standalone per macOS c’è l’aggiornamento integrato:

sudo tailscale update

Per le versioni installate da App Store o da store dei NAS l’aggiornamento arriva dai rispettivi canali e può tardare qualche giorno: controllate la versione a mano dopo l’aggiornamento. Se avete molti nodi, valutate di attivare gli aggiornamenti automatici del client dalle impostazioni della tailnet: per un componente così esposto lo ritengo ragionevole, almeno sui client.

Se non potete aggiornare subito

Tailscale indica una mitigazione temporanea che disattiva l’inoltro delle connessioni senza spegnere Tailscale SSH: impostare la variabile TS_SSH_DISABLE_FORWARDING=1 nell’ambiente del servizio tailscaled e riavviarlo. Su una distribuzione con systemd il modo più pulito è un file di override, che non viene toccato dagli aggiornamenti del pacchetto:

1. Create la cartella dell’override e il file con la variabile:

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/no-forwarding.conf

2. Ricaricate la configurazione e riavviate il servizio:

sudo systemctl daemon-reload
sudo systemctl restart tailscaled
systemctl show tailscaled --property=Environment

3. Verificate da un altro nodo che ssh mario.rossi@SRV01 funzioni ancora e che un inoltro come ssh -L 8080:localhost:80 mario.rossi@SRV01 non funzioni più: il client si collega, ma l’apertura del canale inoltrato fallisce.

La modifica è reversibile: dopo l’aggiornamento, se l’inoltro vi serve, cancellate il file no-forwarding.conf e ripetete daemon-reload e riavvio. Se invece Tailscale SSH su quel server non lo usate davvero, la scelta più semplice è spegnerlo del tutto con sudo tailscale set --ssh=false, dopo esservi assicurati di avere un accesso SSH tradizionale funzionante.

Attenzione: questa mitigazione copre l’inoltro di Tailscale SSH, non i problemi di Serve (TS-2026-016 e TS-2026-017) né il consumo di memoria (TS-2026-015). Per quelli l’unica soluzione è l’aggiornamento.

Rivedere le policy SSH

Tailscale non consiglia di disattivare Tailscale SSH ovunque, ma di limitare le regole ai soli utenti e dispositivi che ne hanno bisogno. È l’occasione per fare pulizia nella sezione ssh del file di policy della tailnet: niente regole generiche verso autogroup:member per i server di produzione, e per i sistemi più delicati usate la modalità check, che chiede una nuova autenticazione prima di concedere l’accesso:

"ssh": [
  {
    "action": "check",
    "src":    ["group:sistemisti"],
    "dst":    ["tag:server"],
    "users":  ["mario.rossi"]
  }
]

Prima di salvare, usate l’anteprima delle regole della console per controllare chi perde l’accesso: una policy troppo stretta applicata di venerdì sera è un classico modo per restare chiusi fuori.

Se il problema persiste

Se un nodo resta sotto la 1.104.4 perché il pacchetto del vostro canale non è ancora uscito, lasciate attiva la mitigazione e restringete al minimo le regole SSH verso quel nodo. Se usate headscale come server di controllo self-hosted, tenete d’occhio anche i suoi rilasci: i ricercatori hanno segnalato problemi pure lato headscale, dove l’inoltro risulta concesso in automatico. Infine, se sospettate che un dispositivo della tailnet sia compromesso, rimuovetelo dalla console e controllate gli accessi SSH recenti sui server che poteva raggiungere.

Vi è capitato di dover aggiornare in fretta Tailscale su server raggiungibili solo dalla tailnet? Raccontate nei commenti come vi siete organizzati: possono essere utili ad altri.