Een gehackt toestel binnen een Tailscale-netwerk kan, onder bepaalde omstandigheden, doorgroeien naar root-toegang op andere servers die het kan bereiken. Onderzoekers brachten dit deze week onder de aandacht via een rapport met de naam Tailworm. Omdat er op het moment van publicatie geen officieel beveiligingsbulletin of vaste oplossing was, komt het neer op het zorgvuldig aanscherpen van instellingen en toegang.
In dit artikel zetten we de belangrijkste bevindingen en praktische maatregelen op een rij, met extra aandacht voor wat je vandaag al kunt doen om je risico te beperken.
Wat zijn de Tailscale SSH-flaws precies?
Volgens het Tailworm-rapport draait het probleem om Tailscale SSH in combinatie met port forwarding. De kern: Tailscale SSH werkt niet zoals een klassieke SSH-server die gebruikers legitimeert met wachtwoorden of sleutels. In plaats daarvan identificeert het systeem een apparaat, en bepaalt één specifieke toegangsregel of dat apparaat een SSH-sessie mag openen naar een doel.
Daardoor is het uitgangspunt van de aanval niet “een gestolen gebruikersnaam of sleutel”, maar een voet tussen de deur: een aanvaller moet al toegang hebben tot één apparaat binnen het netwerk waarop de access rules hem toelaten.
Waarom één gecompromitteerd apparaat genoeg kan zijn
Het rapport beschrijft tests in een labopstelling met Tailscale versie 1.104.2 en headscale 0.29.5. In die setting kan de aanvaller via SSH-forwarding, stap voor stap, privileges opstapelen. Het resultaat dat is beschreven gaat verder dan een normale admin-toegang: in de labtests werd root-niveau toegang bereikt op systemen waar het geautoriseerde pad toegang gaf.
De onderzoeker vermeldt dat het geheel in de praktijk afhankelijk is van je configuratie: de regels bepalen welke doelen binnen bereik liggen en of de keten kan doorlopen.
Geen patch, wel duidelijke configuratiewijzigingen
Belangrijk: bij publicatie was er geen CVE, geen security bulletin en geen “gepatchte versie” genoemd. Tailscale gaf wel publiek antwoord en stelde dat het de bevindingen had ontvangen, dat men al met externe specialisten naar vergelijkbare punten keek en bezig is met het oplossen.
Totdat er een vaste oplossing is, zijn dit de maatregelen die in het rapport en in de berichtgeving eromheen overlappen.
Maak je Tailscale SSH-regels strakker
De grootste praktische rem zit in de access rules voor Tailscale SSH. Het rapport stelt dat instellingen met brede machtigingen minder veilig zijn dan zeer specifieke regels.
Concreet adviseert men om SSH-regels te schrijven als single source-to-destination pairs: één bronapparaat naar één doelapparaat. Brede regels gebaseerd op identiteit, tags of ruimere criteria zouden de “spreidbaarheid” in theorie vergroten.
Met andere woorden: als je één regel te ruim openzet, kan dat een keten mogelijk maken die van één voet aan de deur doorgaat naar meerdere doelen.
Port forwarding uitzetten (waar mogelijk)
Naast de regels zelf is port forwarding een belangrijke schakel. Op de door Tailscale gehoste service kan port forwarding per regel worden uitgeschakeld. Bij headscale 0.29.5 zou port forwarding echter volgens het rapport niet uit te zetten zijn.
Daarom is het advies daar extra streng: behandel elke SSH-grant op headscale als root-toegang op het doel dat in de regel staat.
App connectors en serve-functies: beperk onnodige rechten
Het Tailworm-rapport omvatte meerdere bevindingen. Voor organisaties die het breed gebruiken, gaat het niet alleen om SSH.
- Verwijder app connector-permissies op toestellen die ze niet nodig hebben.
- Verwijder “serve forward” die verwijst naar een Unix socket. Het idee is: als je forwarding richt op lokale sockets, vergroot je het aanvalsvlak.
Een deel van deze onderdelen kan per organisatie meer of minder impact hebben, maar het algemene patroon is duidelijk: minimaliseer wat systemen mogen doorgeven aan andere bestemmingen.
Beperk hergebruik van gestolen device keys
Omdat de aanval in het beschreven scenario niet draait om gestolen SSH-wachtwoorden, maar om een gecompromitteerd apparaat, is het beperken van “blijvende” toegang relevant. Het rapport noemt het inschakelen van node-key expiry, zodat een gestolen device key niet onbeperkt geldig blijft.
Dat vermindert de tijd waarin een aanvaller kan teruggrijpen op eerdere controle, zelfs als je later corrigeert.
Bij compromittering: verwijder het toestel bij de control plane
Als een device daadwerkelijk is gecompromitteerd, is de voorgestelde respons duidelijk: delete** het apparaat bij de control plane. Reimaging of opnieuw installeren van een machine zou volgens de toelichting de waarde van eerder gekopieerde sleutels niet automatisch ongedaan maken.
In incident response-termen: je wilt voorkomen dat een aanval “blijft leven” via credentials die al buiten het systeem zijn beland.
Extra maatregelen die niet de privilege-escalatie fixen
Tailscale noemt daarnaast extra beveiligingsstappen, maar met een belangrijke nuancering: sommige daarvan voegen een extra barrière toe, maar lossen het privilege escalation-probleem niet rechtstreeks op.
- SSH check mode voegt een extra loginstap toe voordat een sessie start.
- Automatic updates helpen om bekende problemen sneller te mitigeren zodra er wel patches zijn.
Deze acties zijn dus niet “de oplossing” voor de Tailworm-issue, maar ze verkleinen wel de kans dat misbruik ongemerkt doorloopt.
Praktisch stappenplan voor security teams
Wil je dit vertalen naar een werkbaar actieplan? Hieronder een volgorde die logisch aansluit bij de beschreven oorzaken.
- Inventariseer alle Tailscale SSH access rules en markeer welke regels brede toegangen geven.
- Herstructureer de regels naar single source-to-destination pairs.
- Zet port forwarding uit waar dat kan; als je headscale gebruikt, behandel SSH-grants als root.
- Haal app connector-permissies weg bij devices die ze niet nodig hebben.
- Verwijder serve forward naar Unix sockets.
- Activeer node-key expiry en pas incident response aan: delete gecompromitteerde devices bij de control plane.
Door deze stappen consequent uit te voeren, maak je de keten van “eerste toegang” naar “privilege op doelen” aanzienlijk moeilijker.
Vergelijkbare risico’s: let ook op bredere Zero-Trust instelvalkuilen
Het Tailworm-verhaal past in een breder patroon: in moderne netwerken (VPN/Zero Trust/mesh) bepalen toegangsregels het verschil tussen “beperkte connectiviteit” en “laterale beweging”. Eerder zagen we dat ook aanvallen via tooling of integraties kunnen leiden tot onverwachte impact, bijvoorbeeld bij incidenten rond AI-agenten en token-/access-structuren. Als je wilt verdiepen in hoe agentische of geautomatiseerde processen toegang kunnen escaleren, kan dit artikel helpen: AI-agenten als insider threat: wat je nu ziet.
En omdat supply chain en compromisroutes vaak dezelfde “eerste foothold” leveren, is het ook nuttig om te begrijpen hoe een keten door meerdere systemen heen kan lopen, zoals bij eerdere supply chain meldingen rond ontwikkel- en distributiekanalen. Een relevant voorbeeld is: LiteLLM supply chain aanval: PyPI en Docker.
Conclusie
De beschreven Tailscale SSH-flaws laten zien hoe snel één gecompromitteerd apparaat kan uitgroeien tot grote impact, zolang je SSH-forwarding en toegangsregels onvoldoende begrenzen. Omdat er bij publicatie nog geen patch beschikbaar was, is de belangrijkste stap nu: configuratie aanscherpen—van per-rule port forwarding tot het beperken van access rules en het terugschroeven van extra functies.
Maak dit onderwerp onderdeel van je eerstvolgende hardening ronde, test de gevolgen op een stagingomgeving en zorg dat incident response klaarstaat om gecompromitteerde devices direct te verwijderen.
Bron: https://thehackernews.com/2026/10/unpatched-tailscale-ssh-flaws-could-let.html
