Tailscale 一次發 4 則安全公告：開了 Tailscale SSH 或 Serve 的節點要升到 1.104.4，部分情境可碰到 Docker 等 root 專用通道、接管整台節點

趨勢新聞2026 年 10 月 28 日

Tailscale 是一套把散在各地的電腦、NAS、伺服器連成一個私人網路的軟體，裝好之後在家或出差也能連回公司的 NAS 或主機，不必在防火牆上開洞。Tailscale 10 月 26 日一次發了四則安全公告（TS-2026-014 到 TS-2026-017），問題都出在兩項進階功能：用 Tailscale 帳號直接登入主機的「Tailscale SSH」，以及把機器上的服務分享給同一網路其他裝置的「Tailscale Serve」。四則都修在 1.104.4。本站的讀法：有開這兩項功能的節點，要自己確認已升到 1.104.4；本機沒開 Tailscale SSH 伺服器、也沒用 Serve 的，不在這四則公告列出的受影響節點範圍內。

我會不會受影響？

• 開了 Tailscale SSH，存取規則又允許轉送：TS-2026-014 的範圍。暫時不能升版的，官方給了關掉轉送的辦法，見下文。
• 開了 Tailscale SSH（不論有沒有轉送）：TS-2026-015 的範圍，最壞是 Tailscale 程式被拖垮、整台機器的 Tailscale 連線中斷。
• 用 Serve 分享 Unix socket 後端，本機又有人能改 Serve 設定或後端路徑：TS-2026-016 的範圍，其中一個問題可導致整台節點被接管。
• 用 Serve 並開了 TLS，同一台有兩個以上權限要求不同的分享路徑：TS-2026-017 的範圍，問題出在同一條 HTTP/2 連線上同時進行的多個請求。

四則的觸發條件各不相同，但都不是「網路上任何陌生人」：SSH 的兩則要對方已通過驗證、存取規則允許他 SSH 進來（014 還要允許轉送）；Serve 的 016 要本機有人能改 Serve 設定或後端路徑；017 要對方在你的 tailnet（同一個 Tailscale 私人網路）裡已持有某個分享路徑的權限。本站的讀法：014、016、017 比較像大樓門禁，你發給訪客一張只能進某一層的卡，這張卡卻刷得開別層甚至機房；這個比喻只說明權限越界，不適用 015，那一則是讓服務當掉。截至本站 10 月 28 日查核，這四則公告都未列 CVE 編號，也沒有標嚴重度分級；公告沒有提到已遭利用，但這不等於可以斷定沒人利用過。

名詞先講清楚

tailscaled 是 Tailscale 在背景常駐的主程式，公告形容它是以 root（系統最高權限帳號）權限執行的程式。Unix socket 是同一台機器上程式之間互相溝通的通道，很多管理介面只開給 root 用，例如 Docker 的管理通道（Docker socket），以及 tailscaled 自己的本機管理介面（官方稱 local API）。SSH 轉送是透過 SSH 連線把遠端機器上的連線通道接到自己這邊（ssh -L），或反過來把自己這邊的通道接到遠端（ssh -R）。

四則公告各說了什麼

TS-2026-014：SSH 轉送 Unix socket 時，tailscaled 只檢查路徑字面上在不在允許清單，實際操作卻用 root 身分做，產生三個問題：用 ssh -L 能以 root 權限連到受保護的 socket；用 ssh -R 能移除 root 擁有的 socket、換成自己的；檢查完到系統真正解析路徑之間有時間差，路徑可被掉包。公告寫，這幾個問題加在一起，“remove the path allowlist as a security boundary”，也就是「讓路徑允許清單不再是一道安全界線」（本站譯），攻擊者可碰到 Docker socket 或 tailscaled 的本機管理介面這類只有 root 能用的通道。新版改成以通過驗證的使用者身分轉送，不再一律沿用 tailscaled 的 root 權限。本站的讀法：如果那個 Docker socket 連的是以 root 執行、又允許建立掛載主機目錄容器的 Docker，攻擊者就可能進一步動到主機上的檔案，所以這則不能只當成「多看到一個檔案」。

TS-2026-016：Serve 可以把 Unix socket 當成後端分享出去。舊版把 TCP 轉到 Unix socket 時沒有防護、以 root 身分連線，可把資料直接送進 tailscaled 的本機管理介面；另一個問題出在 HTTP 代理後端：防止符號連結（symlink，類似捷徑）掉包的檢查只在重新載入設定時做、不是每次連線都做，設定好之後把後端路徑換成符號連結就能繞過，結果是能以 root 身分連到任意只有 root 能用的 Unix socket。公告寫第一個問題 “allowed full node takeover”，也就是「可完整接管節點」（本站譯）。受影響的是本機有人能寫 Serve 設定，或本機使用者能改後端路徑的節點。

TS-2026-015：通過驗證、規則允許的 SSH 連線，可以一直送視窗大小變更與環境變數，讓 tailscaled 的記憶體無限增加，對方斷線也不釋放，可能把主機記憶體耗盡、讓 tailscaled 被系統強制終止；一旦發生，整台機器的 Tailscale 連線全斷。TS-2026-017：Serve 開了 TLS 時會宣告支援 HTTP/2，同一條 HTTP/2 連線上同時進行的多個請求共用一份狀態，一個分享路徑的權限資訊（Tailscale-App-Capabilities 標頭）可能被帶到另一個路徑，靠這個標頭判斷權限的應用程式就可能放錯人。

怎麼修，來不及升版怎麼辦

四則的處置都是升到 1.104.4 或更新版本，用 tailscale version 可以看目前版本。本站 10 月 28 日查 Tailscale 官方下載站，穩定版已是 1.104.4，Windows、macOS、Linux、Android 安裝檔，以及 Synology 與 QNAP 這兩家台灣 NAS 品牌的套件都列了 1.104.4，容器映像檔一欄還是 1.104.2；GitHub 上 v1.104.4 的發布時間是台灣時間 10 月 28 日上午 9 時 5 分。NAS 內建套件中心什麼時候推送，本站沒有逐台確認。

暫時不能升版的，官方只針對 TS-2026-014 給了緩解方式：在 tailscaled 服務的環境變數設 TS_SSH_DISABLE_FORWARDING=1 再重啟服務，這樣會關掉 SSH 轉送，但 Tailscale SSH 其他功能照常。這一招對另外三則無效，Serve 的兩則與 SSH 記憶體那則仍要靠升版。本站的讀法：一時不能升版、又用 Serve 分享 Unix socket 後端的，可先停用那幾個分享，等升版後再開；這主要針對 016，不能當成 017 的緩解，而且是本站的建議，不是官方列的步驟。

還有一個台灣資訊人員容易漏掉的地方。這四則公告未列 CVE 編號，本站的讀法是，公司的修補流程若只靠 CVE 比對，可能對不上，宜另以 TS-2026-014 到 017 的編號追蹤，並確認掃描工具有沒有對應的檢查。10 月 21 日的前一則公告 TS-2026-013 要求升到 1.104.2，這次要再往上到 1.104.4；升到 1.104.4 也同時符合那一則的要求。