Tailscale heeft 1.104.4 uitgebracht als reactie op kwetsbaarheden in de ingebouwde SSH-server. Met de Tailscale SSH-patches wil de leverancier voorkomen dat een aanvaller—met een al toegestane toegang—via SSH-forwarding bij services of bestanden kan komen die normaliter alleen door root aangeraakt mogen worden.
Hoewel Tailscale benadrukt dat een volledig anonieme aanvaller niet zomaar willekeurige SSH-servers kan bereiken, is het risico vooral relevant zodra iemand een apparaat in handen krijgt dat al door de Tailscale-toegangsregels wordt vertrouwd.
Wat gaat er mis met Tailscale SSH?
De kern van het probleem zit in hoe Tailscale SSH verbindingen forwardt. Daarbij gebruikt het Tailscale-achtergrondproces (tailscaled) doorgaans root-privileges om netwerkverkeer door te geven naar een doel op basis van policy’s en identiteiten.
Volgens de uitleg van Tailscale wordt toegang bepaald door wie een apparaat is en wat de netwerkpolicy toestaat—dus niet door een wachtwoord of SSH-sleutel. Een aanvaller heeft daarom geen gestolen inloggegevens nodig, maar wel een “voet aan de grond”: een apparaat dat al binnen de regels toegang mag krijgen.
Waarom kan forwarding leiden tot root-only toegang?
De kwetsbaarheid draait om socket forwarding. In de situatie die is onderzocht, leidt een toegestaan SSH-voorbeeld tot forwarding naar een Unix socket op de server. Tailscale controleert daarbij een pad, maar voert daarna de operatie toch als root uit.
Door een timing-truc kon een aanvaller volgens het onderzoeksrapport een ander pad laten “meespelen” nadat de controle had plaatsgevonden. Daarmee werd de beoogde beperking om welke sockets geforward konden worden, onderuit gehaald.
Wat kan een aanvaller dan precies bereiken?
Tailscale beschrijft het bereik niet als volledige willekeur, maar als toegang tot root-only onderdelen die normaal niet toegankelijk horen te zijn. In de eigen test van de onderzoekster werd bijvoorbeeld forwarding naar de Docker control socket gebruikt om een root-shell te verkrijgen en zelfs de inhoud van /etc/shadow te lezen.
Tailscale formuleert het in de bulletin-notities breder en wijst daarbij ook op scenario’s waarin een aanvaller bij sockets kan komen zoals de Docker socket of de tailscaled local API. Dat zijn precies de soorten endpoints die je op systeemniveau niet door ongeautoriseerde partijen wil laten aansturen.
Welke fixes zitten er in versie 1.104.4?
Naast het hoofdbulletin rond SSH-forwarding bevat 1.104.4 meerdere security-updates. In totaal gaat het om vier afzonderlijke bulletins (TS-2026-014 t/m TS-2026-017):
- TS-2026-014: kwetsbaarheden in SSH socket-forwarding die een toegelaten sessie tot root-only sockets zoals de Docker socket of de tailscaled local API kunnen brengen.
- TS-2026-015: een manier om via een toegelaten SSH-sessie de geheugenbelasting te vergroten en het tailscaled-proces te laten crashen, waardoor de Tailscale-netwerkfunctionaliteit op die node uitvalt.
- TS-2026-016: in tailscale serve kan forwarding naar een Unix socket de tailscaled local API bereikbaar maken (met daaraan gekoppelde socket-swap problematiek).
- TS-2026-017: met TLS serve en twee of meer mounts kan één request de permission headers van een andere mount “meekrijgen”.
De belangrijkste technische wijziging voor de SSH-forwarding kwetsbaarheid is dat Tailscale de forwarding vanaf de server niet langer als root laat uitvoeren, maar als de ingelogde gebruiker. Daarnaast leunt de oplossing op de bestandspermissies van het besturingssysteem in plaats van uitsluitend op een eerder controlepunt.
Wat moet je doen? Update, of zet forwarding uit
De directe aanbeveling is eenvoudig: update tot Tailscale 1.104.4 of later. Heb je (nog) geen mogelijkheid om servercomponenten direct te upgraden, dan geeft Tailscale ook een tijdelijke mitigatie.
Je kunt SSH-forwarding uitschakelen door op de tailscaled-serviceomgeving de variabele in te stellen:
TS_SSH_DISABLE_FORWARDING=1
Daarna moet je de tailscaled-service herstarten. Tailscale stelt dat hierdoor forwarding wordt geblokkeerd zonder de Tailscale SSH zelf uit te schakelen, en dat meerdere van de ernstigere bevindingen zo worden tegengehouden.
Toegangsregels herzien: behandel “toegelaten” als mogelijk gevaarlijk
Omdat de toegang verloopt via identity en policy—niet via wachtwoorden—is het slim om je SSH-toegangsregels te herbekijken. Geef alleen rechten aan de gebruikers en apparaten die dit echt nodig hebben.
In het bijzonder geldt: als een apparaat al gecompromitteerd raakt, kan die aanvaller via een toegestane sessie profiteren. Het onderzoeksrapport beschrijft zelfs een keten die “wormable” wordt genoemd: verspreiding over apparaten die door dezelfde policy mogen communiceren.
Waarom check mode je niet volledig redt
Tailscale adviseert het gebruik van SSH check mode voor gevoelige systemen. Die modus zorgt ervoor dat een gebruiker opnieuw moet inloggen voordat een sessie start.
Maar let op: de forwardings- en socket-gerelateerde problemen spelen zich af binnen een sessie die al eenmaal is goedgekeurd. Check mode helpt dus vooral tegen nieuwe sessie-opstart, maar niet tegen de risico’s tijdens de sessie zelf.
Als een apparaat al gecompromitteerd is
In het onderzoeksrapport wordt benadrukt dat de softwarefix alleen niet genoeg kan zijn als de situatie al actief is. Een gestolen device key kan namelijk geldig blijven totdat het apparaat op de control plane wordt verwijderd. Herinstalleren of opnieuw inrichten van de machine kan de sleutel niet automatisch intrekken.
Daarom is het bij incidenten belangrijk om niet alleen de versie te patchen, maar ook te controleren welke devices en keys nog als “trusted” staan.
Gerelateerd: als je ook kijkt naar situaties waarin tokens en authenticaties misbruikt worden, kan dit artikel je helpen bij het versterken van je account- en key-hygiëne: Microsoft 365 token replay-aanvallen en wat je kunt leren.
Extra aandacht bij headscale
Voor wie headscale gebruikt (de self-hosted control server): wees extra alert. Volgens de onderzoeksbevindingen wordt SSH-forwarding daar automatisch toegestaan in elke geaccepteerde sessie en is het niet uit te zetten via policy.
Het gevolg is dat elke SSH-grant in headscale praktisch gezien als risicovol moet worden behandeld—en dus moet worden gezien alsof die sessie tot root-level endpoints kan leiden. De nieuwste headscale release die in de berichtgeving genoemd wordt (0.29.5, van 13 oktober) zou de gerapporteerde issues niet fixen.
Is dit een worm?
De onderzoekster beschrijft de aanvalsketen als “wormable”. In haar tests kon één gecompromitteerd apparaat zich verspreiden naar alle apparaten waarvoor de policy connectiviteit toestaat—zonder wachtwoorden, zonder gestolen keys en zonder extra gebruikersactie. Ze rapporteert zelfs dat de keten per stap razendsnel kan verlopen.
Tailscale zelf wijst die term deels af. Het stelt dat de bevindingen geen zelfreplicerende malware beschrijven die volledig autonoom verspreidt; het gaat om laterale beweging binnen de grenzen van wat de policy al toestaat. Hoe je het label ook kiest, de technische uitkomst blijft: een gecompromitteerd device kan meer impact hebben dan je op basis van losse hosts zou verwachten.
Eerder: al vaker issues in Unix-socket forwarding
Dit is niet het eerste probleemgebied in dezelfde componenten. In juni zou Tailscale al een aparte kwetsbaarheid hebben gefixt in Tailscale SSH’s Unix-socket forwarding, waarbij een niet-geprivilegieerde gebruiker een privileged socket kon bereiken—toen in versie 1.98.9.
Als je bredere kennis zoekt over vergelijkbare privilege-escalatie via forwarding en sandbox/pipeline-achtige mechanismen, lees dan ook: Wasmtime sandbox lek: updates voor twee CVE’s. Dat artikel helpt om te zien hoe belangrijk het is om te kijken naar wie taken uitvoert en onder welke rechten.
Conclusie
Met de Tailscale SSH-patches in versie 1.104.4 pakt Tailscale serieuze securityproblemen aan in de ingebouwde SSH-forwarding. Het risico is vooral relevant als een aanvaller een apparaat heeft dat door jouw policy al als toegangspunt wordt gezien.
Werk daarom direct bij naar 1.104.4 of hoger, herzie SSH-toegangsregels en behandel gecompromitteerde devices en keys als incidentmateriaal dat je niet alleen “patcht”, maar ook effectief intrekt waar nodig.
Bron: https://thehackernews.com/2026/10/tailscale-patches-ssh-flaws-that-could.html
