1. 事件概述
2026-10-25，Cyberdione Labs 研究者 Erica Windisch 公開名為「Tailworm」的報告，列出 11 項發現、分為五大類，測試對象為 Tailscale 用戶端 1.104.2 與自架控制伺服器 headscale 0.29.5，實驗期間為 10 月 22 日至 24 日，皆為實驗室環境測試，非對真實網路的攻擊。報告公開時沒有協調揭露的修補版本，也沒有 CVE 編號。Tailscale 工程副總 Mike Shaver 隨後在 Reddit 公開回應：公司已收到報告，且此前已與外部安全專家檢視相同領域、已發現正在修復的問題；目前仍在確認受影響的設定範圍，並未建議所有人停用 Tailscale SSH。
2. 攻擊成立的條件（理解本事件的關鍵）
Tailscale SSH 是內建於 tailscaled 的 SSH 伺服器，它以裝置身分與存取規則決定能否登入，不走傳統密碼或金鑰。Tailworm 的主要利用鏈需要同時滿足：
- 目標裝置有啟用 Tailscale SSH，且其 SSH 規則允許 port forwarding；
- 攻擊者已先控制 tailnet 內的一台裝置（例如透過有漏洞的 Web 應用、被污染的軟體套件、釣魚或竊得的登入資料）；
- 存取規則允許該裝置連向目標。
換言之，Tailscale 並不製造第一個立足點；它可能把一個小立足點放大成整個機隊的淪陷。研究者在實驗中展示，此傳播可自動化到每跳不到一秒，且不需要偷密碼或金鑰。實驗同時顯示，將存取規則收緊為單一來源對單一目標的成對授權，能有效阻止傳播，是研究者指出唯一在實驗中奏效的控制。
3. 十一項發現（依元件分組）
| # | 元件 | 內容概要 | 嚴重度（研究者評級） | 攻擊者需要的前置條件 |
|---|---|---|---|---|
| F1 | Tailscale SSH | 本地 socket 轉發（ssh -L）以 root 執行，可觸及僅 root 可用的 socket；實驗中取得 root 並讀取 /etc/shadow | 高 | 允許本地轉發的 SSH 規則 |
| F2 | Tailscale SSH | 遠端 socket 轉發（ssh -R）可取代 root 擁有的 socket，經命令 daemon 達成 root 程式碼執行 | 高 | 允許遠端轉發的 SSH 規則 |
| F3 | Tailscale SSH | 路徑檢查與實際使用之間的時間差（競態）可被擊敗，最終使流氓節點加入網路 | 高 | 一般 SSH 工作階段且允許轉發 |
| F4 | App connectors（conn25 實驗功能） | 取得 connector 資格的裝置可把流量導向任意目的地，包括雲端 metadata 服務與 Kubernetes 內部服務 | 高 | 一般 app 資格 |
| F5 | Tailscale SSH | 工作階段頻繁建立銷毀可使 root daemon 在迴圈中耗盡記憶體（7 秒約配置 536 MB） | 高 | 已驗證的 SSH 工作階段 |
| F6 | headscale 與 DERP 客戶端 | 未授權註冊可擠掉待審核的裝置加入；惡意 relay 可迫使客戶端讀取最高約 1.34 GB 資料 | 中高 | 可觸及 headscale 的網路存取，或惡意 relay |
| F7 | tailscale serve | 將 TCP 轉發指向本地 API socket，遠端 peer 可寫入本地 API，實驗中設定變更回傳成功，等於節點被接管 | 高 | 管理者設定的 serve 轉發，加上被允許的 peer |
| F8 | tailscale serve | 設定後被置換的 symlink 可擊敗 socket 防護，使 root 撥接至僅 root 可用的 socket | 中（範圍受限） | 對 backend 路徑目錄的本地寫入權 |
| F9 | Funnel | Funnel 存取僅取決於 peer 能力與本地設定，研究者列為威脅模型議題 | 中 | 已啟用 funnel 的節點 |
| F10 | tailscale serve | TS_SERVE_ALLOW_ALL_INTERFACES 設定會讓 serve 暴露於隧道綁定之外，研究者列為設定注意事項 | 設定註記 | 有設定該變數的節點 |
| F11 | tailscale serve | 共用 serve context 的競態可使一個掛載點的權限帶到另一個 | 中（無標頭授權時低中） | 使用標頭式授權的 serve 設定 |
注：F3 鏈的最後一步（加入流氓節點）在有啟用 Tailnet Lock 的網路上無法完成，但過程所需的祕密仍在傳輸中被擷取；F6 中 headscale 在 0.29.5 無法關閉 SSH forwarding，研究者建議在其修補前，應將每一條 headscale 的 SSH 授權視為等同授予 root 存取。
4. 廠商回應與揭露過程的出入
社群流傳版本稱研究者「未先通知廠商即直接公開」，此說法與媒體報導有出入：The Hacker News 報導 Tailscale 已收到該報告，研究者亦表示其概念驗證程式碼僅提供給 Tailscale、未公開，他人尚無法公開重現其結果。截至 2026-10-26 查核時，Tailscale 的安全公告頁面尚無針對本報告的新公告，最新版本仍為被測試的 1.104.2。Tailscale 對外建議使用者檢視存取規則，並考慮啟用 SSH check mode；但研究指出 check mode 只是多加一層登入步驟，並不修復權限提升問題本身。
5. 自我檢查清單（讀者可自行對照）
- 確認是否真的有在用 Tailscale SSH。若用的是傳統 OpenSSH 透過 Tailscale 隧道連線（以 SSH 金鑰登入），與 Tailscale SSH 是不同機制，本報告的主要利用鏈不適用；在主機上可用
tailscale debug prefs查看 RunSSH 是否為 true，或以tailscale set --ssh=false關閉（關閉前務必先確認還有其他方式能連上該主機）。 - 檢查
tailscale serve status與tailscale funnel status，移除指向 Unix socket、特別是本地 API socket 的轉發。 - 未使用的 app connector 資格應移除，並限制其出口目的地。
- 存取規則改為成對授權：明確指定單一來源與單一目標；在規則支援的平台上，把 SSH forwarding 設為拒絕。headscale 0.29.5 使用者無法關閉 forwarding，應把每條 SSH 授權視為 root 等級。
- 確認節點金鑰到期（node key expiry）沒有被關閉；只有真正無人值守的裝置才考慮關閉。
- 清理長期未上線的閒置裝置：在管理主控台刪除，而不是只重灌主機，因為已複製出去的金鑰不會因重灌而失效。
- 評估是否啟用 Tailnet Lock：啟用後新節點必須經信任裝置簽章才能加入（即使登入帳號或 auth key 外洩也無法單方面加入裝置）；但簽章裝置的保管與遺失復原要先規劃，避免把自己鎖在外面。
- 保護 Tailscale 登入帳號：以 passkey 或硬體金鑰作雙因素驗證。
6. 本工作坊的判讀
本事件容易被誤讀為「Tailscale 被從外部攻破」。實際上它示範的是零信任工具的共同課題：當一支以 root 運行的代理程式把網路層的授權直接轉成作業系統層的權限，授權之後在主機內部發生什麼事同樣需要權限分離與檢查。對防守方的實務意義有三：第一，功能有開才有風險，盤點實際啟用的功能比恐慌更重要；第二，存取規則的粒度決定災情半徑，成對授權是成本最低的止血；第三，在修補版本出現前，已確認的資訊是研究者的實驗結果與廠商「正在修復」的回應，其餘說法——包括嚴重程度的爭論——應保留為未定論，等待官方公告與修補版本落地。
7. 原始來源與參考
- 原始揭露：Cyberdione Labs, "Tailworm" 報告（Erica Windisch，2026-10-25）。
- 主要報導：The Hacker News, "Unpatched Tailscale SSH Flaws Could Let a Hacked Device Reach Root on Other Servers"（2026-10-25 至 26）；Cyber Security News, "Tailscale SSH Flaws Could Let Hackers Gain Root Access Across Servers"。
- 廠商回應：Tailscale 工程副總 Mike Shaver 於 Reddit 的公開回覆（經 The Hacker News 轉述）。