Tailscale SSH 未修補漏洞：一台被入侵的裝置能橫向取得整個網格的 root

發生了什麼

後續更新（2026-10-28）：Tailscale 已釋出 1.104.4 版本修補這些漏洞，包含 4 個安全公告（TS-2026-014 至 TS-2026-017）。修補方法為將 forwarding 操作改為以登入使用者身分執行，而非 root。headscale 0.29.5 仍無修補版本。

想像一個企業網路標榜零信任：每台裝置都驗證身分、每個連線都檢查規則、不再依賴傳統 VPN 的邊界防禦。管理員在 Tailscale 設定了 SSH 存取規則，讓工程師能直接 SSH 到各台伺服器，不需管理每台機器的密碼或金鑰。規則寫得很寬鬆：「開發團隊可以連到所有開發環境伺服器」。

2026 年 10 月 25 日，安全研究員 Erica Windisch 發布 Tailworm 報告，證明這個設定的後果：攻擊者只需入侵網格內任何一台裝置（例如工程師的筆電），就能透過 Tailscale SSH 的 port forwarding 功能，在不到一秒內橫向取得存取規則允許的所有伺服器的 root 權限，不需要密碼、不需要竊取 SSH 金鑰。

報告測試了 Tailscale 1.104.2 與自架的 headscale 0.29.5，在實驗室中重現三種攻擊路徑。截至報導發布，Tailscale 官方未發布 CVE、未釋出修補版本、未發布安全公告。唯一的防禦是調整組態：關閉 port forwarding（headscale 0.29.5 無法關閉）、將 SSH 規則改寫為單一來源對單一目標。

來源：本文整理自 The Hacker News 於 2026 年 10 月 25 日發布的報導，原始研究為 Erica Windisch（Cyberdione Labs）的 Tailworm 報告。原文連結

Tailscale SSH 與傳統 SSH 的差異

傳統 SSH 驗證的是「人」：輸入密碼或提供 SSH 金鑰，伺服器確認你是誰。Tailscale SSH 驗證的是「裝置」：它辨識連線來自哪台裝置，存取控制規則（ACL）決定「這台裝置能不能 SSH 到那台伺服器」。

這個設計的好處是簡化管理：不用在每台伺服器上分發金鑰、不用管理使用者帳號，一切都在 Tailscale 的控制平面統一設定。但這也代表：只要攻擊者控制了網格內一台裝置，他就繼承了那台裝置的所有 SSH 權限。

報告強調：Tailscale 本身不會製造「第一個立足點」，攻擊者仍需透過傳統方式入侵第一台裝置（釣魚、弱密碼、軟體供應鏈攻擊、未修補漏洞）。但一旦拿下第一台，Tailscale SSH 的 port forwarding 功能就成為橫向移動的加速器。

三種攻擊路徑

Windisch 在實驗室證明三種從「普通使用者」提權到「root」的路徑，全部利用 Tailscale SSH 的 port forwarding 功能。

路徑一：root process 連接特權 socket

使用標準 SSH port forwarding，建立一個普通 SSH session。因為 Tailscale SSH 是由 root-level 的 Tailscale process 處理連線，這個 process 連接了「只有 root 能存取」的系統 socket。

報告寫道：實驗室中，這個動作「幾乎立即」讓測試取得 root 並讀取系統密碼檔，不需要管理員權限。

路徑二：替換 root 擁有的 socket

攻擊者將一個 root 擁有的 socket 替換為自己的 socket，讓 Tailscale process 連接到攻擊者控制的 socket。這允許「直接以 root 執行指令」針對特定服務。

路徑三：TOCTOU 競爭繞過路徑檢查，竊取裝置金鑰

第三種方法針對 Tailscale 的「檔案路徑檢查」做競爭攻擊（TOCTOU, Time-of-check to time-of-use）：系統檢查檔案路徑是否安全，與實際使用該路徑之間有時間差，攻擊者在這個間隙替換檔案。

報告證明這條路徑能走得更遠：竊取用來註冊新裝置的金鑰，然後用這把金鑰將攻擊者自己的機器加入網格，成為「可信任的伺服器」。

但這一步有限制：只在未啟用 Tailnet Lock 功能的網格上完整成功。啟用 Tailnet Lock 時，雖然金鑰在傳輸中被攔截，但最後一步無法完成。

「蠕蟲式」橫向移動

Windisch 將整體結果描述為「wormable」（可蠕蟲化）：在實驗室中，一台被入侵的裝置能擴散到存取規則允許的每一台裝置，不需密碼、不需竊取金鑰、不需使用者動作，每一步不到一秒。

報告的原文：「網格將一個普通立足點轉換為整個機群的特權存取，速度達到機器等級（machine speed）。」

但報告也指出兩件事能阻止擴散：

1. 單一來源對單一目標的存取規則（single source-to-destination pairs）：不寫「開發團隊可以連所有開發環境」，而是寫「這台筆電只能連那台伺服器」。報告稱這是實驗室中唯一能自行阻止擴散的控制。
2. 裝置金鑰綁定硬體：例如綁定 TPM 或 Secure Enclave，讓金鑰無法被複製離開裝置。

官方回應與揭露爭議

截至 The Hacker News 報導發布，Tailscale 官方未發布安全公告、未分配 CVE、未釋出修補版本。

Tailscale 工程副總裁 Mike Shaver 在 Reddit 回應：公司已收到報告、此前就在與外部安全專家調查相同領域、已發現一些問題並正在修復。他表示公司仍在釐清哪些組態受影響，並強調「不建議所有人關閉 Tailscale SSH」。

揭露流程也引發爭議。Windisch 在 Hacker News 留言表示這是「reported but not coordinated」（已通報但未協調），有評論者認為在未先通報 Tailscale 的情況下公開是不負責任的。

但 Windisch 向 The Hacker News 澄清：她在公開發布前一個週六就已將報告與概念驗證程式碼寄給 Tailscale 的安全聯絡窗口，也曾更早向公司執行長提出對架構的擔憂，並在公開前發布檔案雜湊並建議使用者關閉 Tailscale SSH。

不只 SSH：報告的其他 11 項發現

SSH 權限提升只是 Tailworm 報告中 11 項發現之一。報告還涵蓋 Tailscale 的 app connectors、serve 功能、裝置間的 DERP relay，以及自架的 headscale。

Windisch 向 The Hacker News 表示，SSH 權限提升「令人擔憂」，但 app connector 發現「對某些組織可能更有衝擊性」。

App connector 的發現針對一個實驗性功能 conn25：允許獲得權限的使用者發送流量到「資安團隊從未核准的目的地」，包括雲端供應商的 metadata service（可能洩漏伺服器憑證）。

這不是 Tailscale SSH 第一次出問題

報告是 Tailscale 在 2026 年「同一區域的一系列問題中最新一起」。

今年稍早，Tailscale 在 1.98.9 版本修補了數個 Tailscale SSH 與 server socket 處理的漏洞，其中一個就是「SSH Unix socket forwarding 可連接特權 socket」。

這顯示 Tailscale SSH 的權限邊界問題不是偶發，而是設計層面需要持續加固的區域。

如何避免

因為目前沒有修補版本，唯一的防禦是調整 Tailscale SSH 與相關功能的組態。報告與 Tailscale 官方的建議大部分重疊。

今天能做的緩解措施

1. 檢視 Tailscale SSH 存取規則，改寫為單一來源對單一目標

   不要寫「開發團隊可以連所有開發環境伺服器」（by identity or tag），而要寫成「這台裝置只能連那台伺服器」。報告稱這是測試中唯一能阻止橫向擴散的控制。

2. 關閉 SSH port forwarding（如果你的平台允許）

   • 在 Tailscale 官方託管服務：這是每條規則的設定，可以關閉。
   • 在 headscale 0.29.5：無法關閉。報告建議：在 headscale 上，每一條 SSH 授權都要當作「給對方 root」。

3. 移除不需要 app connector 的裝置權限

   避免實驗性功能 conn25 被用來繞過核准的目的地清單。

4. 移除任何指向 Unix socket 的 tailscale serve forward

   這類設定可能讓攻擊者連接特權 socket。

5. 啟用裝置金鑰過期機制（node-key expiry）

   讓竊取的裝置金鑰不會永久有效。

6. 若裝置被入侵，從控制平面刪除該裝置

   只是重灌機器不會撤銷金鑰，攻擊者可能已經將金鑰複製走。

Tailscale 另外建議的措施

• 啟用 SSH check mode：在 session 開始前增加登入步驟。報告指出這不會修補權限提升，只是在前面多一道關卡。
• 啟用自動更新：確保未來修補釋出時能快速套用。

headscale 使用者的處境更嚴峻

headscale 是 Tailscale 的開源、自架版本，讓企業能自行運行控制平面而非使用 Tailscale 官方託管服務。

報告測試的 headscale 0.29.5 版本無法關閉 SSH port forwarding。這代表在 headscale 上，目前沒有辦法從組態層面阻止這個攻擊路徑。

報告的建議很直接：在 headscale 上，每一條 SSH 授權都要當作「給對方那台伺服器的 root」。

你可以學到什麼

站在攻擊者的角度：Tailscale 網格給了一個很好的橫向移動平台。只要先拿下一台裝置（工程師筆電、CI/CD runner、任何在網格內的機器），存取規則允許的每一台伺服器都能在一秒內拿下 root。而且因為 Tailscale SSH 驗證的是裝置不是人，攻擊者不需要密碼、不需要偷 SSH 金鑰，只需要控制那台裝置。

如果你使用 Tailscale SSH

1. 今天就把存取規則改寫為單一來源對單一目標：不要用 tag 或 identity 做廣泛授權。
2. 如果你用官方託管服務，關閉 SSH port forwarding。
3. 如果你用 headscale 0.29.5，把每條 SSH 授權都當作給 root，並考慮暫時關閉 Tailscale SSH 或限縮規則到最小範圍。
4. 啟用裝置金鑰過期，考慮綁定硬體金鑰。
5. 持續追蹤 Tailscale 官方是否發布修補與安全公告。

目前沒有修補版本，組態是唯一的防線。