Tailscale corregge due falle: CPU bloccata e accesso root via SSH

Tailscale è una soluzione per creare reti private cifrate tra computer, server, smartphone e altri dispositivi, senza dover configurare manualmente una VPN tradizionale. Basato sul protocollo WireGuard, il servizio assegna a ogni nodo un’identità e consente di stabilire collegamenti diretti regolati da policy di accesso centralizzate. Accanto alla connettività privata, Tailscale offre anche funzioni come Serve, Funnel e Tailscale SSH, pensate rispettivamente per pubblicare servizi locali, renderli accessibili da Internet e gestire sessioni SSH attraverso le identità della rete.

Proprio due di queste funzioni sono al centro dei bollettini TS-2026-008 e TS-2026-009, pubblicati da Tailscale intorno alla metà di luglio 2026.

Le vulnerabilità, corrette con il rilascio di Tailscale 1.98.9, permettevano in un caso di occupare indefinitamente un core della CPU con una sola richiesta HTTP malformata; nell’altro, di trasformare un accesso SSH autorizzato ma limitato in una sessione root su un sistema Linux.

Perché Tailscale Serve e Funnel ampliano la superficie HTTP

Tailscale (abbiamo visto come creare una VPN distribuita) costruisce reti private cifrate, chiamate tailnet, collegando direttamente dispositivi e utenti attraverso WireGuard.

Alcune funzioni del client, però, vanno oltre il semplice trasporto dei pacchetti. Tailscale Serve permette di pubblicare un servizio locale, una directory o una porta verso gli altri nodi autorizzati della tailnet. Un’applicazione in ascolto su 127.0.0.1:3000, per esempio, può diventare raggiungibile tramite un indirizzo HTTPS associato.

Tailscale Funnel estende lo stesso modello all’esterno: il servizio locale può ricevere connessioni dalla rete Internet. Serve continua ad applicare le regole di accesso della tailnet; Funnel offre invece un punto di ingresso pubblico e non richiede che il visitatore possieda un’identità Tailscale.

Entrambe le funzioni operano come proxy verso un backend locale: quando arriva una richiesta HTTP, il software deve stabilire quale configurazione applicare confrontando il percorso richiesto con i mount point definiti dall’amministratore. Si potrebbe associare / a un server web, /api a un secondo processo e /static a una directory.

Una richiesta HTTP malformata poteva saturare la CPU

La vulnerabilità TS-2026-008 nasceva nella procedura usata da Tailscale Serve e Funnel per individuare il gestore associato a una richiesta HTTP. Il software risaliva il percorso una directory alla volta, aspettandosi di raggiungere prima o poi la radice /.

Il meccanismo funzionava però soltanto con percorsi assoluti, cioè preceduti dallo slash iniziale: una richiesta malformata con un percorso relativo non raggiungeva mai la condizione di arresto e lasciava la routine intrappolata in un ciclo infinito.

Come confermato da Tailscale, un singolo input poteva mantenere un core logico al 100% per tutta la durata del processo. Su un sistema multicore il nodo poteva continuare a funzionare grazie agli altri core, almeno in un primo momento, ma ulteriori richieste costruite allo stesso modo rischiavano di sottrarre progressivamente capacità di calcolo, rallentando sia il proxy sia gli altri servizi presenti sulla macchina. L’assenza di un timeout capace di interrompere l’elaborazione rendeva persistente il consumo di risorse.

La superficie d’attacco dipendeva poi dalla funzione utilizzata: con Serve la richiesta doveva provenire da un peer autorizzato a raggiungere il nodo attraverso la tailnet, mentre con Funnel poteva arrivare da qualsiasi host su Internet, senza autenticazione. Il rischio risultava particolarmente concreto su VPS di piccole dimensioni, NAS, Raspberry Pi e server domestici, dove anche la perdita permanente di un solo core può degradare sensibilmente webhook, pannelli amministrativi, strumenti di sviluppo e applicazioni pubblicate tramite Funnel.

La seconda falla nasce dal passaggio di un nome utente a Linux

TS-2026-009 segue una dinamica completamente diversa e riguarda soltanto Tailscale SSH su Linux.

La funzione consente di autenticare gli utenti attraverso Tailscale e di applicare regole che stabiliscono chi può collegarsi a un nodo e con quale account locale. L’amministratore può, per esempio, autorizzare alcuni membri della tailnet ad aprire una sessione come utenti non privilegiati, senza distribuire chiavi SSH tradizionali.

Prima della correzione, il software accettava anche nomi utente che iniziavano con il carattere “-“. Su Linux, il valore veniva poi passato al comando getent, usato per interrogare i database gestiti dal Name Service Switch. Tra questi database rientra passwd, che contiene le informazioni sugli account locali e può integrare fonti esterne configurate attraverso /etc/nsswitch.conf.

Usando -i come nome utente, il comando getent enumera tutte le voci: nel caso di passwd, la prima riga restituita corrisponde normalmente all’account root, che usa UID 0.

Tailscale interpretava quella prima voce come il risultato della ricerca dell’utente richiesto e apriva una sessione interattiva associata a root. Non serviva conoscere la password dell’amministratore locale, né sfruttare una vulnerabilità del kernel. Bastava collegarsi tramite Tailscale SSH specificando -i come username.

Non si parla, in senso stretto, di una shell ottenibile da chiunque su Internet: l’attaccante doveva già possedere il diritto di aprire una sessione SSH verso il nodo.

Non è la classica command injection, ma il rischio è analogo

Le installazioni esposte erano quelle Linux che utilizzavano Tailscale SSH e facevano affidamento sulla restrizione autogroup:nonroot. Tale selettore permette a una regola SSH di riferirsi agli utenti locali diversi da root. Nella configurazione predefinita, Tailscale può combinarlo con autogroup:self per consentire agli utenti di collegarsi ai propri dispositivi senza autorizzare direttamente sessioni amministrative.

La vulnerabilità ricorda una command injection, anche se la descrizione pubblica non indica l’esecuzione attraverso una shell con metacaratteri come “;”, “|” o “$()”. L’attaccante non aggiungeva un nuovo comando: manipolava gli argomenti di getent affinché un valore venisse trattato come opzione.

La categoria più precisa in cui ricade la seconda falla corretta da Tailscale è argument injection o gestione insicura degli argomenti della riga di comando. Tailscale ha scelto una correzione netta: Tailscale SSH rifiuta ora gli username con il trattino iniziale.

Gli amministratori devono controllare la versione installata sui nodi che eseguono Serve, Funnel o Tailscale SSH. Il comando tailscale version mostra la release del client; sulle distribuzioni Linux conviene verificare anche la versione del pacchetto registrata dal package manager, soprattutto quando gli aggiornamenti seguono repository aziendali, mirror interni o finestre di manutenzione ritardate.

La soluzione indicata dal produttore consiste nell’aggiornamento a Tailscale 1.98.9 o a una release successiva. Non basta aggiornare la console di amministrazione o un singolo endpoint: la patch deve raggiungere ogni nodo che espone le funzioni vulnerabili.