Egyetlen feltört eszköz egy Tailscale hálózaton elég lehet ahhoz, hogy a támadó root hozzáférést szerezzen más, általa elérhető szervereken – erre jutott egy biztonsági kutató, aki a héten hozta nyilvánosságra az eredményeit.

A támadáshoz két feltétel kell: olyan Tailscale SSH, ahol engedélyezték a porttovábbítást, és egy támadó, aki már irányít egy olyan eszközt, amelyet a hálózat hozzáférési szabályai engednek kapcsolódni a célgéphez.

Az eredményeket október 25-én tették közzé Tailworm címmel, a Cyberdione Labsnél dolgozó Erica Windisch jelentésében. Windisch három napon át laborban tesztelte a Tailscale 1.104.2-es verzióját és a headscale 0.29.5-öt, azt az önhostolt szervert, amelyet egyes hálózatok a Tailscale cég által üzemeltetett szolgáltatás helyett használnak.

A jelentés ezeknek a szoftvereknek a tesztjeit írja le, nem valódi hálózatok elleni támadásokat. A cikk megjelenéséig a Tailscale nem adott ki biztonsági közleményt, nem kért CVE azonosítót, és nincs javított verzió sem.

A Tailscale nyilvánosan reagált. Mike Shaver, a cég mérnöki alelnöke a Redditen írta, hogy megkapták a jelentést, már korábban is vizsgálták ugyanezeket a területeket külső biztonsági szakértőkkel, és találtak problémákat, amelyeken dolgoznak. Shaver szerint még mindig azt térképezik fel, pontosan mely konfigurációk érintettek, és „nem javasolják, hogy mindenki kapcsolja ki a Tailscale SSH-t”.

A Tailscale SSH nem úgy működik, mint egy hagyományos SSH szerver. Nem a csatlakozó felhasználó jelszavát vagy kulcsát ellenőrzi, hanem az eszközt azonosítja, és egyetlen hozzáférési szabály dönti el, hogy az adott eszköz nyithat-e SSH kapcsolatot a célhoz.

Emiatt a támadáshoz nem kell ellopott jelszó vagy kulcs. Először azonban meg kell szerezni az irányítást egy eszköz felett, amit a jelentés szerint a szokásos módszerekkel lehet elérni: sérülékeny webalkalmazással, fertőzött szoftvercsomaggal, adathalászattal vagy ellopott bejelentkezési adatokkal. Az első betörési pontot nem a Tailscale hozza létre.

Hogy az adminisztrátor mit tehet ellene, attól függ, hol fut a hálózat. A Tailscale által üzemeltetett szolgáltatásban szabályonként ki lehet kapcsolni a továbbítást. A headscale 0.29.5-ös verziójában viszont egyáltalán nem lehet letiltani. A jelentés szerint ezért ott minden SSH jogosultságot úgy kell kezelni, mintha root hozzáférést adna a célgépen.

Laborban Windisch lépésről lépésre mutatta be a problémát. Szabványos SSH porttovábbítással egy egyszerű munkamenet rá tudta venni a root jogosultsággal futó Tailscale folyamatot, hogy kapcsolódjon egy olyan rendszer sockethez, amelyet elvileg csak a root érhet el. A teszt így szinte azonnal root jogot szerzett, és rendszergazdai jogosultság nélkül olvasta ki a rendszer jelszófájlját.

A második módszer egy root tulajdonában lévő socketet cserélt le a támadóéra, így bizonyos szolgáltatások ellen közvetlen root parancsvégrehajtást tett lehetővé.

A harmadik módszer egy biztonsági ellenőrzést játszott ki, amelynek az lett volna a feladata, hogy korlátozza, milyen fájlokhoz férhet hozzá az SSH porttovábbítás. A támadás versenyhelyzetet teremt a rendszerben a fájlútvonal ellenőrzése és a tényleges használata között. A jelentés szerint a laborban ezt a láncot tovább is vitték: sikerült megszerezni egy kulcsot, amellyel új eszközöket lehet regisztrálni, majd ezzel a kulccsal a támadó saját gépét is felvették a hálózatba, megbízható szerverként.

Ez az utolsó lépés elejétől a végéig csak olyan hálózatokon működött, ahol nem kapcsolták be a Tailscale Tailnet Lock funkcióját. Ahol igen, ott ugyan sikerült útközben elfogni a szükséges titkokat, de a végső lépés már nem futott le.

Windisch az egész eredményt „féregszerűen terjedőnek” írja le. A laborban egyetlen feltört eszköz minden olyan gépre tovább tudott terjedni, amelyhez a hozzáférési szabályok engedélyt adtak – jelszavak, ellopott kulcsok és felhasználói beavatkozás nélkül, lépésenként kevesebb mint egy másodperc alatt.

A jelentés megfogalmazása szerint „a mesh hálózat egy átlagos lábnyomból flottaszintű, kiemelt jogosultságú hozzáférést csinál gépi sebességgel”. Ezt a terjedést laborban mérték, nem valós hálózatokon figyelték meg.

A jelentés két tényezőt nevez meg, ami korlátozta a terjedést: az egy-egy forrás–cél párra írt hozzáférési szabályokat, amelyek önmagukban megállították a láncot, illetve azokat az eszközkulcsokat, amelyeket hardverhez – például TPM-hez vagy Secure Enclave-hez – kötöttek.

Néhány kutató, aki elolvasta a jelentést, nyilvánosan megkérdőjelezte a „féregszerűen terjedő” jelzőt, mások viszont komolyan vették a root hozzáférésre vonatkozó megállapítást.

Az SSH-probléma a jelentés 11 megállapításának egyike. A dokumentum foglalkozik még a Tailscale app connectoraival, a serve funkcióval, az eszközök között használt DERP relay-jel és a headscale-lel is. Windisch a The Hacker Newsnak azt mondta, hogy az SSH jogosultságkiterjesztés „aggasztó”, de az app connectorral kapcsolatos megállapítás „egyes szervezeteknél nagyobb hatású lehet”. Utóbbi egy conn25 nevű, kísérleti funkciót érint, és lehetővé teszi, hogy egy engedélyezett felhasználó olyan célpontok felé is forgalmat küldjön, amelyeket a biztonsági csapat soha nem hagyott jóvá – köztük felhős szolgáltatók metadata szolgáltatását, amely szerverhozzáférési adatokhoz juttathatja a támadót.

Az összes megállapítás kizárólag Windisch jelentésére épül. Más kutató nyilvánosan még nem reprodukálta őket, és a Tailscale sem erősítette meg a konkrét technikai állításokat. Windisch elmondta, hogy a bizonyítékként szolgáló proof-of-concept kód nem nyilvános, azt csak a Tailscale security kapcsolattartójának adta át.

Windisch a közzétételt úgy jellemezte, hogy „bejelentett, de nem egyeztetett”, erről a Ycombinator HN-en is írt. Ott legalább egy hozzászóló felelőtlennek nevezte, hogy a kutató a Tailscale előzetes értesítése nélkül hozta nyilvánosságra a részleteket.

A The Hacker News kérdésére Windisch elmondta, hogy a nyilvános bejegyzés előtt tényleg elküldte a Tailscale-nek a jelentés egy példányát és a proof-of-concept kódot is, még az előző szombaton, a cég security kapcsolattartójának címezve. Azt is hozzátette, hogy korábban már jelezte a Tailscale architektúrájával kapcsolatos aggályait a cég vezérigazgatójának, nyilvánosan közzétett egy fájl hash-t, és azt tanácsolta a felhasználóknak, hogy kapcsolják ki a Tailscale SSH-t.

A jelentés egy újabb epizód ugyanabban a Tailscale-komponensben felbukkanó problémák sorában. 2026 elején a cég több Tailscale SSH- és szerver socket-kezelési hibát is javított, köztük egy olyat is, amelyben a SSH Unix socket forwarding elérhetett egy privilégizált socketet, a 1.98.9-es verzióban.

Mit érdemes most tenni

Mivel nincs javítócsomag, jelenleg csak a Tailscale SSH és a kapcsolódó funkciók beállításain lehet változtatni. A jelentés és a Tailscale saját javaslatai nagyrészt egybeesnek.

• Nézd át a Tailscale SSH hozzáférési szabályokat. Úgy írd meg őket, hogy egy-egy konkrét forrás–cél párt fedjenek le, egy eszközt és egy célpontot megnevezve, és töröld azokat az általános szabályokat, amelyek pusztán identitás vagy tag alapján adnak hozzáférést. A jelentés szerint a páronkénti szabályok voltak az egyetlen kontroll, amely a tesztekben megállította a terjedést.
• Kapcsold ki az SSH port forwardingot, ahol csak lehet. A Tailscale hosztolt szolgáltatásában ez szabályonként állítható. A headscale 0.29.5-ös verziójában nem lehet kikapcsolni, ezért ott minden SSH jogosultságot úgy kell kezelni, mintha root hozzáférést adna a célgépen.
• Vond vissza az app connector jogosultságokat azoktól az eszközöktől, amelyeknek nincs feltétlenül szükségük rájuk.
• Törölj minden olyan tailscale serve forwardot, amely Unix socketre mutat.
• Kapcsold be a node-key lejáratot, hogy egy ellopott eszközkulcs ne maradjon korlátlan ideig érvényes.
• Ha egy eszköz kompromittálódik, töröld a control plane-en. Az újratelepítés önmagában nem vonja vissza azokat a kulcsokat, amelyeket a támadó már lemásolhatott róla.

A Tailscale azt is javasolja, hogy kapcsold be az SSH check mode-ot, amely egy plusz bejelentkezési lépést iktat be a session indulása elé, és engedélyezd az automatikus frissítéseket. A check mode nem javítja a jogosultságkiterjesztést, csak egy újabb akadályt állít elé.