O singură stație compromisă într-o rețea Tailscale ar putea deveni punctul de plecare pentru acces root pe alte servere la care are voie să se conecteze, potrivit unui raport publicat pe 25 octombrie de cercetătoarea Erica Windisch. Constatările provin din teste de laborator, nu din atacuri confirmate asupra unor rețele reale, iar Tailscale nu publicase încă un patch sau un buletin de securitate.
Raportul, numit Tailworm și realizat de Windisch, de la Cyberdione Labs, analizează Tailscale 1.104.2 și headscale 0.29.5, o alternativă găzduită de organizații pe propriile servere. Cercetătoarea a petrecut trei zile testând aceste versiuni într-un mediu controlat; rezultatele nu demonstrează, de unele singure, că rețele de producție au fost compromise.
Lanțul de atac descris are două condiții: Tailscale SSH trebuie să permită redirecționarea porturilor, iar atacatorul trebuie să controleze deja un dispozitiv pe care regulile de acces îl autorizează să ajungă la țintă. Tailscale nu oferă, prin aceste vulnerabilități, accesul inițial; acesta ar putea proveni, de exemplu, dintr-o aplicație web vulnerabilă, un pachet software compromis, phishing sau furtul datelor de autentificare.
O sesiune SSH obișnuită, cu consecințe de administrator
Tailscale SSH funcționează diferit față de un server SSH convențional: nu verifică parola sau cheia utilizatorului care se conectează, ci identitatea dispozitivului, iar o regulă de acces stabilește dacă acel dispozitiv poate deschide o sesiune către țintă. În scenariul descris, asta înseamnă că atacatorul nu are nevoie să fure parola ori cheia SSH a administratorului.
În primul test, Windisch a folosit redirecționarea standard de porturi SSH. O sesiune obișnuită a determinat procesul Tailscale, care rulează cu privilegii root, să se conecteze la un socket de sistem rezervat root; cercetătoarea a obținut astfel privilegii administrative și a putut citi fișierul cu parolele sistemului, aproape imediat și fără drepturi de administrator inițiale.
O a doua metodă a înlocuit un socket deținut de root cu unul controlat de atacator, ceea ce a permis executarea directă de comenzi cu privilegii root împotriva anumitor servicii. A treia metodă a exploatat o verificare de siguranță destinată să limiteze fișierele accesibile prin redirecționare, folosind o cursă între momentul verificării căii și cel al accesării fișierului.
De la escaladare locală la propagare prin rețea
În laborator, această ultimă secvență a mers mai departe: a capturat o cheie folosită la înrolarea unor dispozitive noi și a utilizat-o pentru a adăuga în rețea mașina atacatorului, prezentată drept server de încredere. Etapa finală a reușit integral numai în rețele fără Tailnet Lock, funcția care protejează procesul de autorizare a dispozitivelor.
În rețelele cu Tailnet Lock activat, raportul spune că secretele necesare au fost totuși capturate în tranzit, dar cercetătoarea nu a finalizat pasul de înrolare. Windisch a descris rezultatul general drept „wormable”: în laborator, un singur dispozitiv compromis putea ajunge la toate celelalte dispozitive permise de regulile de acces, fără parole furate, chei sustrase sau acțiuni suplimentare ale utilizatorilor.
Ritmul propagării raportat a fost de sub o secundă pentru fiecare pas, nu o măsurătoare făcută într-o rețea reală. Raportul rezumă miza astfel: „mesh-ul transformă un punct de sprijin obișnuit în acces privilegiat la nivelul întregii flote, cu viteza mașinii”.
Unii cercetători au contestat public eticheta „wormable”, în timp ce alții au considerat gravă escaladarea la root.
Ce știm despre remediere și limitele raportului
La data publicării, Tailscale nu anunțase un identificator CVE, un buletin de securitate sau o versiune corectată. Mike Shaver, vicepreședintele pentru inginerie al companiei, a scris pe Reddit că Tailscale primise raportul, analiza deja zone similare împreună cu specialiști externi și lucra la remedierea unor probleme; compania încă stabilea configurațiile afectate.
Shaver a precizat că Tailscale „nu recomandă ca toată lumea să dezactiveze Tailscale SSH”. Totuși, constatările tehnice specifice nu au fost confirmate public de companie și nu au fost reproduse public de un alt cercetător; Windisch spune că dovada de concept nu este publică și că a transmis-o numai contactului de securitate al Tailscale.
Dezvăluirea a stârnit și o dispută privind coordonarea. Windisch a numit-o „raportată, dar necoordonată” într-o postare pe Y Combinator Hacker News, unde un comentator a criticat publicarea înaintea raportării către companie; ulterior, ea a declarat pentru The Hacker News că trimisese raportul și codul de test către contactul de securitate al Tailscale în sâmbăta dinaintea publicării.
Riscul pentru organizațiile din România și UE
Pentru companiile și instituțiile din România sau din restul UE care folosesc Tailscale pentru acces la servere, problema trebuie tratată ca un risc de configurare și de extindere a unui incident inițial, nu ca dovada unei compromiteri generalizate. O stație de lucru afectată ar putea deveni o cale către servere, dar numai dacă regulile și opțiunile SSH relevante permit lanțul descris.
Diferența dintre serviciul găzduit Tailscale și headscale este importantă: în serviciul companiei, redirecționarea poate fi dezactivată separat pentru fiecare regulă; în headscale 0.29.5, raportul spune că această opțiune nu poate fi dezactivată. Windisch recomandă ca fiecare acord SSH din acea versiune headscale să fie tratat, din perspectiva riscului, ca și cum ar putea oferi acces root asupra țintei.
Organizațiile ar trebui să inventarieze regulile și dispozitivele, să verifice dacă au activat Tailnet Lock și să prioritizeze sistemele care gestionează date sensibile sau servicii critice. În paralel, echipele de securitate pot monitoriza dispozitivele autorizate, conexiunile SSH și modificările neobișnuite ale regulilor, fără a presupune că activarea Tailnet Lock, singură, elimină vulnerabilitatea descrisă.
Raportul Tailworm include 11 constatări, nu doar problema SSH: sunt analizate și app connectors, funcția Serve, releul DERP folosit între dispozitive și headscale. Windisch a spus că escaladarea SSH este îngrijorătoare, dar că o constatare privind funcția experimentală conn25 ar putea avea efecte mai importante pentru unele organizații.
În conn25, potrivit raportului, un utilizator autorizat ar putea trimite trafic către destinații pe care echipa de securitate nu le-a aprobat, inclusiv serviciul de metadate al unui furnizor cloud. Astfel de servicii pot furniza acreditări ale serverelor, ceea ce face ca această problemă să merite evaluată separat, chiar dacă nu este aceeași vulnerabilitate ca escaladarea prin SSH.
Măsuri imediate, fără a aștepta un patch
Raportul recomandă reguli de acces definite ca perechi individuale sursă–destinație, care numesc un singur dispozitiv și o singură țintă, în locul permisiunilor largi acordate pe baza identității sau a etichetelor. Potrivit testelor, această limitare a oprit propagarea; acolo unde serviciul permite, administratorii ar trebui să dezactiveze și redirecționarea porturilor SSH.
Organizațiile ar trebui să retragă permisiunile pentru app connectors de pe dispozitivele care nu au nevoie de ele și să elimine orice regulă Tailscale Serve care redirecționează către un socket Unix. Activarea expirării cheilor dispozitivelor poate limita perioada în care o cheie furată rămâne validă, dar nu înlocuiește revocarea ei după un incident.
Dacă un dispozitiv este compromis, recomandarea este eliminarea lui din planul de control Tailscale; reinstalarea sistemului de operare nu invalidează cheile pe care atacatorul le-ar fi putut copia. Tailscale recomandă și SSH check mode, care adaugă o etapă de autentificare înaintea sesiunii, precum și actualizările automate; check mode adaugă o barieră, dar nu remediază escaladarea de privilegii.
Raportul apare după ce, la începutul lui 2026, Tailscale a remediat mai multe probleme legate de SSH și gestionarea socketurilor serverului, inclusiv o vulnerabilitate prin care redirecționarea unui socket Unix SSH putea ajunge la un socket privilegiat; corecția a fost inclusă în versiunea 1.98.9. Până la clarificarea configurațiilor afectate și publicarea unor remedieri, măsurile de limitare a accesului rămân esențiale.
