Tailscale hat am Mittwoch den Patch veröffentlicht — und einen guten Teil desselben Beitrags damit verbracht, über den Namen zu streiten.
Version 1.104.4 schließt Rechteausweitungs-Lücken in Tailscale SSH sowie Fehler in Serve und Funnel, dokumentiert in vier Sicherheitsbulletins von TS-2026-014 bis TS-2026-017. Sie erscheint fünf Tage, nachdem Erica Windisch von Cyberdione Labs „Tailworm" veröffentlicht hat: elf Befunde in fünf Klassen, getestet gegen tailscale 1.104.2 und headscale 0.29.5 zwischen dem 22. und 24. Oktober. Eine koordinierte Offenlegung gab es nicht; Tailscale erhielt den Bericht nach eigener Darstellung am Morgen des Samstags, zwei Stunden später war er öffentlich.
Der Fehler liegt nach dem Login
Die klarste Beschreibung liefert der Hersteller selbst: Die Lücken lagen nicht in der Authentifizierung und nicht in der Auswertung der Policy — also dort, wo entschieden wird, wer sich verbinden darf —, sondern darin, wie Rechte durchgesetzt wurden, nachdem eine Sitzung autorisiert war. Tailscale SSH braucht erhöhte Systemrechte, um Sitzungen als verschiedene Unix-Benutzer zu starten; die Grenze zwischen diesen erhöhten Rechten und der Sitzung des verbundenen Benutzers hielt nicht in allen Fällen, auch nicht beim SSH-Forwarding.
Im Labor der Forscherin genügte ein kompromittiertes Gerät, um auf anderen Servern Root zu erlangen und einen fremden Knoten zu registrieren. Daher der Name: aus einem Einstiegspunkt wird ein Schlüssel zum Rest des Netzes. Die meisten der elf Befunde bewertete die Forscherin als hoch oder mittelhoch.
Was der Hersteller einräumt — und was er bestreitet
Tailscale räumt ein, dass die Rechtegrenze nicht korrekt durchgesetzt wurde, nennt die Probleme dringend und erklärt, über die gemeldeten Symptome hinaus „architektonische Schutzmechanismen" gegen verwandte Fehlerklassen eingebaut zu haben.
Fast alles an der Einordnung bestreitet das Unternehmen. Ein nicht authentifizierter Angreifer könne sich nicht mit beliebigen Tailscale-SSH-Servern verbinden: Ausnutzung setze einen bestehenden Zugang auf einem autorisierten Peer voraus, ausdrücklich per Policy-Datei erlaubten SSH-Zugriff und die Bedingungen, unter denen der verwundbare Code erreichbar ist. Weil die Policy-Datei den Zugriff zwischen Maschinen weiterhin begrenzte, habe ein Angreifer nur Maschinen erreicht, die die Policy ohnehin zuließ.
Und es sei kein Wurm. „Sie beschreiben keine sich selbst replizierende Malware, die sich automatisch zwischen Maschinen ausbreitet", heißt es in dem Beitrag. „Besser beschrieben wäre es als laterale Bewegung, begrenzt auf Verbindungen, die eine Tailnet-Policy-Datei erlaubt."
Von fünf Befunden in Serve und Funnel seien drei Fehler und behoben; zwei beschrieben Verhalten wie vorgesehen — das Umgehen der Funnel-Attributprüfung erfordere lokale Adminrechte, und TS_SERVE_ALLOW_ALL_INTERFACES sei eine Opt-in-Einstellung. Der Conn25-Befund betrifft einen App-Connector, der nie ausgeliefert wurde; die stabilen Connectoren sind nicht betroffen.
Der Bericht erfasste außerdem headscale, den separaten Open-Source-Kontrollserver, den Tailscale nicht betreut. Version 0.29.6 erschien am 24. Oktober; ihre Release Notes erwähnten die Befunde nicht. Wer diese Kontrollebene selbst betreibt, arbeitet dem Stand der Veröffentlichung nach mit Übergangsmaßnahmen statt mit einem Hersteller-Fix.
Dasselbe Subsystem, zum zweiten Mal
Die beiden betroffenen Komponenten sind die beiden, die schon im Juni betroffen waren. TS-2026-004 und TS-2026-005, beide am 3. Juni veröffentlicht und in 1.98.9 behoben, betrafen SSH-Unix-Socket-Forwarding, das Symlink-Rechte ignorierte, sowie Serve-Unix-Socket-Proxy-Ziele, die nicht auf root beschränkt waren. Architektonische Schutzmechanismen sind die richtige Antwort auf eine Wiederholung — zugleich das Eingeständnis, dass die Juni-Fixes Punktkorrekturen an derselben Nahtstelle waren.
Was Betreiber tun sollten
Auf mindestens 1.104.4 aktualisieren. Danach die Policy-Datei als das behandeln, was sie nachweislich ist: die Sicherheitsgrenze. SSH-Regeln zu Paar-Grants umschreiben — eine benannte Quelle, ein benanntes Ziel —, identitäts- und tagweite Accept-Regeln entfernen, Forwarding in jeder Regelaktion verweigern. Für sensible Systeme den SSH-Check-Modus einschalten. Auf Geräten ohne Bedarf `tailscale set --ssh=false` ausführen, nachdem ein anderer Zugangsweg bestätigt wurde. Die App-Connector-Fähigkeit entfernen, wo sie ungenutzt ist, und Serve-Forwardings auf Unix-Sockets prüfen.
Bei Verdacht den Knoten in der Kontrollebene löschen. Neuaufsetzen widerruft keine Knotenschlüssel, die bereits kopiert wurden; war ein Tailnet-Lock-signierender Knoten kompromittiert, muss Tailnet Lock rotiert werden.
Der strukturelle Punkt bleibt ohnehin. Ein Zero-Trust-Netz bündelt Zugriffsentscheidungen an einer Stelle — genau deshalb lohnt es sich, und genau deshalb sind Fehler dort kategorial schlimmer als in jedem einzelnen geschützten Server. Das Produkt von Tailscale ist die Zusage, dass ein gestohlenes Notebook kein Dietrich wird. Für ein paar Tage im Oktober behauptete der Bericht das Gegenteil.
