Tailscale-Sicherheitslücke Tailworm: Update auf 1.104.4

Was ist die Tailscale-Sicherheitslücke Tailworm?

Die Tailscale-Sicherheitslücke, über die gerade viele schreiben, heißt Tailworm. Dahinter steht ein Bericht von Erica Windisch und Cyberdione Labs mit 11 Befunden zu Tailscale SSH, tailscale serve und headscale. Die Lösung ist der Tailscale-Client in Version 1.104.4 oder neuer. Darin sind die Lücken geschlossen, die Tailscale selbst in vier Bulletins bestätigt hat.

Sie betreiben Tailscale auf einem gemieteten VPS, auf einer Synology oder auf einem Raspberry Pi hinter der FRITZ!Box? Dann ist der erste Schritt ein einziger Befehl: tailscale version auf jedem Gerät. Zeigt er eine ältere Version, aktualisieren Sie. Danach erklärt diese Anleitung, wer wirklich angreifbar ist und was Sie tun, wenn das Update noch nicht möglich ist. Am Ende steht, welche Punkte noch offen sind.

Laut eigener Angabe hat der Bericht Tailscale v1.104.2 und headscale v0.29.5 getestet. Die Tests liefen zwischen dem 22. und dem 24. Oktober 2026 in einer eigenen Laborumgebung.

Warum die Versionsnummer zählt und nicht das Datum

Die Daten auf den Seiten von Tailscale passen nicht zusammen. Die Seite mit den Security-Bulletins datiert TS-2026-014 bis TS-2026-017 auf den 26. Oktober 2026. Das Changelog datiert Version 1.104.4 auf den 28. Oktober 2026. Version 1.104.3 war laut Changelog nur intern und wurde nie veröffentlicht.

Halten Sie sich deshalb an die Versionsnummer. Alle vier Bulletins sagen dasselbe: behoben in Tailscale 1.104.4 oder neuer. Ein Datum hilft Ihnen beim Prüfen nicht, eine Versionsnummer schon.

Wer ist von Tailworm wirklich betroffen?

Lesen Sie diesen Abschnitt vor den Schritten. Laut Tailscale braucht ein Angreifer zuerst Zugriff auf ein bereits autorisiertes Gerät in Ihrem Tailnet. Ein Tailnet ist Ihr privates Tailscale-Netz, also alle Geräte unter Ihrem Konto. Von diesem Gerät aus erreicht der Angreifer laut Tailscale nur Maschinen, zu denen Ihre Richtlinie (das policy file) schon SSH-Verbindungen erlaubt.

Ein Fremder im Internet ohne eigenes Gerät in Ihrem Tailnet hat also keinen direkten Weg zu diesen Lücken. Die Portfreigaben Ihrer FRITZ!Box spielen dafür keine Rolle, denn der Weg führt über ein Gerät im Tailnet. Realistisch ist dieser Fall: Ein Laptop oder Server in Ihrem Tailnet wurde vorher auf anderem Weg übernommen.

Die genauen Voraussetzungen hängen vom Bulletin ab:

• TS-2026-014, SSH-Weiterleitung von Unix-Sockets lief als root: Tailscale SSH muss auf dem Ziel aktiv sein, und Ihre Richtlinie muss lokale oder entfernte Weiterleitung (forwarding) erlauben. Dann konnte ein Peer Sockets erreichen, die nur root öffnen darf, zum Beispiel den Docker-Socket oder die lokale API von tailscaled. Ab 1.104.4 läuft die Weiterleitung als der angemeldete Benutzer und nicht mehr als root.
• TS-2026-015, Speichererschöpfung in SSH-Sitzungen: Hier reicht eine SSH-Sitzung, die Ihre Richtlinie erlaubt. Weiterleitung ist nicht nötig. Die Folge ist ein Denial of Service: tailscaled wird wegen Speichermangel beendet, und der Knoten verliert jede Tailscale-Verbindung.
• TS-2026-016, tailscale serve mit Unix-Socket-Backends: Dafür ist kein Tailscale SSH nötig. Betroffen sind Knoten, auf denen ein lokaler Operator Serve-Konfigurationen schreiben darf. Betroffen sind auch Knoten, auf denen lokale Benutzer die eingetragenen Backend-Pfade beschreiben können. Dann konnte Serve privilegierte Sockets erreichen, auch den API-Socket von tailscaled.
• TS-2026-017, falsche Capabilities über HTTP/2: Das betrifft Serve mit TLS (Transport Layer Security) und mindestens zwei Mounts mit unterschiedlichen Capability-Anforderungen. Ein Mount konnte die Werte im Header Tailscale-App-Capabilities eines anderen Mounts bekommen.

Ein Pi, den Sie nur mit normalem OpenSSH über Tailscale erreichen und auf dem kein tailscale serve läuft, erfüllt nach diesen Bulletins keine der vier Voraussetzungen. Aktualisieren sollten Sie trotzdem, denn auch künftige Korrekturen kommen nur über neue Versionen.

Wie es um das Sicherheitsmodell von Tailscale insgesamt steht, beschreibt die Frage, wie sicher Tailscale ist. Dort geht es um das Grundprinzip: Der Koordinationsserver verteilt Schlüssel und Regeln, aber er hält nicht die Schlüssel, die Ihren Datenverkehr verschlüsseln.

Was bedeutet Tailnet Lock für die Angriffskette?

Der Bericht beschreibt eine vollständige Angriffskette. Von Anfang bis Ende vorgeführt hat er sie nur in der Standardeinstellung, also mit ausgeschaltetem Tailnet Lock. Auf Tailnets mit aktivem Tailnet Lock wurden laut Bericht das Disable-Secret und Material der Signaturschlüssel unterwegs abgefangen. Die Sperre selbst wurde dort aber nicht abgeschaltet.

Tailnet Lock bedeutet: Ein neuer Knoten kommt nur ins Netz, wenn ein vertrauenswürdiges Gerät seinen Schlüssel signiert. Wie das funktioniert, erklärt Tailnet Lock einrichten und verstehen. Der Bericht empfiehlt außerdem: Wurde ein Gerät mit Signaturschlüssel kompromittiert, rotieren Sie die Sperre. Der Blogbeitrag von Tailscale zu den Befunden erwähnt Tailnet Lock nicht.

Was an Tailworm umstritten ist

Vier Punkte werden unterschiedlich dargestellt. Wir geben beide Seiten wieder und bewerten sie nicht.

• Ist es ein Wurm? Tailscale schreibt, die Befunde beschreiben keine Schadsoftware, die sich selbst von Maschine zu Maschine verbreitet. Treffender sei seitliche Bewegung (lateral movement) im Rahmen dessen, was die Richtlinie erlaubt. Der Bericht schreibt, im Labor sei eine automatisierte Ausbreitung auf jedes Gerät gemessen worden, das die Richtlinie zulässt. Beide Seiten nennen also dieselbe Grenze: Ihre SSH-Regeln.
• War die Offenlegung abgestimmt? Laut Tailscale kursierten erste Hinweise am Freitag, 23. Oktober. Tailscale erhielt den Bericht am Samstag, 24. Oktober, und die Forschenden veröffentlichten ihn zwei Stunden später. Der Bericht vertritt die Auffassung, dass die Infrastruktur schon heute angreifbar ist. Er dankt Tailscale zugleich für eine schnelle und inhaltliche Reaktion.
• Gibt es eine CVE? Stand 29. Oktober 2026 nennen weder die vier Bulletins noch der Bericht eine CVE-Nummer. Tailscale nutzt eigene Kennungen im Format TS-2026-xxx. Eine CVE kann später noch vergeben werden.
• Hat jemand die Befunde nachgestellt? Der Bericht sagt, alle Befunde seien in einer Laborumgebung mit unveränderter, veröffentlichter Software reproduziert worden. Das ist die eigene Prüfung der Forschenden. Eine unabhängige Reproduktion haben wir nicht gefunden. Mit den vier Bulletins bestätigt Tailscale aber, dass die darin beschriebenen Probleme echt waren und behoben sind.

Schritt 1: Prüfen Sie die Version auf jedem Knoten

Holen Sie sich zuerst die Liste Ihrer Geräte, dann prüfen Sie jedes einzeln:

tailscale status
tailscale version

tailscale status zeigt die Geräte, die dieser Knoten im Tailnet sieht. tailscale version gibt die Version des lokalen Clients aus. Die Frage für jedes Gerät lautet: Ist die Versionsnummer 1.104.4 oder höher? Prüfen Sie wirklich jedes Gerät, auch den Laptop und das NAS. Auf dem Handy finden Sie die Version in den Einstellungen der App.

Schritt 2: Aktualisieren Sie aus dem Paket-Repository von Tailscale

Die Quelle für das Update ist das Repository des Tailscale-Projekts unter pkgs.tailscale.com. Am 29. Oktober 2026 führt der stabile Zweig dort die Version 1.104.4 als neueste. Debian, Ubuntu und Raspberry Pi OS binden es mit einem Schlüssel unter /usr/share/keyrings und einer Quellliste unter /etc/apt/sources.list.d/ ein.

Prüfen Sie zuerst, woher Ihr Paket kommt:

apt policy tailscale

Achten Sie auf zwei Dinge. Steht bei der Quelle pkgs.tailscale.com? Und welche Version ist als Kandidat (Candidate) eingetragen? Kommt das Paket aus einer anderen Quelle, kann es dem Release hinterherhinken. Stimmt die Quelle, aktualisieren Sie nur dieses eine Paket:

sudo apt update
sudo apt install --only-upgrade tailscale
tailscale version

Auf Fedora und RHEL kommt Tailscale aus einem dnf-Repository desselben Servers. Dort heißt der Befehl sudo dnf upgrade tailscale. Ist das Repository noch gar nicht eingerichtet, nutzen Sie das offizielle Installationsskript aus der Tailscale-Dokumentation:

curl -fsSL https://tailscale.com/install.sh | sh

Prüfen Sie danach erneut mit tailscale version. Erst diese Ausgabe zählt, nicht die Meldung des Paketmanagers.

Synology und QNAP

Auf einer Synology ist die Version im Paket-Zentrum laut Tailscale nicht mehr unterstützt. Sie zeigt auch nicht den neuesten Stand. Tailscale empfiehlt, das SPK-Paket manuell von pkgs.tailscale.com zu installieren. Dort liegen SPK-Dateien in 1.104.4 für DSM 6 und DSM 7. Für spätere Updates beschreibt die Doku eine geplante Aufgabe in DSM, die täglich als root tailscale update --yes ausführt.

Auf einem QNAP nennt Tailscale das App Center den empfohlenen Weg. Die Version dort kann dem Release aber hinterherhinken. Das manuelle QPKG-Paket steht auf pkgs.tailscale.com in Version 1.104.4-1 bereit. Welche Version das App Center heute anbietet, haben wir nicht geprüft. Sehen Sie dort nach: Zeigt es 1.104.4 oder höher? Wenn nicht, installieren Sie das QPKG von Hand.

Schritt 3: Wenn das Update noch nicht geht

Manchmal geht ein Update nicht sofort, etwa auf einem Gerät, das Sie gerade nicht neu starten dürfen. Dann haben Sie zwei Wege.

Weg A: SSH-Weiterleitung abschalten. Die Umgebungsvariable TS_SSH_DISABLE_FORWARDING=1 schaltet die Weiterleitung in Tailscale SSH ab, ohne Tailscale SSH selbst abzuschalten. Tailscale schrieb am 27. Oktober, das entschärfe mehrere der ernsteren Befunde. Im Quellcode von 1.104.4 wird die Variable in allen vier Weiterleitungs-Pfaden geprüft, vor den Flags aus der Richtlinie. Ab welcher älteren Version sie existiert, haben wir nicht geprüft.

Nehmen Sie keinen Pfad an. Fragen Sie systemd, welche Datei es wirklich liest:

systemctl cat tailscaled

Suchen Sie die Zeile, die mit EnvironmentFile= beginnt. In der Unit-Datei des Projekts steht /etc/default/tailscaled. Pakete anderer Distributionen können abweichen. Tragen Sie die Variable in genau diese Datei ein und starten Sie den Dienst neu. Ersetzen Sie den Pfad, falls Ihre Ausgabe einen anderen zeigt:

echo 'TS_SSH_DISABLE_FORWARDING=1' | sudo tee -a /etc/default/tailscaled
sudo systemctl restart tailscaled

Der Neustart unterbricht kurz alle Verbindungen über Tailscale. Auf einem entfernten VPS arbeiten Sie dafür besser über eine Verbindung, die nicht über Tailscale läuft. Prüfen Sie dann, ob der laufende Prozess die Variable wirklich hat:

sudo cat /proc/$(pidof tailscaled)/environ | tr '\0' '\n' | grep TS_SSH

Gibt der Befehl TS_SSH_DISABLE_FORWARDING=1 aus, ist die Variable aktiv. Bleibt die Ausgabe leer, steht sie in der falschen Datei, oder der Neustart fehlt.

Weg B: Tailscale SSH dort abschalten, wo Sie es nicht brauchen.

sudo tailscale set --ssh=false

Danach nimmt dieser Knoten keine Tailscale-SSH-Sitzungen mehr an. Auf einem gemieteten VPS sperren Sie sich damit aus, wenn kein normales OpenSSH läuft. Testen Sie deshalb vorher eine OpenSSH-Anmeldung mit Schlüssel in einer zweiten Sitzung. Wie Sie OpenSSH selbst absichern, steht in der Anleitung zur SSH-Härtung auf dem VPS.

Weg A hilft gegen TS-2026-014, Weg B gegen beide SSH-Bulletins. Gegen TS-2026-016 und TS-2026-017 helfen sie nicht, denn diese betreffen tailscale serve. Tailscale selbst empfahl am 27. Oktober ausdrücklich nicht, Tailscale SSH überall abzuschalten. Es rät stattdessen, die SSH-Regeln zu prüfen und einzuschränken. Für sensible Systeme empfiehlt es den Check-Modus.

Schritt 4: Prüfen Sie tailscale serve auf Unix-Socket-Backends

tailscale serve status

Der Befehl zeigt, was dieser Knoten über Serve anbietet. Die Frage lautet: Zeigt ein Eintrag auf einen Dateipfad, also einen Unix-Socket, statt auf eine Adresse mit Port wie 127.0.0.1:8080? Genau solche Backends betrifft TS-2026-016. Laut Changelog beschränkt 1.104.4 TCP-Weiterleitungen auf Unix-Socket-Backends und prüft den Backend-Pfad bei jeder Verbindung neu.

Eine Voraussetzung für diese Lücke ist ein lokaler Benutzer, der Serve konfigurieren darf. Das ist neben root der Operator, den Sie mit --operator festlegen. Wer Operator ist, kann ohne sudo tailscale serve und sogar tailscale set --ssh=true ausführen. Lesen Sie dazu was der Operator in Tailscale darf und wann Sie ihn setzen. Fragen Sie sich dann, ob dieses Recht auf jedem Gerät noch nötig ist.

Eine weitere Angriffsmöglichkeit sind beschreibbare Backend-Pfade. Prüfen Sie für jeden Socket aus tailscale serve status die Rechte entlang des ganzen Pfads. Ersetzen Sie den Beispielpfad durch Ihren:

namei -l /run/meine-app/app.sock

namei -l zeigt Besitzer und Rechte jedes Verzeichnisses bis zur Datei. Darf ein normaler Benutzer in eines dieser Verzeichnisse schreiben, kann er den Socket austauschen. Welche Serve-Befehle es gibt und wie Sie Einträge wieder entfernen, finden Sie im Spickzettel zum Befehl tailscale serve.

Schritt 5: Fassen Sie die SSH-Regeln enger

Die SSH-Regeln stehen im Abschnitt ssh Ihrer Tailnet-Richtlinie. Laut Doku kennt eine Regel die Felder action, src, dst, users, checkPeriod, acceptEnv und srcPosture. Je enger die Regel, desto kleiner die Reichweite eines übernommenen Geräts. Ziel ist ein Paar aus genau einer Quelle und genau einem Ziel:

"ssh": [
  {
    "action": "check",
    "src": ["alice@example.com"],
    "dst": ["tag:nas"],
    "users": ["admin"]
  }
]

Diese Regel erlaubt nur Alice den Zugang. Sie gilt nur für Geräte mit dem Tag tag:nas und nur für den Benutzer admin. Mit check statt accept muss Alice sich regelmäßig erneut anmelden, standardmäßig alle zwölf Stunden. Tailscale SSH kennt übrigens keinen frei wählbaren Port, nur Port 22 ist erlaubt.

Kann man Weiterleitung pro Regel abschalten? Der Bericht rät Nutzern des gehosteten Dienstes dazu. Der Client-Code von 1.104.4 liest auch tatsächlich Flags für lokale und entfernte Weiterleitung aus der SSH-Aktion. In der Doku zur Richtlinien-Syntax und zu Tailscale SSH haben wir eine solche Einstellung aber nicht gefunden. Prüfen Sie die aktuelle Tailscale-Doku selbst, bevor Sie sich darauf verlassen. Bis dahin ist TS_SSH_DISABLE_FORWARDING=1 der Weg, den Tailscale selbst genannt hat.

Schritt 6: Löschen Sie ein kompromittiertes Gerät im Control Plane

Ein Gerät, dem Sie nicht mehr trauen, entfernen Sie in der Admin-Konsole: Machines, dann das Menü des Geräts, dann Remove und Remove machine. Laut Tailscale verliert das Gerät sofort die Verbindung zu allen Ressourcen im Tailnet. Dafür brauchen Sie die Rolle Owner, Admin oder IT admin.

Die Reihenfolge ist wichtig. Den Client zu deinstallieren entfernt das Gerät nicht aus dem Tailnet. Laut Bericht widerruft auch eine Neuinstallation des Systems keine kopierten Schlüssel. Löschen Sie das Gerät also zuerst in der Konsole und installieren Sie danach neu. Ist die Geräte-Freigabe (device approval) aus, warnt Tailscale: Das Gerät kann ohne erneute Zustimmung eines Admins wieder hinzukommen. Für Server-Flotten empfiehlt der Bericht zusätzlich, dass Knotenschlüssel ablaufen.

headscale: Was gilt für den selbst gehosteten Control Server?

headscale ist ein quelloffener Ersatz für den Koordinationsserver von Tailscale, den Sie selbst betreiben. Den Aufbau beschreibt headscale als selbst gehostete Tailscale-Alternative. Für Tailworm gilt dort Folgendes.

headscale v0.29.7 vom 30. Oktober 2026 behebt Befunde aus dem Tailworm-Bericht. Die Release-Notes von v0.29.6 nennen Go 1.27.3, Updates von Abhängigkeiten wegen HTTP/2 und eine Tailscale-Bibliothek in Version v1.102.0. Tailworm und SSH-Weiterleitung kommen darin nicht vor. Aktualisieren Sie headscale auf v0.29.7 und jeden Client auf 1.104.4 oder neuer.

Die SSH- und Serve-Korrekturen stecken im Client. Aktualisieren Sie deshalb auch mit headscale jeden Client auf 1.104.4 oder neuer. headscale v0.29.6 verlangt mindestens Client v1.80.0, 1.104.4 liegt also darüber. Ob 1.104.4 mit headscale 0.29.x fehlerfrei zusammenarbeitet, haben wir nicht getestet.

Der Bericht behauptet außerdem, dass headscale v0.29.5 Weiterleitung bei jeder akzeptierten Sitzung ohne Bedingung gewährt. Er rät deshalb, jede SSH-Freigabe in headscale wie root-Zugriff auf das Ziel zu behandeln. Die headscale-Doku zur Richtlinie sagt nichts über Weiterleitungs-Optionen. Bestätigen oder widerlegen konnten wir die Aussage daher nicht. Die Umgebungsvariable aus Schritt 3 wirkt im Client. Der Client in Version 1.104.4 prüft sie vor den Flags, die vom Server kommen.

Ein kompromittiertes Gerät löschen Sie in headscale mit dem CLI. headscale nodes list zeigt die IDs, und headscale nodes delete -i <ID> entfernt den Knoten.

Welche der 11 Befunde sind behoben, welche offen?

Tailscale ordnet die Befunde nicht selbst den Bulletins zu. Die folgende Zuordnung ist unsere, abgeleitet aus dem Text der Bulletins. Die Nummern sind die des Berichts.

• Befunde 1 bis 3 (lokale und entfernte Socket-Weiterleitung als root, ein Wettlauf gegen die Pfad-Freigabeliste): TS-2026-014, behoben in 1.104.4.
• Befund 5 (Speicher in SSH-Sitzungen): TS-2026-015, behoben in 1.104.4.
• Befunde 7 und 8 (serve --tcp erreicht die lokale Admin-API, Unix-Socket-Schutz nur beim Konfigurieren geprüft): TS-2026-016, behoben in 1.104.4.
• Befund 11 (geteilter HTTP/2-Kontext gibt Capabilities weiter): TS-2026-017, behoben in 1.104.4.

Für die übrigen Punkte nennt der Bericht folgenden Stand:

• Befund 4, App-Connectors: Der Bericht markiert ihn als teilweise behoben: Zugriffe auf interne Netze und Metadaten sind auf main blockiert, öffentlicher Internetzugang bleibt vorgesehen. Pull Request #22003 wurde am 29. Oktober 2026 in main zusammengeführt; die Änderungen sind noch nicht veröffentlicht. Tailscale sagt, es gehe um conn25, die nächste Generation der App-Connectors. Diese sei noch nicht veröffentlicht, und die heute verfügbaren stabilen App-Connectors seien nicht betroffen. Hier widersprechen sich die Seiten.
• Befund 6, Speichererschöpfung in headscale und im DERP-Client: DERP (Designated Encrypted Relay for Packets) sind die Relay-Server von Tailscale. Der Bericht markiert ihn als behoben in Tailscale v1.104.4 zusammen mit headscale v0.29.7. Die Headscale- und DERP-Korrekturen stehen damit nicht mehr aus. Der Blog von Tailscale sagt zu DERP nichts.
• Befund 9, Funnel-Berechtigung nur im CLI und in der lokalen Konfiguration geprüft: Der Bericht nennt ihn offen. Tailscale nennt ihn erwartetes Verhalten, denn er setzt lokale Admin-Rechte voraus.
• Befund 10, TS_SERVE_ALLOW_ALL_INTERFACES: Laut Bericht dokumentiert, eine Änderung ist nicht geplant. Für Tailscale ist es ebenfalls erwartetes Verhalten, weil man die Option bewusst einschalten muss.

Die früheren SSH-Bulletins aus 2026

Tailworm ist nicht die erste SSH-Lücke dieses Jahres. Zwei frühere Bulletins sind für alte Geräte wichtig:

• TS-2026-004 vom 3. Juni 2026: Die SSH-Weiterleitung von Unix-Sockets beachtete die Rechte von Symlinks nicht. Behoben in 1.98.9 oder neuer.
• TS-2026-009 vom 13. Juli 2026: Benutzernamen mit führendem Bindestrich konnten root-Zugriff entgegen den Regeln geben. Betroffen waren Linux-Systeme, die sich auf autogroup:nonroot verlassen. Behoben in 1.98.9 oder neuer.

Wer auf 1.104.4 ist, hat beide Korrekturen. Zeigt tailscale version eine Nummer unter 1.98.9, fehlen dem Gerät auch die Korrekturen aus Juni und Juli.

FAQ

Ist Tailscale nach Tailworm noch sicher?

Tailscale hat vier Security-Bulletins zu den bestätigten Befunden veröffentlicht. Laut Bericht sind sieben der 11 Befunde in Version 1.104.4 behoben; Befund 6 ist mit 1.104.4 zusammen mit headscale v0.29.7 ebenfalls behoben. Ausnutzen kann sie laut Tailscale nur, wer schon ein autorisiertes Gerät in Ihrem Tailnet kontrolliert. Auch dann trifft es nur Ziele, zu denen Ihre Richtlinie SSH erlaubt. Aktualisieren Sie jeden Client auf 1.104.4 oder neuer und fassen Sie Ihre SSH-Regeln eng. Für headscale aktualisieren Sie auch den Server auf v0.29.7. Bei App-Connectors ist Befund 4 teilweise behoben; Befund 9 zu Funnel bleibt laut Bericht offen, für Befund 10 ist keine Änderung geplant.

Muss ich Tailscale SSH jetzt abschalten?

Nein, Tailscale empfiehlt das ausdrücklich nicht für alle. Nach dem Update auf 1.104.4 sind die bestätigten SSH-Lücken geschlossen. Geht das Update noch nicht, setzen Sie TS_SSH_DISABLE_FORWARDING=1 in die Datei, die systemctl cat tailscaled unter EnvironmentFile= nennt. Starten Sie danach tailscaled neu. Die Variable entschärft die Weiterleitungs-Befunde, schützt aber nicht vor der Speichererschöpfung aus TS-2026-015. Auf Geräten ohne Bedarf schaltet sudo tailscale set --ssh=false Tailscale SSH ab. Prüfen Sie aber vorher Ihren OpenSSH-Zugang.

Bin ich betroffen, wenn ich nur normales OpenSSH über Tailscale nutze?

Die Bulletins TS-2026-014 und TS-2026-015 betreffen Tailscale SSH, also den SSH-Server im Tailscale-Client, nicht OpenSSH. Die Bulletins TS-2026-016 und TS-2026-017 betreffen tailscale serve. Nutzen Sie weder Tailscale SSH noch Serve, trifft keine der vier Voraussetzungen zu. Ein Update auf 1.104.4 ist trotzdem sinnvoll.

Schützt mich headscale vor den Tailworm-Lücken?

Nein. headscale v0.29.7 vom 30. Oktober 2026 behebt eigene Tailworm-Befunde. Die SSH- und Serve-Korrekturen liegen im Tailscale-Client. Deshalb müssen auch Clients an einem headscale-Server auf 1.104.4 oder neuer. Aktualisieren Sie zusätzlich den headscale-Server auf v0.29.7. Der Bericht behauptet, headscale v0.29.5 erlaube SSH-Weiterleitung ohne Bedingung. Er rät deshalb, jede SSH-Freigabe dort wie root-Zugriff zu behandeln.

Gibt es eine CVE-Nummer für Tailworm?

Stand 29. Oktober 2026 nennen weder die Tailscale-Bulletins noch der Tailworm-Bericht eine CVE-Nummer. Tailscale führt die Lücken als TS-2026-014, TS-2026-015, TS-2026-016 und TS-2026-017. Suchen Sie in Scannern und Ticketsystemen deshalb nach diesen Kennungen oder nach der Version 1.104.4.