Исследовательница Эрика Виндиш из Cyberdione Labs описала уязвимости, которые, по её данным, могут позволить злоумышленнику с доступом к одному устройству получить права root на других серверах в сети Tailscale. Для атаки нужны два условия: на целевой стороне настроен Tailscale SSH с разрешённой переадресацией портов, а захваченное устройство допущено правилами доступа к этому серверу. Пароль или SSH-ключ пользователя на целевой машине похищать не требуется. Но первоначальный доступ к устройству атакующий должен получить сам — например, через уязвимое веб-приложение, заражённый пакет, фишинг или украденные учётные данные.
Виндиш опубликовала отчёт Tailworm 25 октября. В лаборатории она три дня проверяла Tailscale версии 1.104.2 и headscale версии 0.29.5. Headscale — сервер с открытым исходным кодом, который некоторые сети используют вместо облачного сервиса Tailscale. Описанные результаты получены в лаборатории: сообщений об атаках на реальные сети не было. На момент публикации Tailscale не выпустила бюллетень безопасности, у проблемы не было номера CVE и исправленной версии. Технические выводы основаны на отчёте Виндиш; публично их не воспроизвёл другой исследователь, а Tailscale не подтвердила конкретные утверждения. Код доказательства концепции, по словам исследовательницы, не публиковался и был передан только специалисту компании по безопасности.
У Tailscale SSH иная модель доступа, чем у обычного SSH-сервера: при подключении система проверяет устройство, а не пароль или ключ пользователя. Правило доступа определяет, может ли это устройство открыть SSH-сессию с конкретной целью. Поэтому, если злоумышленник уже контролирует разрешённую машину, он способен воспользоваться её правами — учётные данные пользователя целевого сервера для этого не нужны.
В отчёте описаны три способа эксплуатации. В первом обычная SSH-сессия заставляла процесс Tailscale, работающий с правами root, подключиться к системному сокету, доступ к которому должен быть только у администратора. В лабораторном тесте это сразу давало root и позволяло прочитать системный файл паролей. Во втором случае исследовательница подменяла сокет, принадлежащий root, на сокет под контролем атакующего, после чего можно было напрямую выполнять команды с правами root для некоторых служб. Третий способ обходил проверку безопасности при доступе через переадресацию портов: атакующий использовал разницу во времени между проверкой пути к файлу и его открытием.
В ходе третьего сценария удалось перехватить ключ для подключения новых устройств. С его помощью машина под контролем атакующего могла присоединиться к сети как доверенный сервер. Однако завершить этот этап удалось только при выключенном Tailnet Lock. Если защита была включена, необходимые секреты захватывались при передаче, но войти в сеть таким способом исследовательнице не удалось.
Виндиш назвала общую цепочку «способной распространяться как червь»: в лаборатории одно захваченное устройство могло переходить к другим машинам, доступным по правилам сети, без паролей, украденных пользовательских ключей и дополнительных действий владельцев. Каждый шаг занимал менее секунды. В отчёте риск сформулирован так: «Сеть превращает один обычный плацдарм в привилегированный доступ ко всему парку машин со скоростью компьютера». Это лабораторный результат, а не описание распространения вредоносной программы в реальных сетях. Некоторые исследователи усомнились, что слово «червь» здесь уместно; другие назвали получение root серьёзной проблемой.
По данным Виндиш, распространение ограничивали два фактора: правила, заданные отдельными парами «источник — цель», и привязка ключей устройства к аппаратным средствам защиты, например TPM или Secure Enclave. Майк Шейвер, вице-президент Tailscale по инженерным вопросам, ответил на Reddit, что компания получила отчёт и уже изучала те же области вместе с внешними специалистами по безопасности. Tailscale обнаружила проблемы, над исправлением которых работает, и продолжает выяснять, какие конфигурации затронуты. При этом Шейвер заявил, что компания «не рекомендует всем отключать Tailscale SSH».
Проблема с SSH — лишь одна из 11 находок в Tailworm. В отчёте также рассматриваются app connectors, функция serve, ретранслятор DERP и headscale. Виндиш сказала The Hacker News, что повышение привилегий через SSH «вызывает тревогу», но уязвимость app connector «для некоторых организаций может иметь более серьёзные последствия». Речь идёт об экспериментальной функции conn25: пользователь с разрешённым доступом мог направлять трафик к адресам, которые специалисты по безопасности не одобряли. Среди возможных целей — служба метаданных облачного провайдера, откуда иногда можно получить учётные данные сервера.
Обсуждение порядка раскрытия информации тоже стало частью истории. На Ycombinator HN Виндиш назвала раскрытие «сообщённым, но не согласованным». Один из комментаторов счёл публикацию до первого обращения к Tailscale безответственной. Отвечая The Hacker News, исследовательница заявила, что до открытого поста передала компании отчёт и код доказательства концепции, отправив их специалисту по безопасности в предшествующую субботу. Ранее она также обращалась к генеральному директору Tailscale с опасениями по поводу архитектуры сервиса, публиковала хеш файла и советовала пользователям отключить Tailscale SSH.
Это не первая проблема в той же области. Ранее, в 2026 году, Tailscale исправила несколько ошибок в Tailscale SSH и обработке серверных сокетов в версии 1.98.9. Среди них была уязвимость, позволявшая переадресации Unix-сокета через SSH добраться до привилегированного сокета.
Пока исправления для описанных в Tailworm проблем не было, администраторам стоит пересмотреть правила Tailscale SSH. Виндиш рекомендует задавать доступ отдельными парами: одно устройство-источник и одна целевая машина. Широкие разрешения по идентичности пользователя или тегу лучше убрать. На размещённом Tailscale сервисе переадресацию портов можно отключить для каждого правила; в headscale 0.29.5 такой настройки нет, поэтому автор отчёта советует считать каждое разрешение SSH фактической выдачей root-доступа на целевой машине.
Также рекомендуется убрать права app connector у устройств, которым они не нужны, удалить переадресацию
Виндиш опубликовала отчёт Tailworm 25 октября. В лаборатории она три дня проверяла Tailscale версии 1.104.2 и headscale версии 0.29.5. Headscale — сервер с открытым исходным кодом, который некоторые сети используют вместо облачного сервиса Tailscale. Описанные результаты получены в лаборатории: сообщений об атаках на реальные сети не было. На момент публикации Tailscale не выпустила бюллетень безопасности, у проблемы не было номера CVE и исправленной версии. Технические выводы основаны на отчёте Виндиш; публично их не воспроизвёл другой исследователь, а Tailscale не подтвердила конкретные утверждения. Код доказательства концепции, по словам исследовательницы, не публиковался и был передан только специалисту компании по безопасности.
У Tailscale SSH иная модель доступа, чем у обычного SSH-сервера: при подключении система проверяет устройство, а не пароль или ключ пользователя. Правило доступа определяет, может ли это устройство открыть SSH-сессию с конкретной целью. Поэтому, если злоумышленник уже контролирует разрешённую машину, он способен воспользоваться её правами — учётные данные пользователя целевого сервера для этого не нужны.
В отчёте описаны три способа эксплуатации. В первом обычная SSH-сессия заставляла процесс Tailscale, работающий с правами root, подключиться к системному сокету, доступ к которому должен быть только у администратора. В лабораторном тесте это сразу давало root и позволяло прочитать системный файл паролей. Во втором случае исследовательница подменяла сокет, принадлежащий root, на сокет под контролем атакующего, после чего можно было напрямую выполнять команды с правами root для некоторых служб. Третий способ обходил проверку безопасности при доступе через переадресацию портов: атакующий использовал разницу во времени между проверкой пути к файлу и его открытием.
В ходе третьего сценария удалось перехватить ключ для подключения новых устройств. С его помощью машина под контролем атакующего могла присоединиться к сети как доверенный сервер. Однако завершить этот этап удалось только при выключенном Tailnet Lock. Если защита была включена, необходимые секреты захватывались при передаче, но войти в сеть таким способом исследовательнице не удалось.
Виндиш назвала общую цепочку «способной распространяться как червь»: в лаборатории одно захваченное устройство могло переходить к другим машинам, доступным по правилам сети, без паролей, украденных пользовательских ключей и дополнительных действий владельцев. Каждый шаг занимал менее секунды. В отчёте риск сформулирован так: «Сеть превращает один обычный плацдарм в привилегированный доступ ко всему парку машин со скоростью компьютера». Это лабораторный результат, а не описание распространения вредоносной программы в реальных сетях. Некоторые исследователи усомнились, что слово «червь» здесь уместно; другие назвали получение root серьёзной проблемой.
По данным Виндиш, распространение ограничивали два фактора: правила, заданные отдельными парами «источник — цель», и привязка ключей устройства к аппаратным средствам защиты, например TPM или Secure Enclave. Майк Шейвер, вице-президент Tailscale по инженерным вопросам, ответил на Reddit, что компания получила отчёт и уже изучала те же области вместе с внешними специалистами по безопасности. Tailscale обнаружила проблемы, над исправлением которых работает, и продолжает выяснять, какие конфигурации затронуты. При этом Шейвер заявил, что компания «не рекомендует всем отключать Tailscale SSH».
Проблема с SSH — лишь одна из 11 находок в Tailworm. В отчёте также рассматриваются app connectors, функция serve, ретранслятор DERP и headscale. Виндиш сказала The Hacker News, что повышение привилегий через SSH «вызывает тревогу», но уязвимость app connector «для некоторых организаций может иметь более серьёзные последствия». Речь идёт об экспериментальной функции conn25: пользователь с разрешённым доступом мог направлять трафик к адресам, которые специалисты по безопасности не одобряли. Среди возможных целей — служба метаданных облачного провайдера, откуда иногда можно получить учётные данные сервера.
Обсуждение порядка раскрытия информации тоже стало частью истории. На Ycombinator HN Виндиш назвала раскрытие «сообщённым, но не согласованным». Один из комментаторов счёл публикацию до первого обращения к Tailscale безответственной. Отвечая The Hacker News, исследовательница заявила, что до открытого поста передала компании отчёт и код доказательства концепции, отправив их специалисту по безопасности в предшествующую субботу. Ранее она также обращалась к генеральному директору Tailscale с опасениями по поводу архитектуры сервиса, публиковала хеш файла и советовала пользователям отключить Tailscale SSH.
Это не первая проблема в той же области. Ранее, в 2026 году, Tailscale исправила несколько ошибок в Tailscale SSH и обработке серверных сокетов в версии 1.98.9. Среди них была уязвимость, позволявшая переадресации Unix-сокета через SSH добраться до привилегированного сокета.
Пока исправления для описанных в Tailworm проблем не было, администраторам стоит пересмотреть правила Tailscale SSH. Виндиш рекомендует задавать доступ отдельными парами: одно устройство-источник и одна целевая машина. Широкие разрешения по идентичности пользователя или тегу лучше убрать. На размещённом Tailscale сервисе переадресацию портов можно отключить для каждого правила; в headscale 0.29.5 такой настройки нет, поэтому автор отчёта советует считать каждое разрешение SSH фактической выдачей root-доступа на целевой машине.
Также рекомендуется убрать права app connector у устройств, которым они не нужны, удалить переадресацию
tailscale serve, ведущую к Unix-сокету, и включить срок действия ключей устройств. Если машина скомпрометирована, её следует удалить через управляющую консоль: переустановка системы не отзывает ключи, которые злоумышленник мог скопировать заранее. Tailscale также советует включить режим SSH check, требующий дополнительного входа перед началом сессии, и автоматические обновления. Режим check добавляет барьер, но саму эскалацию привилегий не устраняет.
