Tailscale bestätigt Rechteausweitung in SSH und nennt Härtungsschritte

Tailscale hat in einem Update vom 26. Oktober schwerwiegende Rechteausweitungen in Tailscale SSH bestätigt: Wer sich bereits per Tailscale SSH verbinden darf, kann in manchen Fällen mehr tun, als der konfigurierte lokale Benutzer dürfte. Einen Patch-Client will das Unternehmen bis Ende Dienstag, 27. Oktober, veröffentlichen, vorbehaltlich erfolgreicher Tests.

Bis dahin müssen Sie SSH nicht komplett abschalten. Tailscale nennt als Zwischenlösung engere SSH-Zugriffsregeln und die Umgebungsvariable TS_SSH_DISABLE_FORWARDING=1 für den Dienst tailscaled. Eine CVE-Nummer und eine Fixversion gibt es nach Angaben von Tailscale bislang nicht. Stand 27. Oktober kann der Patch bereits veröffentlicht sein, den aktuellen Stand nennt die Untersuchungsseite von Tailscale.

Was Tailscale zur bestätigten Rechteausweitung sagt und was noch fehlt

Tailscale hat am 26. Oktober eine Seite zur laufenden SSH-Untersuchung veröffentlicht. Dort heißt es, die meisten der identifizierten Tailscale-SSH-Probleme betreffen Rechteausweitung („privilege escalation“). Das Unternehmen spricht ausdrücklich von „serious security issues“, also von ernsten Sicherheitsproblemen. Das ist eine deutlich andere Lage als in den ersten Berichten, die noch von unbestätigten Behauptungen ausgingen.

Zum Verständnis: Bei Tailscale SSH authentifiziert der Dienst tailscaled auf dem Zielgerät die Verbindung anhand der Identität im Tailnet, dem privaten Netz Ihrer Geräte und Konten. Welche Person oder welches Gerät sich auf welchem Rechner als welcher lokale Benutzer anmelden darf, legen die Zugriffsregeln fest. Eine Rechteausweitung bedeutet hier: Die Anmeldung selbst ist erlaubt, aber das Ergebnis geht über die Grenzen hinaus, die der gewählte lokale Benutzer eigentlich setzt.

Genau das beschreibt Tailscale. Wer ohnehin über Tailscale SSH verbinden darf, könne in manchen Fällen Aktionen über die Berechtigungen des konfigurierten lokalen Benutzers hinaus ausführen, „including potentially gaining elevated privileges“, also möglicherweise auch erhöhte Rechte erlangen. Die Voraussetzung ist demnach ein bereits verbindungsberechtigter Zugang. Ein Fremder ohne jede Freigabe im Tailnet ist damit nicht beschrieben.

Wie leicht sich das ausnutzen lässt, hängt laut Tailscale von mehreren Faktoren ab: den Berechtigungen der verbindenden Person oder des verbindenden Geräts, der Systemkonfiguration und weiteren Bedingungen. Umfang und betroffene Konfigurationen prüft das Unternehmen noch. Für Ihre Einschätzung heißt das: Ein Homelab, in dem nur Sie selbst mit Ihren eigenen Geräten verbinden, hat ein anderes Risikoprofil als eine Firma, in der viele Konten auf gemeinsam genutzte Server dürfen. Diese Abstufung ist eine dm-Einordnung und keine Aussage von Tailscale.

Zum Stand der Behebung schreibt Tailscale, Fixes für die meisten Probleme seien implementiert, die Tests vor einem Patch-Release des Clients liefen. Als Ziel nennt das Unternehmen „by the end of Tuesday 27 October“, vorbehaltlich erfolgreicher Tests. Die Seite soll aktualisiert werden, sobald die gepatchte Version verfügbar ist oder sich der Zeitplan ändert. Danach kündigt Tailscale ein Security Advisory an, also eine förmliche Sicherheitsmitteilung mit den bestätigten Lücken, den betroffenen Versionen und Konfigurationen, den Auswirkungen und den Gegenmaßnahmen, sowie einen technischen Blogbeitrag.

Offen sind damit genau die Angaben, die für eine saubere Bestandsaufnahme nötig wären: Tailscale nennt bislang weder CVE noch Fixversion, und welche Konfigurationen betroffen sind, steht noch nicht fest. Auch dass „die meisten“ Probleme behoben seien, lässt Raum für Restpunkte. Prüfen Sie deshalb nicht nur, ob ein Update da ist, sondern auch, was das spätere Advisory zu Ihrer Konfiguration sagt. Ein Hinweis zur Zeitangabe: The Hacker News datiert das Update auf den 27. Oktober, die Tailscale-Seite selbst trägt den 26. Oktober. Hier gilt das Datum von Tailscale.

Der Bericht „Tailworm“ nennt Behauptungen ohne unabhängige Bestätigung

Ausgelöst wurde die Aufmerksamkeit durch einen Bericht mit dem Namen „Tailworm“. Erica Windisch von Cyberdione Labs hat ihn am 25. Oktober veröffentlicht. Er beschreibt 11 Funde rund um Tailscale SSH. Getestet hat Windisch laut dem Bericht von The Hacker News mit Tailscale 1.104.2 und headscale 0.29.5 und drei Tage lang im Labor. Headscale ist die quelloffene, selbst betriebene Alternative zum Koordinationsserver von Tailscale und deshalb für viele Homelabs interessant.

Als Voraussetzung nennt der Bericht laut The Hacker News Tailscale SSH mit erlaubter Port-Weiterleitung. Zusätzlich müsse eine angreifende Person bereits ein Gerät kontrollieren, das laut den Zugriffsregeln verbindungsberechtigt ist. Auch hier gilt also: Ein Zugang, der im Tailnet schon freigegeben ist, steht am Anfang. Technische Angriffsschritte bleiben bewusst außen vor, denn für die Absicherung genügen die genannten Voraussetzungen.

Der Bericht trägt außerdem die Einordnung „wormable“, also die Möglichkeit, dass sich ein Angriff selbstständig von Gerät zu Gerät ausbreitet. Diese Einschätzung haben laut The Hacker News andere Forschende angezweifelt. Tailscale selbst spricht auf seiner Seite von Rechteausweitung, nicht von einer selbstverbreitenden Schwachstelle, und hat „wormable“ nicht bestätigt. Wer in Foren oder sozialen Netzwerken auf Warnungen vor einem Wurm stößt, sollte das als Behauptung einer einzelnen Forscherin behandeln.

Weitere Punkte relativieren die Schlagkraft des Berichts, ohne ihn abzutun. Die Funde sind laut The Hacker News nicht unabhängig reproduziert worden, ein Proof of Concept, also eine Beispielimplementierung des Angriffs, ist nicht öffentlich. Die Offenlegung beschreibt Windisch selbst als „reported but not coordinated“: Sie hat die Probleme gemeldet, aber keine abgestimmte Veröffentlichung mit dem Hersteller durchgeführt.

Wichtig ist die Trennung zwischen beiden Dokumenten. Tailscale hat nach den Angaben von The Hacker News nicht jede konkrete Behauptung des Berichts bestätigt. Bestätigt sind schwere Rechteausweitungen, nicht automatisch jeder der 11 Funde in der beschriebenen Form. Wie viele der Funde sich mit den „most of the issues“ von Tailscale decken, lässt sich Stand 27. Oktober nicht sagen; das Advisory soll das klären.

Für Betreibende von headscale nennt The Hacker News einen zusätzlichen Punkt: headscale 0.29.5 könne die Weiterleitung nicht per Regel abschalten. Als dm-Einordnung gilt: Ob und wie headscale selbst reagiert, ist offen, deshalb bleibt für headscale-Nutzende mit Tailscale-Clients die Härtung auf der Client-Seite der sichere Weg. Zusätzlich sollten sie die Mitteilungen des headscale-Projekts beobachten.

Härtung aus den offiziellen Tailscale-Seiten

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptSystem administrator at a standing desk checking a secure remote connection on a laptop, small server and network gear on a shelf, focused mood, evening office. Photorealistic editorial magazine photo, 16:9. Absolutely no text, no letters, no numbers, no logos, no brand marks.

Tailscale nennt auf der Untersuchungsseite vier Empfehlungen. Ergänzend beschreibt die Dokumentation zu Tailscale SSH die Befehle, mit denen sich Zugriff entziehen oder blockieren lässt. Alle Maßnahmen stammen von den beiden Tailscale-Seiten; was nicht von Tailscale kommt, ist ausdrücklich als solches gekennzeichnet.

Zugriffsregeln auf das Nötige begrenzen

Die erste Empfehlung lautet, die SSH-Zugriffsregeln zu prüfen und auf die Benutzer und Geräte zu begrenzen, die den Zugang wirklich brauchen. Der Zweck ist einfach: Jede verbindungsberechtigte Identität ist ein möglicher Ausgangspunkt für die beschriebene Rechteausweitung. Je kleiner der Kreis, desto kleiner die Angriffsfläche. Die Grenze: Die Regeln verhindern den Missbrauch nicht für Personen, die weiter berechtigt bleiben. Tailscale rät zusätzlich, den Zugriff auf sensible Systeme gezielt zu prüfen und Regeln vorübergehend enger zu fassen.

Wer Server mit SSH-Zugang betreibt, kennt das Muster aus der klassischen Wartung. Als dm-Einordnung lohnt sich derselbe erste Blick wie bei den SSH-Zugängen auf MikroTik-Routern, nämlich die Frage, wer überhaupt Zugang hat.

Weiterleitung abschalten, SSH aber behalten

Die zweite Empfehlung ist die konkreteste. Setzen Sie TS_SSH_DISABLE_FORWARDING=1 in der Umgebung des Dienstes tailscaled und starten Sie den Dienst neu. Damit schaltet Tailscale die SSH-Weiterleitung ab, ohne Tailscale SSH ganz zu deaktivieren. Weiterleitung heißt hier, dass eine SSH-Sitzung als Tunnel für weitere Verbindungen dient, etwa für Ports oder Sockets. Laut Tailscale „mitigates several of the more serious findings“, entschärft also mehrere der schwereren Funde.

Die Grenze steckt im Wort „several“: Der Schalter entschärft mehrere, aber nicht nachweislich alle Probleme. Wer Weiterleitung im Alltag braucht, etwa für Datenbank-Tunnel über SSH, verliert diese Funktion bis zur Rücknahme. Wo die Variable dauerhaft gesetzt werden soll, hängt vom Init-System und der Distribution ab; Tailscale nennt dafür auf der Untersuchungsseite nur die Umgebung des Dienstes.

Zugriff gezielt entziehen

Laut kb/1193 entziehen Sie Zugriff, indem Sie die Zugriffsregel ändern. Das wirkt nahezu sofort und beendet bestehende SSH-Verbindungen, die dann mit „Access revoked“ abbrechen. Das ist der schnellste Weg, wenn ein Konto oder Gerät in Verdacht gerät. Die Grenze nennt die Dokumentation ebenfalls: Zugang außerhalb von Tailscale, etwa über hinterlegte SSH-Schlüssel, bleibt davon unberührt und muss separat entzogen werden. Wer zusätzlich zu Tailscale SSH klassische Schlüssel auf den Servern liegen hat, sollte beide Wege betrachten.

Tailscale SSH auf einem Gerät abschalten oder das Gerät abschirmen

Als härteste Variante beschreibt die Dokumentation tailscale set --ssh=false. Der Befehl schaltet Tailscale SSH auf dem jeweiligen Gerät ab. Die Dokumentation warnt, vorher sicherzustellen, dass ein anderer Weg zum Gerät besteht („ensure you have another way to SSH to the device“). Sonst sperren Sie sich bei einem Server ohne Konsolenzugang selbst aus. Tailscale empfiehlt die komplette Abschaltung laut Untersuchungsseite nicht für alle; sie bleibt eine Option für besonders sensible Systeme.

Daneben blockiert tailscale set --shields-up eingehende Verbindungen aus dem Tailnet, auch Tailscale SSH. Das passt für Geräte, die nur ausgehend kommunizieren sollen. Für Server, auf die Sie per Tailscale zugreifen wollen, ist es keine Lösung, denn damit wäre auch Ihr eigener Zugang weg.

Weitere Maßnahmen laut The Hacker News

The Hacker News nennt darüber hinaus weitere Schritte: Einzelregeln von Quelle zu Ziel statt breiter Freigaben, Ablauf der Node-Keys, Rechte von Konnektoren begrenzen, Weiterleitungen über serve-Sockets prüfen und kompromittierte Geräte aus dem Tailnet löschen. Tailscale hat diese Maßnahmen nicht bestätigt. dm-Einordnung: Diese Maßnahmen sind allgemeine Netzwerkhygiene und nicht Teil der Tailscale-Empfehlung.

Patch einspielen und die Tailscale-Seite im Blick behalten

Die vierte Empfehlung von Tailscale ist schlicht: den gepatchten Client einspielen, sobald er verfügbar ist. Als Ziel nannte das Unternehmen das Ende des 27. Oktober; der Termin stand unter dem Vorbehalt erfolgreicher Tests und konnte sich verschieben. Ob die Version bei Ihnen schon bereitsteht, zeigt die Untersuchungsseite von Tailscale, die das Unternehmen bei Verfügbarkeit oder geändertem Zeitplan aktualisiert. Der Stand 27. Oktober kann beim Lesen überholt sein, ein Blick auf die Tailscale-Seite lohnt sich deshalb.

Ein Patch ersetzt nicht die Auswertung des angekündigten Security Advisorys. Erst dort nennt Tailscale die bestätigten Lücken, die betroffenen Versionen und Konfigurationen sowie die Auswirkungen. Dann lässt sich entscheiden, ob die Weiterleitung wieder aktiviert werden kann und ob die vorübergehend verengten Regeln bleiben sollten. Bis dahin gilt: Schalter und Regeln nicht vorschnell zurücknehmen, nur weil ein neuer Client installiert ist.

Praktisch hilft es, alle Geräte mit Tailscale SSH zu erfassen und nach der Veröffentlichung nacheinander zu aktualisieren, zuerst die Systeme mit den sensibelsten Daten oder den meisten berechtigten Konten. Das ist eine dm-Einordnung. Bei Servern, die ohnehin gerade Wartungsfenster brauchen, etwa wegen des Kernel-Patches für PwnEscape auf KVM-Hosts, lässt sich das Client-Update bündeln.

Wer ein Sicherheitsbulletin mit Nummer erwartet, wird zunächst nichts finden. Auf der Seite der Tailscale-Sicherheitsbulletins war Stand 27. Oktober der jüngste Eintrag TS-2026-013 vom 21. Oktober; er betrifft ein anderes Thema, nämlich eMudhra-Zertifikate. Ein Eintrag zu Tailscale SSH fehlte. Das passt zur Ankündigung, das Advisory erst nach dem Patch zu veröffentlichen.

Ein Blick zurück erklärt, warum sich das Thema lohnt zu beobachten: Laut The Hacker News hat Tailscale früher im Jahr 2026 bereits mehrere Probleme rund um SSH und Sockets in Version 1.98.9 behoben. Tailscale SSH war also schon vorher Gegenstand von Korrekturen. Für Ihre Wartung ist daraus eine konkrete Handlung abzuleiten: Notieren Sie sich, welche Clientversion auf jedem SSH-Gerät läuft, und prüfen Sie nach Erscheinen des Patches, ob die installierte Version dem bestätigten Stand entspricht. Als dm-Einordnung gilt: Erst nach dem Einspielen des gepatchten Clients und einer erneuten Prüfung der Regeln sollten Sie die Weiterleitung wieder erlauben.