Indice dell'articolo
Rischio e azione: chi usa Tailscale SSH o Tailscale Serve deve inventariare oggi le configurazioni attive e aggiornare i nodi alla versione 1.104.4 o successiva. La release corregge quattro vulnerabilità che, in condizioni specifiche, possono esporre socket privilegiati, causare il crash di tailscaled o applicare capability errate tra servizi pubblicati. Non è una falla che permette a un attaccante Internet non autenticato di entrare in qualsiasi tailnet: servono già un dispositivo autorizzato, una sessione consentita dalla policy oppure accesso locale alla configurazione interessata.
Che cosa corregge Tailscale 1.104.4
Nel resoconto tecnico del 28 ottobre, Tailscale spiega che i problemi principali riguardano l’applicazione dei privilegi dopo l’autorizzazione della connessione. Il changelog della versione 1.104.4 collega la release a quattro bollettini.
TS-2026-014 interessa il forwarding di socket Unix in Tailscale SSH. Alcune operazioni venivano eseguite dal processo tailscaled con privilegi root, consentendo a un peer autenticato e autorizzato al forwarding di raggiungere socket riservati, tra cui il socket Docker o l’API locale di Tailscale. Sono esposti i nodi con Tailscale SSH attivo e forwarding locale o remoto consentito.
TS-2026-015 riguarda la gestione della memoria nelle sessioni SSH. Un peer autenticato può inviare messaggi e variabili in modo da far crescere la memoria senza un limite adeguato. L’esito possibile è un OOM kill di tailscaled, con interruzione di tutte le connessioni Tailscale del nodo.
TS-2026-016 interessa Tailscale Serve con backend su socket Unix. In alcune configurazioni il proxy poteva raggiungere socket privilegiati, inclusa l’API locale di tailscaled. Il rischio riguarda soprattutto nodi dove un operatore locale può modificare la configurazione Serve o i percorsi dei backend.
TS-2026-017 riguarda Serve con TLS, almeno due mount con requisiti di capability differenti e flussi HTTP/2 concorrenti. Una condizione di race poteva associare a una richiesta le capability destinate a un altro mount, inducendo l’applicazione a prendere una decisione di autorizzazione errata. I dettagli e i prerequisiti sono nei bollettini di sicurezza Tailscale.
Prerequisiti e limiti dell’impatto
La distinzione operativa è importante. Per le vulnerabilità SSH serve già un peer autorizzato nel tailnet, con accesso Tailscale SSH permesso dalla policy. Per Serve servono configurazioni specifiche: backend Unix modificabili oppure Serve TLS con più mount e capability differenti. Tailscale precisa inoltre che gli app connector stabili non sono coinvolti; il problema segnalato su Conn25 riguarda una funzione ancora in pre-produzione.
Questo riduce l’esposizione rispetto a una RCE remota non autenticata, ma non rende il problema trascurabile. Un account, un endpoint o una chiave già compromessi possono trasformare un accesso legittimo limitato in movimento laterale, accesso a socket root o indisponibilità del nodo.
Patching o incident response?
Se non ci sono anomalie, trattate l’attività come vulnerability management: inventario, backup della configurazione, aggiornamento, collaudo e monitoraggio. Se non potete aggiornare subito, per TS-2026-014 Tailscale indica una mitigazione temporanea: impostare TS_SSH_DISABLE_FORWARDING=1 nell’ambiente del servizio tailscaled e riavviarlo. La mitigazione disattiva il forwarding SSH, non l’intero Tailscale SSH.
Passate a incident response se trovate peer inattesi nel tailnet, modifiche non autorizzate alle policy, forwarding o configurazioni Serve sconosciute, riavvii/OOM anomali di tailscaled, accessi sospetti al socket Docker o all’API locale. Prima della bonifica preservate log, configurazioni, cronologia delle modifiche e informazioni sui nodi coinvolti. Installare la patch chiude le vulnerabilità note, ma non dimostra che un sistema fosse integro prima dell’aggiornamento.
Checklist operativa
- Aprire la pagina Machines e filtrare i dispositivi con aggiornamenti disponibili; verificare la versione anche su server, appliance NAS e container.
- Identificare i nodi con Tailscale SSH, forwarding locale o remoto, Serve TLS, più mount o backend su socket Unix.
- Salvare policy, configurazioni Serve e impostazioni del servizio prima della modifica.
- Applicare la mitigazione sul forwarding dove l’upgrade immediato non è possibile.
- Aggiornare a 1.104.4 o successiva. Per i container, usare l’immagine stabile e ridistribuire il workload: l’auto-update interno non sostituisce una strategia di immutabilità.
- Non attendere passivamente l’aggiornamento automatico: Tailscale avverte che il rollout può non essere immediato, anche se le correzioni di sicurezza possono essere accelerate.
- Dopo l’upgrade, verificare connettività del tailnet, accessi SSH con l’utente previsto, modalità
check, forwarding autorizzato, backend Serve, log e stabilità di memoria del processo. - Documentare versione iniziale e finale, nodi esclusi, test eseguiti e azioni residue.
Devi verificare rapidamente nodi, policy e dipendenze Tailscale prima della finestra di aggiornamento? Richiedi una verifica tecnica a MSP In Cloud.