Tailscale Tailworm 漏洞報告解析：SSH 權限提升風險、影響前提與暫解措施

前言

Tailscale 的方便之處，是讓不同地點的電腦、NAS 與伺服器加入同一個受控網路。但當遠端管理功能本身出現權限問題，「連線有加密」能保護的範圍，就需要重新說清楚。

近期公開的 Tailworm 研究，讓 Tailscale SSH 的權限邊界受到關注。對管理者來說，現在最有用的工作是確認自己啟用了哪些功能、誰能連到正式主機，以及有哪些措施可以先降低風險。

查核日期：2026-10-26，台灣時間。 本文區分研究者主張、廠商回應與一般維運建議；本文未自行重現漏洞。封面為自行繪製的權限邊界示意圖，並非實際入侵紀錄。下方操作範例依公開文件整理，未在讀者環境執行。

一、先看廠商已經說了什麼

Tailscale 工程副總 Mike Shaver 在公開回應中表示，團隊已收到研究報告，先前也與外部安全專家獨立調查相關區域，已發現正在處理的問題，受影響配置仍在確認。回應指出，部分問題涉及已獲授權建立 SSH 連線後，工作階段可能取得超出所選本機帳號的能力；官方當時並未建議所有人一律停用 Tailscale SSH。Tailscale 工程主管回應

這個回應足以支持管理者立即檢查 SSH 授權與 forwarding 設定；完整受影響範圍、各項研究結論及正式修補版本，仍需繼續對照官方公告。

二、Tailscale SSH 與「透過 Tailscale 使用 SSH」差在哪裡？

兩種方法都可以在終端機輸入 ssh，但伺服器端實際接待連線的程式不同。辨認自己的部署，是判斷這次 SSH 問題是否適用的第一步。

使用方式	接待 SSH 連線的程式	主要認證與授權來源
Tailscale SSH	`tailscaled` 內建的 SSH 功能	Tailscale 裝置身分、tailnet 的 SSH 存取政策，可搭配 check mode
一般 SSH 經過 Tailscale 網路	主機上的 OpenSSH `sshd` 等服務	網路存取政策之外，再由 SSH 伺服器檢查金鑰、帳號與自身設定

官方文件說明，啟用 Tailscale SSH 後，來自 Tailscale 網路、送往該裝置連接埠 22 的 SSH 流量，會由這項功能處理。它可以免除個別散發 SSH 金鑰的工作，但也把更多認證與授權責任交給 Tailscale。Tailscale SSH 文件

如果你只使用 Tailscale 提供網路連線，伺服器仍由原本的 sshd 處理，就應沿著 OpenSSH 的設定檢查。官方另有透過 Tailscale 保護一般 SSH 的說明。這個區別能排除部分誤判；其他已啟用的 Tailscale 功能，仍需各自盤點。

三、Tailworm 報告涵蓋哪些風險？

研究者 Erica Windisch 公開的報告，列出 11 項觀察，測試對象為 Tailscale 1.104.2 與 headscale 0.29.5，實驗期間是 10 月 22 至 24 日。這些是報告的測試版本，不能直接當成完整受影響版本範圍。Tailworm 原始研究

報告包含不同元件，攻擊前提也不同。下表是研究者主張的精簡整理，並非廠商逐項確認的漏洞清單。

研究範圍	報告主張的問題	需要先具備的條件
Tailscale SSH	Unix socket forwarding 的權限與競爭條件可能造成提權	控制可通過目標 SSH 政策的來源裝置，且相關 forwarding 可用
實驗性的 `conn25` app connector	實際轉送目的地可能超出原先授權範圍	已獲使用該 connector 的權限
headscale 控制伺服器	資源耗盡與註冊流程阻斷	能接觸相關對外介面；依項目而異
DERP 用戶端	處理惡意 relay 回應時的記憶體耗盡	用戶端連向攻擊者控制的 relay
Serve／Funnel	特定 socket 轉送與授權處理風險	特定服務設定或可達的對應路徑

來源：Tailworm 報告的元件、條件與測試結果。

因此，盤點時要分開記錄「安裝套件」「啟用功能」「功能可被誰使用」三件事。單靠套件名稱，無法判斷一條具體攻擊路徑是否存在。

四、為什麼一般使用者的 SSH 連線，會碰到 root 權限？

理解這類風險，可以把遠端管理拆成三道邊界：

裝置身分：連線來自哪一台裝置？
SSH 授權：這個來源能否以指定帳號登入目標？
作業系統權限：登入後的操作，是否受該帳號的權限限制？

研究中特別關注 Unix domain socket forwarding：如果高權限常駐程式代替一般工作階段操作本機資源，權限檢查就必須正確保留呼叫者的限制。研究中的 SSH socket 分析

Unix socket 是本機程式之間的通訊入口。某些入口的權限很高，例如傳統 rootful Docker daemon 的控制 socket。Docker 官方提醒，能控制 daemon 的人可能影響主機檔案系統，因此這類存取只能交給可信任的使用者。Docker daemon 安全面

從工程角度來看，關鍵在於：代理程式替使用者做事時，是否帶著過大的權限。 即使登入的帳號沒有 sudo，代理路徑也必須維持同樣的限制。單純把 SSH 政策中的帳號從 root 改成一般帳號，不能代替對代理操作的修補。

同理，加密通道負責保護傳輸資料；通道另一端的程式，仍需正確執行權限檢查。這兩層要分別驗證。

五、目前可以先做什麼？

處置順序應配合用途。以 SSH 維運正式主機的團隊，先確認管理通道與授權；使用 connector 或 Serve 的團隊，則另外檢查相關功能，避免把一項 SSH 設定當成所有問題的解法。

不需要 SSH forwarding，就先關閉

Mike Shaver 更新後的回應，提供了具體暫解措施：在 tailscaled 服務的環境設定 TS_SSH_DISABLE_FORWARDING=1，再重新啟動服務。官方表示，這能緩解數項較嚴重的發現，同時保留 Tailscale SSH 本身。官方回應與設定修正說明

在 Tailscale 1.104.2 的 SSH 原始碼中，也能核對這個環境變數與 forwarding 檢查。

以下以 Linux、systemd、服務名稱為 tailscaled.service 的安裝為例。請先確認有雲端主控台、實體終端或其他可用管理通道；重啟網路代理可能中斷目前的遠端工作階段。

先開啟服務的 drop-in 設定：

1	sudo systemctl edit tailscaled.service

加入以下內容並儲存，保留原本需要的其他設定：

1 2	[Service] Environment="TS_SSH_DISABLE_FORWARDING=1"

接著重新載入設定並重啟服務：

1
2
3

sudo systemctl daemon-reload
sudo systemctl restart tailscaled.service
sudo systemctl show tailscaled.service --property=Environment

最後一行用來檢查 systemd 記錄的環境設定；它不能單獨證明 forwarding 已被阻擋。仍要以受控測試確認必要的登入可用、原本可用的 forwarding 已被拒絕。drop-in 與環境設定語法分別見 systemctl 與 systemd.exec。

只在目前 shell 執行 export，不會自動改變已由 systemd 啟動的服務。容器或其他服務管理方式，則應把環境變數加入實際啟動 tailscaled 的設定；使用 headscale 時，也要找真正接待 SSH 的節點代理。

這個開關是 forwarding 暫解措施。對 app connector、控制伺服器或其他功能，仍需採取各自適用的處理方式。

完全不需要 Tailscale SSH，可停用該功能

官方文件提供以下指令：

1	sudo tailscale set --ssh=false

這會停用裝置上的 Tailscale SSH。執行前要先確認替代管理方式；停用後是否能改由一般 OpenSSH 接待連線，也取決於 sshd、金鑰及網路政策是否已正確設定。停用 Tailscale SSH 文件

保留 SSH 時，收斂可以到達的範圍

建議把授權檢查落到實際情境：哪些人的哪些裝置，能以哪個帳號連到哪些正式主機？開發環境、CI worker 與正式管理節點，應依工作需求分開評估。

需要互動式管理的高風險連線，可考慮 check mode，要求重新驗證身分。不過它保護的是進入工作階段的關卡，無法修補進入後的權限處理問題；要求每次驗證也可能影響自動化工作，需先確認使用方式。Tailscale SSH check mode

另外，記錄 Serve 的轉送目標、connector 的使用者與出口限制，以及自架控制服務的暴露範圍。這份功能清單，後續可以直接拿來對照正式公告。

六、更新到 1.104.2 就解決了嗎？

截至本文查核日，官方 changelog 列出的 1.104.2 發布於 10 月 21 日，其中的安全相關更新，是處理遭洩漏的 TLS 中繼憑證信任問題。這與後續 Tailworm 研究的 SSH 主張需要分開追蹤。Tailscale 1.104.2 changelog、官方安全公告

本文未查得能逐項對應 Tailworm 的完整正式修補版本表。 升級到平台目前提供的穩定版本仍有價值，但完成紀錄應寫清楚：安裝了哪個版本、對應哪份公告、涵蓋哪些問題，以及服務是否已重新載入。

也要留意開發分支與正式套件的差別。看到修補程式碼或合併紀錄之後，還要確認它是否已進入自己使用的平台與發行管道。