Vulnerabilități necorectate în Tailscale SSH transformă un dispozitiv compromis în acces root pe vecinii săi

O evaluare de laborator publicată pe 25 octombrie 2026 descrie un lanț de slăbiciuni în Tailscale SSH care, în anumite condiții, permite unui atacator ce controlează deja un nod dintr-un tailnet să obțină root pe toate celelalte noduri la care acel nod are acces. La momentul redactării nu există CVE, buletin de securitate sau versiune corectată, ceea ce înseamnă că echipele de apărare trebuie să se bazeze pe configurare, nu pe actualizări.

Ce s-a întâmplat

Evaluarea a testat Tailscale 1.104.2 și headscale 0.29.5, alternativa self-hosted la serviciul de coordonare al Tailscale, timp de trei zile într-un laborator controlat. Au fost vizate exclusiv versiuni publice ale software-ului. Nu a fost atinsă nicio rețea de producție, iar codul de tip proof-of-concept a fost transmis în privat către Tailscale, nu publicat.

Problema centrală ține de modul în care Tailscale SSH gestionează redirecționarea de porturi. Tailscale SSH nu autentifică utilizatorul prin parolă sau cheie. Identifică dispozitivul care se conectează și lasă o singură regulă de acces să decidă dacă acel dispozitiv poate deschide o sesiune pe țintă. Dacă regula permite și port forwarding, trei tehnici distincte au fost demonstrate pentru a escalada o sesiune obișnuită la root:

Redirecționare locală de socket Unix. Daemonul Tailscale rulează ca root. Redirecționarea unui socket Unix prin el a făcut daemonul să se conecteze la socket-uri pe care doar root ar trebui să le poată deschide, iar testul a citit fișierul de parole al sistemului aproape instantaneu, fără niciun drept de administrator.
Redirecționare inversă de socket. Un socket deținut de root a fost înlocuit cu unul controlat de atacator, permițând execuția de comenzi cu drepturi de root asupra anumitor servicii care au încredere în acel socket.
O condiție de cursă de tip time-of-check / time-of-use. O verificare de siguranță menită să limiteze căile de fișiere accesibile prin redirecționare a fost ocolită prin exploatarea intervalului dintre momentul validării căii și momentul utilizării ei.

În laborator, a treia tehnică a mers mai departe. A capturat o cheie folosită la înrolarea dispozitivelor noi și a utilizat-o pentru a alătura rețelei o mașină controlată de atacator, ca server de încredere. Acest ultim pas a funcționat complet doar în rețelele fără Tailnet Lock. Acolo unde Tailnet Lock era activ, secretele au fost totuși capturate în tranzit, dar înrolarea a eșuat.

Raportul descrie rezultatul drept „wormable”: un singur dispozitiv compromis s-ar putea răspândi către toți vecinii permiși de regulile de acces, fără parole, fără chei furate și fără interacțiune din partea utilizatorului, în mai puțin de o secundă per salt. Afirmația a fost contestată public de unii specialiști, în timp ce alții consideră constatarea privind accesul root serioasă în sine. Este important să fim preciși. Răspândirea a fost demonstrată în laborator, nu a fost reprodusă de nicio terță parte, iar Tailscale nu a confirmat afirmațiile tehnice specifice.

Lanțul SSH este una dintre cele 11 constatări ale aceleiași evaluări. Celelalte acoperă conectorii de aplicații Tailscale, funcția serve, releul DERP și headscale. Una dintre ele vizează modul experimental conn25 al conectorilor de aplicații, în care un utilizator autorizat ar putea direcționa trafic către destinații neaprobate de echipa de securitate, inclusiv endpoint-ul de metadate al unui furnizor cloud, care emite credențiale de server.

Poziția Tailscale

Tailscale a răspuns public. Vicepreședintele său pentru inginerie a declarat că firma a primit raportul, analiza deja aceleași zone de cod împreună cu specialiști externi și a identificat probleme pe care le corectează acum. Compania încă stabilește ce configurații sunt afectate și nu recomandă în mod explicit ca toată lumea să dezactiveze Tailscale SSH.

Dezvăluirea a fost descrisă de autoarea sa drept „raportată, dar necoordonată”. Raportul și codul proof-of-concept au fost trimise contactului de securitate al Tailscale înainte de publicare, iar un hash al fișierului a fost postat public împreună cu recomandarea de a dezactiva Tailscale SSH. Nu este prima problemă în această zonă a produsului. Mai devreme în 2026, Tailscale a corectat mai multe erori legate de SSH și de gestionarea socket-urilor, inclusiv una în care redirecționarea de socket-uri Unix putea atinge un socket privilegiat, în versiunea 1.98.9.

De ce contează

Tailscale este adesea implementat tocmai pentru a înlocui VPN-urile plate cu acces bazat pe identitate și pe principiul privilegiului minim. Punctul slab descris aici nu este tunelul WireGuard, ci modelul de încredere din jurul SSH: dispozitivul este identitatea, iar redirecționarea rulează într-un proces root. Asta înseamnă că primul punct de sprijin al atacatorului, obținut pe căile obișnuite printr-o aplicație web vulnerabilă, un pachet otrăvit, phishing sau credențiale furate, devine singura parte dificilă. Tot ce urmează se bazează pe regulile de acces ale rețelei mesh.

Două lucruri au oprit lanțul în teste, și ambele sunt sub controlul administratorului chiar acum:

Reguli de acces scrise ca perechi sursă-destinație individuale, care numesc un dispozitiv și o țintă, în locul permisiunilor largi acordate după identitate sau tag.
Chei de dispozitiv legate de hardware precum un TPM sau Secure Enclave, care nu pot fi pur și simplu copiate de pe un host compromis.

Acolo unde planul de control este self-hosted, marja este mai mică. Pe serviciul găzduit de Tailscale, port forwarding poate fi dezactivat per regulă. Pe headscale 0.29.5 nu poate fi dezactivat deloc, așa că fiecare permisiune SSH de acolo ar trebui tratată ca echivalentul accesului root pe țintă.

Ce este de făcut acum

Pentru că nu există un patch, măsurile de atenuare sunt modificări de configurare. Recomandările Tailscale și cele din raport se suprapun în mare parte:

Rescrieți regulile de acces SSH ca perechi explicite. Eliminați regulile largi care acordă SSH după identitate sau tag. Regulile per pereche au fost singurul control care a limitat răspândirea în teste.
Dezactivați port forwarding pentru SSH oriunde este posibil. Pe serviciul găzduit este o setare per regulă. Pe headscale 0.29.5 nu este disponibilă, așa că presupuneți root pentru fiecare permisiune.
Eliminați permisiunile de app connector de pe dispozitivele care nu au nevoie de ele și revizuiți orice utilizare a modului experimental conn25.
Ștergeți orice redirecționare tailscale serve care indică spre un socket Unix.
Activați expirarea cheilor de nod, astfel încât o cheie furată să nu rămână valabilă la nesfârșit.
Dacă un dispozitiv este compromis, ștergeți-l din planul de control. Reinstalarea mașinii nu revocă cheile pe care atacatorul le-a copiat deja.
Activați SSH check mode și actualizările automate. Check mode adaugă un pas de autentificare înainte de pornirea sesiunii. Nu rezolvă escaladarea de privilegii, dar este încă o barieră în fața ei.

Lecția mai largă este că securitatea unei rețele mesh este exact atât de puternică cât accesibilitatea permisă de regulile sale. Presupunerea că mișcarea laterală este dificilă odată ce un dispozitiv este „înăuntrul” tailnet-ului nu se confirmă aici. Angajamentele noastre de penetration testing sunt construite exact în jurul acestei întrebări: pornind de la un singur host considerat compromis, cât de departe poate ajunge efectiv un atacator prin regulile de acces, setările de redirecționare și relațiile de încredere înainte ca ceva să-l oprească? A afla răspunsul înaintea unui intrus real este ceea ce transformă o revizuire de configurare într-un control pe care te poți baza.