Tailworm: Ungepatchte Lücken in Tailscale SSH erlauben Root

Ein am 25. Oktober 2026 veröffentlichter Prüfbericht namens Tailworm beschreibt, wie ein einzelnes kompromittiertes Gerät in einem Tailscale-Netz über Tailscale SSH Root-Rechte auf anderen Servern erlangen kann. Getestet wurden der Tailscale-Client v1.104.2 und der selbst gehostete Kontrollserver headscale v0.29.5. Eine CVE, ein Security Bulletin oder eine korrigierte Version gibt es bislang nicht.

Betroffen sind Umgebungen, in denen Tailscale SSH aktiv ist und Weiterleitungen über SSH erlaubt sind. Wer Tailscale nur als VPN nutzt und Tailscale SSH nicht eingeschaltet hat, ist von diesem Kernbefund nicht betroffen. Weil kein Patch existiert, sollten Admins ihre SSH-Regeln heute prüfen und nicht auf ein Wartungsfenster warten. Besonders headscale-Betreiber, denn dort lässt sich die Weiterleitung laut Bericht gar nicht abschalten.

Was ist passiert?

Erica Windisch von Cyberdione Labs hat Tailscale und headscale vom 22. bis 24. Oktober 2026 im Labor untersucht und elf Befunde veröffentlicht. Im Zentrum steht der eingebettete SSH-Server von tailscaled, der als root läuft. Leitet eine normale SSH-Sitzung Unix-Sockets per ssh -L oder ssh -R weiter, führt tailscaled die Pfadprüfungen und Dateioperationen mit Root-Rechten aus.

Daraus ergeben sich laut Bericht drei Wege: Verbindungen zu Sockets, die nur root erreichen darf, etwa dem Docker-Socket, das Ersetzen root-eigener Sockets durch einen Listener des Angreifers und eine Race Condition (TOCTOU), die die Pfad-Allowlist zwischen Prüfung und Nutzung aushebelt. Im Labor gelang so Root-Ausführung ohne sudo oder Docker-Gruppe. Über einen gekaperten Steuer-Socket wurde zudem ein Schlüssel zur Geräteregistrierung abgegriffen und ein fremdes Gerät als regulärer Server ins Netz aufgenommen. Der letzte Schritt funktionierte durchgängig nur ohne aktiviertes Tailnet Lock.

Weitere Befunde betreffen die experimentellen App-Connectoren (conn25), die Funktion tailscale serve, den DERP-Client und headscale selbst, das sich ohne Anmeldung per Speicherüberlastung in eine Absturzschleife treiben lassen soll.

Wer ist betroffen?

• Netze mit aktiviertem Tailscale SSH auf Servern, besonders mit breiten Regeln für ganze Identitäten oder Tags.
• headscale v0.29.5: Weiterleitung wird bei jeder akzeptierten SSH-Sitzung gewährt. Jede SSH-Freigabe ist dort praktisch eine Root-Freigabe.
• Tailscale-SaaS: Weiterleitung ist pro Regel abschaltbar, das Risiko hängt also von der Konfiguration ab.
• Selbst gehostete headscale-Server, die aus dem Internet erreichbar sind (Absturzschleife).

Das jüngste headscale-Release v0.29.6 vom 24. Oktober 2026 nennt in seinen Release Notes den Build mit Go 1.27.3 gegen die kompromittierten eMudhra-Zwischenzertifikate sowie Abhängigkeitsupdates. Hinweise auf die Tailworm-Befunde enthält es nicht. Auch Tailscale v1.104.2 ist weiterhin die aktuelle Version.

Wie kritisch ist das?

Technisch handelt es sich um eine Rechteausweitung, die einen bestehenden Zugang voraussetzt: Der Angreifer braucht ein Gerät im Netz, dem eine SSH-Regel den Zugriff auf das Ziel erlaubt. Diesen ersten Zugang erlangt er laut Bericht auf üblichen Wegen, etwa über eine verwundbare Webanwendung oder ein manipuliertes Paket. Danach braucht er weder Passwörter noch Schlüssel. Im Labor verbreitete sich der Angriff automatisiert in unter einer Sekunde pro Gerät.

Einschränkungen gehören dazu: Alle Befunde stützen sich bislang allein auf diesen Bericht, unabhängig nachvollzogen wurden sie laut The Hacker News noch nicht, und der Proof of Concept ist nicht öffentlich. Einige Fachleute bezweifeln die Einstufung als wurmfähig. Tailscale-Vizepräsident Mike Shaver bestätigte laut The Hacker News auf Reddit, dass das Unternehmen an Fixes arbeitet, empfiehlt aber nicht, Tailscale SSH flächendeckend abzuschalten.

Was sollten Admins jetzt tun?

• Inventar erstellen: Welche Knoten bieten Tailscale SSH an, welche SSH-Regeln stehen in der Policy, welche Version von tailscaled und headscale läuft?
• SSH-Regeln als Paare formulieren (ein Quellgerät, ein Ziel) und Regeln für ganze Identitäten oder Tags entfernen. Laut Bericht stoppte nur das die Ausbreitung.
• Auf der SaaS-Variante Weiterleitungen pro Regel deaktivieren, sofern kein dokumentierter Bedarf besteht.
• Bei headscale jede SSH-Freigabe wie root behandeln und Tailscale SSH dort, wo es verzichtbar ist, durch regulären SSH-Zugang mit Schlüsseln ersetzen.
• tailscale serve auf TCP-Weiterleitungen zu Unix-Sockets prüfen und App-Connector-Rechte entziehen, wo sie nicht gebraucht werden.
• Ablauf der Node-Keys aktivieren, Tailnet Lock prüfen und kompromittierte Geräte in der Kontrollebene löschen, da Neuinstallation gestohlene Schlüssel nicht widerruft.
• headscale nicht ungeschützt ins Internet stellen, Speicherlimits und Neustartüberwachung setzen.

Einordnung für Unternehmen

Tailscale SSH ist bequem, weil es Schlüsselverwaltung erspart. Genau das macht den Befund heikel: Autorisiert wird das Gerät, nicht der Mensch. SSH-Regeln gehören deshalb so eng gefasst wie Firewall-Regeln, gehärteter klassischer SSH-Zugang bleibt bis zu Korrekturen die sichere Alternative. Ein Bulletin von Tailscale steht noch aus.

Passende Anleitungen auf S-EDV

• Headscale und Tailscale als selbst gehostetes Mesh-VPN für KMU
• SSH härten mit sshd_config und ssh-audit
• Zero Trust und Netzwerksegmentierung mit VLANs und Firewall-Regeln

Quellen

• Tailworm: Security Assessment Report zu Tailscale v1.104.2 und headscale v0.29.5 (Cyberdione Labs)
• The Hacker News: Unpatched Tailscale SSH Flaws (25.10.2026)
• Tailscale Security Bulletins
• headscale v0.29.6 Release Notes (GitHub)