Если вы self-hostите на VPS, Tailscale SSH наверняка внутри вашего ежедневного цикла: никаких ключевых пар под присмотром, никаких authorized_keys, между машинами WireGuard, доступ решает политика tailnet’а, а не файлы паролей.[6] На этой неделе этот удобный инструмент - под security-адвизори. 26 октября Tailscale опубликовала update об расследовании Tailscale SSH, подтвердив, что большинство найденных проблем касаются privilege escalation: в некоторых случаях пользователь, уже авторизованный для подключения по Tailscale SSH, может выполнять действия за пределами прав своего сконфигурированного локального пользователя - вплоть до получения повышенных привилегий.[1] 28 октября вышел патченный клиент v1.104.4 (01:05 UTC), а обещанный адвизори появился на странице security-bulletins как TS-2026-014 – TS-2026-017.[2][3]

Это момент «проверьте свои машины на этой неделе», а не «сносите всё»: Tailscale прямо пишет, что не рекомендует всем отключать Tailscale SSH.[1] Сначала короткая версия, потом детали.

  • Обновите клиент на каждой ноде до v1.104.4 или новее - все четыре новых бюллетеня закрываются «этой версией или новее».[2][3]
  • Пока не обновились - временная мера: задайте TS_SSH_DISABLE_FORWARDING=1 в окружении сервиса tailscaled и перезапустите его. Это отключает SSH forwarding, не отключая Tailscale SSH целиком, и митигирует несколько самых серьёзных находок.[1][2]
  • Пересмотрите SSH access policies и на время расследования временно ужесточите доступ к чувствительным системам.[1]
  • Не отключайте Tailscale SSH массово по умолчанию. На машине, которой он действительно не нужен, tailscale set --ssh=false - легитимный выбор на уровне устройства; только сперва убедитесь, что у вас есть другой способ зайти.[6]

Что произошло, по порядку

  • 24–25 октября - публикация исследовательского отчёта Tailworm (Erica Windisch, Cyberdione Labs): 11 заявленных находок против Tailscale 1.104.2 и headscale 0.29.5; заглавный тезис - Tailscale SSH выполняет форвардинг Unix-сокетов с root-привилегиями, позволяя уже доверенной сессии дотянуться до root-only сокетов.[9] Пресса описала это как несогласованное раскрытие - детали ушли в публичное поле до выхода фикса.[8] Это комьюнити-репортинг, а не слова Tailscale - относитесь к заявлениям отчёта соответственно.
  • 26 октября - собственный update Tailscale: большинство найденных проблем касаются privilege escalation; фиксы для большинства проблем реализованы и проходят тестирование, патченный релиз клиента целят на конец вторника 27 октября.[1]
  • 28 октября, 01:05 UTC - выпущен v1.104.4. Предыдущий стабильный релиз - v1.104.2 (21 октября).[3]
  • 28 октября - обещанный адвизори опубликован на tailscale.com/security-bulletins: TS-2026-014 … TS-2026-017 закрывают находки расследования про SSH-форвардинг, исчерпание памяти и Tailscale Serve.[2] Остальные пункты отчёта (app connectors, relay, headscale) в адвизори не попали - Tailscale пишет, что продолжает проверку оставшихся находок, так что объём может измениться.[1][9]

Что подтвердила сама Tailscale

Класс проблемы - privilege escalation, а не удалённое неаутентифицированное вторжение. В некоторых случаях пользователь, уже авторизованный для подключения по Tailscale SSH, может выполнять действия за пределами прав своего локального пользователя, вплоть до повышенных привилегий.[1] Эксплуатация зависит от прав, выданных подключающемуся пользователю или устройству, от конфигурации системы и других условий; на момент update’а Tailscale ещё проверяла полный объём.[1] Фиксы для большинства проблем были готовы до релиза; патченная линия - клиент v1.104.4.[1][3]

Четыре новых бюллетеня

Бюллетень Что закрывает Кто затронут Худший случай
TS-2026-014 Unix-socket forwarding в Tailscale SSH давал пирам доступ к root-only сокетам пользователи с включённым Tailscale SSH, у которых access policies разрешают local или remote forwarding авторизованный пир с правом форвардинга достаёт root-only сокеты - Docker socket или локальный API tailscaled[2]
TS-2026-015 исчерпание памяти при обработке SSH-сессий (denial of service) ноды с запущенным SSH-сервером Tailscale; для срабатывания нужна аутентифицированная сессия, разрешённая политикой OOM-килл tailscaled - рвутся все Tailscale-подключения на ноде[2]
TS-2026-016 Unix-бэкенды tailscale serve доставали привилегированные сокеты ноды, где локальный оператор может писать конфиги serve, или локальные пользователи могут писать в настроенные пути бэкендов сырые байты прямо в локальный API tailscaled - полный захват ноды; root-контекстные диалы произвольных root-only сокетов[2]
TS-2026-017 общий HTTP/2-контекст serve отдавал неверные Tailscale-App-Capabilities между маунтами serve с TLS и двумя и более маунтами с разными требованиями к capabilities на одной ноде capabilities «перетекают» между приложениями; приложение, авторизующее по заголовку, может отдать запросы, которые не должно[2]

У всех четырёх одна строка фикса: «исправлено в Tailscale версии 1.104.4 или новее».[2] Обратите внимание на нумерацию: Tailscale ведёт их под собственными ID бюллетеней. CVE-номеров здесь нет и искать их не нужно - страница бюллетеней и есть авторитетный источник по затронутым конфигурациям и версиям.[2]

TS-2026-014 заслуживает вашего полного внимания. SSH-сервер Tailscale живёт внутри root-привилегированного процесса tailscaled и валидировал пути Unix-сокетов лексически, при этом выполняя сами операции от root. Это расхождение дало три бага: привилегированные диалы через local forwarding (ssh -L); замену сокета через remote forwarding (ssh -R) с удалением root-owned сокетов; и гонку, которая обходила allowlist путей, потому что ядро повторно резолвит пути уже после начальной проверки.[2] Вместе они убрали allowlist как границу безопасности: авторизованный пир с разрешённым форвардингом получал маршрут к root-only Unix-сокетам - например /var/run/docker.sock или локальному API-сокету самого tailscaled. Фикс выполняет форвардинг от имени аутентифицированного пользователя, а не root.[2]

Почему это бьёт именно по self-hosted

На dev-VPS есть два root-only сокета, которые важнее остальных:

  • Docker socket. Машина с Docker + Tailscale SSH с разрешённым форвардингом превращает «пира с SSH-доступом» в «пира с docker.sock» - а это root-эквивалент на хосте, потому что Docker CLI общается с демоном от root. TS-2026-014 называет Docker socket напрямую.[2]
  • Локальный API-сокет tailscaled. Тот самый сокет, с которым говорят команды tailscale CLI. Доступ к нему означает возможность переконфигурировать сетевой стек ноды удалённо - TS-2026-016 показывает эквивалентный исход для Serve (полный захват ноды через локальный API), и причина там та же: диалы в root-контексте.[2]

А TS-2026-015 - напоминание, насколько централен tailscaled: это привилегированный демон, владеющий сетевым состоянием ноды.[7] Одна исчерпывающая SSH-сессия может довести его до OOM-килла - и упадут все Tailscale-подключения на машине, не только SSH, пока демон не перезапустится.[2]

И это не первый заезд по этой дороге. Та же область Unix-socket форвардинга уже патчилась в этом году, в v1.98.9: TS-2026-004 (SSH-форвардинг сокетов не уважал симлинки, цель - тоже привилегированные сокеты вроде Docker), TS-2026-005 (Unix-таргеты Serve не были ограничены root), TS-2026-006 (числовой UID обходил root-ограничения в SSH ACL), TS-2026-009 (специально сформированное имя пользователя открывало root-сессию в обход политики).[2] Если вы пропустили ту линейку релизов - это второй толчок.

Шаг 1 - Узнайте, что стоит на каждой ноде

  • Admin console: откройте страницу Machines и посмотрите колонку Version. Серая стрелка - доступно обновление, красная - доступно security-обновление; есть и фильтр «Update available».[4]
  • На самой машине: tailscale version печатает версию клиента; добавьте --daemon, чтобы увидеть и версию демона, или --upstream, чтобы сравнить с последним релизом из pkgs.tailscale.com.[5]

Цель - v1.104.4 или новее. Всё, что ниже, - кандидат на обновление.[2][3]

Шаг 2 - Обновление

  • На Debian/Ubuntu (и Windows) быстрый путь - собственный апдейтеров Tailscale: sudo tailscale update. Команда update доступна на Ubuntu/Debian Linux и Windows начиная с клиента v1.36.[5]
  • Любую установку из пакетного менеджера можно обновить и самим менеджером пакетов; механизм авто-обновления Tailscale переиспользует тот способ, которым клиент был установлен.[4]
  • Не считайте, что авто-обновление уже вас спасло. Tailscale несколько дней мониторит релиз, прежде чем включить его в авто-обновления - «обычно проходит около недели после релиза, прежде чем машины начнут обновляться» (security-обновления могут применяться быстрее). Даже на tailnet’е с включённым авто-апдейтом проверяйте колонку Version, а не надейтесь.[4]
  • Docker: используйте tailscale/tailscale:stable и перезадеплойте контейнер. Авто-обновление внутри контейнера не переживает перезапуск, так что пинить старую версию образа здесь - ловушка; шагом обновления должен быть сам редеплой.[4]

Шаг 3 - Нет возможности патчить прямо сейчас? Временная мера

Если вы застряли на старом клиенте, официальная промежуточная рекомендация Tailscale - отключить только SSH forwarding:

sudo systemctl edit tailscaled
# редактор откроет /etc/systemd/system/tailscaled.service.d/override.conf
# добавьте:
[Service]
Environment=TS_SSH_DISABLE_FORWARDING=1

затем перезапустите демон:

sudo systemctl restart tailscaled
# проверка:
systemctl cat tailscaled | grep Environment

Переменная должна жить в окружении сервиса, а не в вашей shell - Tailscale формулирует прямо: «in the tailscaled service environment and restart the service».[1] Обычные SSH-сессии при этом работают как раньше, а выключается именно форвардинг - та самая функция, вокруг которой крутятся и TS-2026-014, и заглавные тезисы отчёта. По словам Tailscale, это митигирует несколько самых серьёзных находок.[1][2]

Если машине Tailscale SSH не нужен вообще - его можно выключить на конкретном устройстве: tailscale set --ssh=false. Только сперва убедитесь, что у вас есть другой способ доступа, иначе отрежете себе дверь.[6]

Шаг 4 - Чините политику, а не только версию

  • Форвардинг - это разрешение. Затронутая популяция TS-2026-014 описана точно: «пользователи с включённым Tailscale SSH, у которых access policies разрешают local или remote forwarding». Если в вашем рабочем процессе нет -L/-R поверх Tailscale SSH - уберите форвардинг из правил, а не полагайтесь только на переменную окружения.[2]
  • Ужимайте граф правил. Первая рекомендация Tailscale - пересмотреть SSH access policies и ограничить доступ пользователями и устройствами, которым он нужен; для чувствительных систем на время расследования - ужесточить.[1]
  • Используйте check mode для рискованных подключений. Tailscale SSH умеет требовать повторную аутентификацию для подключений под чувствительными пользователями (например, root) - дешёвая страховка ровно под сценарий «доверенный пир превышает права своего пользователя».[6]
  • Если у вас headscale: адвизори покрывает хостированный control plane Tailscale; отчёт Tailworm отдельно утверждает, что headscale 0.29.5 выдавал форвардинг на каждое принятое SSH-правило без переключателя в политике. Это заявление исследователя, а не Tailscale, и в адвизори его нет - но это причина операторам headscale внимательно следить за оставшимися находками.[9]

Что дальше

Адвизори вышел, но две обещанные вещи ещё впереди. Вслед за бюллетенем Tailscale обещала технический блог-пост с объяснением находок, первопричин и инженерных изменений - по состоянию на 28 октября он не опубликован, и именно на странице investigation-update Tailscale обещает разместить ссылки.[1] Полный объём находок ещё проверяется, оставшиеся пункты - в работе, так что страница бюллетеней может пополниться.[1][2] И для калибровки: пресса отмечает, что ни Tailscale, ни отчёт Tailworm не упоминают эксплуатацию в дикой природе по состоянию на 27 октября.[8]

Итог

  1. Обновите каждый клиент Tailscale до v1.104.4 или новее - через tailscale update, пакетный менеджер или редеплой образа с stable-тегом. Все четыре бюллетеня закрываются этой линией.[2][3][4]
  2. До обновления задайте TS_SSH_DISABLE_FORWARDING=1 в окружении сервиса tailscaled и перезапустите. SSH продолжит работать, а серьёзные находки митигируются.[1]
  3. Перестаньте выдавать форвардинг, которым не пользуетесь, и ужесточите SSH access policies - least privilege работает до следующего адвизори, а не после.[1][2]
  4. Не отключайте Tailscale SSH массово. Оценка Tailscale: отключать всё - не тот дефолт; дисциплинированная политика плюс патченный клиент - тот.[1]

Self-hosting означает, что ритм патчинга - ваш. Tailscale SSH - по-настоящему удобный способ заходить на VPS, и фикс здесь рутинный: сверить версии, поставить релиз и внимательно посмотреть, каким пирам вообще разрешено форвардить. Если вы чаще туннелируете сервисы на tailnet, чем заходите по SSH, - смежная поверхность разобрана в нашем гайде по self-hosted HTTP-туннелям: Funnel, reverse-туннели и что происходит с экспозицией, когда меняется модель доверия вендора.

Источники

  1. Tailscale - «Tailscale SSH: Investigation and remediation update» (опубликовано 26.10.2026; находки privilege escalation, промежуточные рекомендации, включая TS_SSH_DISABLE_FORWARDING=1, отсутствие рекомендации отключать Tailscale SSH). https://tailscale.com/ssh-investigation-update - checked 2026-10-28
  2. Tailscale - Security Bulletins (TS-2026-014, TS-2026-015, TS-2026-016, TS-2026-017 - фикс в v1.104.4 или новее; предыдущие TS-2026-004/005/006/009 - фикс в 1.98.9). https://tailscale.com/security-bulletins - checked 2026-10-28
  3. tailscale/tailscale на GitHub - релиз v1.104.4 (28.10.2026, 01:05 UTC; предыдущий стабильный v1.104.2 - 21.10.2026). https://github.com/tailscale/tailscale/releases - checked 2026-10-28
  4. Tailscale - «Update Tailscale» (колонка Version: серая/красная стрелка; тайминг авто-обновлений «обычно около недели»; рекомендация Docker-тега stable). https://tailscale.com/docs/features/client/update - checked 2026-10-28
  5. Tailscale - CLI reference (tailscale version с --daemon/--upstream; tailscale update доступна на Ubuntu/Debian и Windows с v1.36; --ssh по умолчанию false). https://tailscale.com/docs/reference/tailscale-cli - checked 2026-10-28
  6. Tailscale - «Tailscale SSH» (порт 22 для tailnet-трафика, check mode для высокорисковых подключений, tailscale set --ssh=false для отключения на устройстве). https://tailscale.com/docs/features/tailscale-ssh - checked 2026-10-28
  7. Tailscale - tailscaled daemon reference (привилегированный демон, выполняющий сетевую работу). https://tailscale.com/docs/reference/tailscaled - checked 2026-10-28
  8. SecurityWeek - «Tailscale Rushes Patches After Uncoordinated Disclosure of ‘Tailworm’ Flaws» (27.10.2026; детали ушли в публичное поле до фиксов; ни Tailscale, ни отчёт не упоминают эксплуатацию в дикой природе). https://www.securityweek.com/tailscale-rushes-patches-after-uncoordinated-disclosure-of-tailworm-flaws/ - checked 2026-10-28
  9. BreachNews - «Tailworm Flaws in Tailscale SSH Could Let Trusted Users Gain Root, Researcher Claims» (27.10.2026; детали отчёта Cyberdione Labs: 11 находок, тесты Tailscale 1.104.2 и headscale 0.29.5, тезис про форвардинг в headscale). https://breachnews.com/research/tailworm-tailscale-ssh-flaws-root-privilege-escalation/ - checked 2026-10-28