Ungepatchte Schwachstellen in Tailscale SSH: Ein gekapertes Gerät kann Root auf anderen Servern erlangen

Windisch testete über drei Tage im Labor Tailscale in Version 1.104.2 sowie headscale 0.29.5 — den selbst betriebenen Server, den manche Netze statt des gehosteten Dienstes des Unternehmens einsetzen. Der Report beschreibt ausdrücklich Tests an dieser Software, keine Angriffe auf reale Netze.

Tailscale SSH arbeitet anders als ein üblicher SSH-Server: Statt Passwort oder Schlüssel eines Nutzers zu prüfen, identifiziert es das Gerät, und eine einzelne Zugriffsregel entscheidet, ob dieses Gerät eine SSH-Sitzung zum Ziel aufbauen darf. Deshalb kommt der Angriff ohne gestohlene Zugangsdaten aus. Nötig ist zunächst ein Fuß in der Tür auf einem Gerät — laut Report auf den üblichen Wegen: eine verwundbare Webanwendung, ein manipuliertes Softwarepaket, Phishing oder entwendete Anmeldedaten. Tailscale selbst schafft diesen ersten Zugang nicht.

Drei Stufen im Labor

Mit gewöhnlichem SSH-Port-Forwarding brachte eine normale Sitzung den mit Root-Rechten laufenden Tailscale-Prozess dazu, sich mit einem Systemsocket zu verbinden, auf den nur Root zugreifen sollte. Der Test erlangte damit fast sofort und ohne Administratorrechte Root-Rechte und las die Systempasswortdatei aus.

Eine zweite Methode ersetzte einen Root-eigenen Socket durch den des Angreifers und erlaubte so die direkte Ausführung von Root-Befehlen gegen bestimmte Dienste.

Eine dritte Methode umging eine Sicherheitsprüfung, die begrenzen soll, auf welche Dateien das Forwarding zugreifen darf — über ein Wettrennen zwischen dem Zeitpunkt der Pfadprüfung und dem der Nutzung. Diese Kette reichte im Labor weiter: Sie erbeutete einen Schlüssel zum Einbinden neuer Geräte und nutzte ihn, um eine eigene Maschine des Angreifers als vertrauenswürdigen Server ins Netz aufzunehmen. Dieser letzte Schritt gelang vollständig nur in Netzen ohne aktiviertes Tailnet Lock; war die Funktion aktiv, wurden die nötigen Geheimnisse zwar während der Übertragung abgefangen, der Abschluss misslang jedoch.

„Wormable“ — und Widerspruch

Windisch bezeichnet das Gesamtergebnis als „wurmfähig“: Im Labor konnte sich ein kompromittiertes Gerät auf jedes Gerät ausbreiten, das die Zugriffsregeln erlauben — ohne Passwörter, ohne gestohlene Schlüssel, ohne Zutun eines Nutzers und in weniger als einer Sekunde pro Schritt. Im Report heißt es, „das Mesh verwandelt einen gewöhnlichen Fuß in der Tür in flottenweiten privilegierten Zugriff in Maschinengeschwindigkeit“. Gemessen wurde diese Ausbreitung im Labor, nicht in realen Netzen.

Zwei Dinge bremsten den Angriff: Zugriffsregeln, die als einzelne Quelle-Ziel-Paare formuliert sind — sie stoppten die Ausbreitung für sich genommen —, sowie Geräteschlüssel, die an Hardware wie TPM oder Secure Enclave gebunden sind.

Einige Forscher, die den Report gelesen haben, stellten die Bezeichnung „wurmfähig“ öffentlich infrage, andere nannten den Befund zum Root-Zugriff gravierend.

Elf Befunde insgesamt

Das SSH-Problem ist einer von elf Befunden. Der Report behandelt außerdem Tailscales App-Connectors, die Funktion serve, das zwischen Geräten genutzte DERP-Relay sowie headscale. Windisch sagte, die SSH-Rechteausweitung sei „besorgniserregend“, der Befund zu den App-Connectors „könnte für manche Organisationen aber folgenreicher sein“. Dieser Befund betrifft eine experimentelle Funktion namens conn25: Ein berechtigter Nutzer kann Verkehr an Ziele senden, die das Sicherheitsteam nie freigegeben hat — darunter der Metadatendienst eines Cloud-Anbieters, der Server-Zugangsdaten herausgeben kann.

Alle Befunde stützen sich allein auf Windischs Report. Kein weiterer Forscher hat sie öffentlich reproduziert, und Tailscale hat die konkreten technischen Behauptungen nicht bestätigt. Der zugrunde liegende Proof-of-Concept-Code ist nach Windischs Angaben nicht öffentlich; sie habe ihn ausschließlich an den Sicherheitskontakt von Tailscale übergeben.

Reaktion von Tailscale und Streit um die Offenlegung

Mike Shaver, Vice President of Engineering bei Tailscale, schrieb auf Reddit, das Unternehmen habe den Report erhalten, sich mit externen Sicherheitsspezialisten bereits mit denselben Bereichen befasst und Probleme gefunden, an deren Behebung es arbeite. Noch werde geklärt, welche Konfigurationen betroffen seien; man empfehle „nicht, dass alle Tailscale SSH deaktivieren“.

Windisch beschrieb die Offenlegung als „gemeldet, aber nicht koordiniert“ und schrieb dies auch auf Ycombinator HN; mindestens ein Kommentator dort nannte eine Veröffentlichung ohne vorherige Meldung an Tailscale unverantwortlich. Windisch erklärte, sie habe Tailscale Report und Proof-of-Concept-Code tatsächlich vor der öffentlichen Veröffentlichung zukommen lassen — am Samstag zuvor an den Sicherheitskontakt des Unternehmens. Zudem habe sie bereits früher Bedenken zur Architektur gegenüber dem Vorstandschef geäußert sowie öffentlich einen Datei-Hash veröffentlicht und Nutzern geraten, Tailscale SSH abzuschalten.

Der Report reiht sich in eine Serie von Problemen im selben Bereich ein: Früher im Jahr 2026 hatte das Unternehmen mehrere Schwachstellen in Tailscale SSH und in der Socket-Behandlung des Servers behoben, darunter eine, bei der SSH-Unix-Socket-Forwarding einen privilegierten Socket erreichen konnte — korrigiert in Version 1.98.9.

Mögliche Maßnahmen ohne Patch

Da kein Patch vorliegt, bleiben Änderungen an der Konfiguration von Tailscale SSH und verwandten Funktionen. Die Empfehlungen aus dem Report und die von Tailscale decken sich weitgehend:

• Zugriffsregeln für Tailscale SSH prüfen und als einzelne Quelle-Ziel-Paare schreiben, die genau ein Gerät und ein Ziel benennen; breite Regeln, die Zugriff über Identität oder Tag gewähren, entfernen. Der Report nennt Regeln je Paar die einzige Maßnahme, die die Ausbreitung im Test stoppte.
• SSH-Port-Forwarding abschalten, wo möglich. Im gehosteten Dienst von Tailscale ist das eine Einstellung je Regel. In headscale 0.29.5 lässt es sich gar nicht deaktivieren — dort sollte jede SSH-Berechtigung als Root-Zugriff auf das Ziel betrachtet werden.
• App-Connector-Berechtigungen von Geräten entfernen, die sie nicht benötigen.
• Jede tailscale-serve-Weiterleitung entfernen, die auf einen Unix-Socket zeigt.
• Ablauf von Node-Keys aktivieren, damit ein entwendeter Geräteschlüssel nicht unbegrenzt gültig bleibt.
• Kompromittierte Geräte in der Control Plane löschen. Ein Neuaufsetzen der Maschine widerruft keine Schlüssel, die ein Angreifer bereits kopiert haben könnte.

Tailscale empfiehlt zusätzlich den SSH-Check-Modus, der vor dem Start einer Sitzung einen Anmeldeschritt einfügt, sowie automatische Updates. Der Check-Modus behebt die Rechteausweitung nicht, sondern stellt ihr lediglich eine weitere Hürde voran.