Tailscale SSH 安全漏洞 TS-2026-009

Tailscale 已修補一項關鍵安全漏洞，編號為 TS-2026-009，該漏洞允許具有現有 Tailscale ACL 權限的使用者將其在目標主機上的權限提升至 root。此缺陷源於 Tailscale SSH 在與系統工具互動時處理使用者名稱的方式，特別是允許以破折號開頭的使用者名稱被解讀為命令列參數。

根本原因：不安全的參數處理

此漏洞發生的原因是 Tailscale SSH 直接將使用者名稱作為參數傳遞給 getent(1) 指令以取得密碼條目。由於輸入未經適當的清理或分隔，使用者可以提供以破折號開頭的名稱（例如 -i），getent 會將其解讀為旗標而非字面上的使用者名稱。

此行為使得透過 Tailscale ACL 取得有效 SSH 存取權的攻擊者能繞過預期的使用者限制，取得 root 登入。這是一個典型的參數注入漏洞，使用者提供的資料被底層系統呼叫誤當成控制指令。

修復與對策

Tailscale 已實施多項限制以防止此類參數注入：

• 拒絕以破折號開頭的名稱：Tailscale SSH 現在會明確拒絕任何以破折號開頭的使用者名稱。
• 限制數字使用者名稱：為避免歧義及進一步的潛在利用，Tailscale 現在不允許在 SSH 中使用 UID 或純數字的使用者名稱。

技術社群分析

TS-2026-009 的公開引發了安全專業人士對系統呼叫最佳實踐以及取代既有工具風險的廣泛討論。

參數處理最佳實踐

技術評論者指出，呼叫子程序如 getent 本身就比使用原生 API 或系統呼叫更具風險。正如使用者 @jcarrano 所說：

usernames were passed as arguments to getent(1) to retrieve the corresponding passwd entry Always try to use actual API/system calls (in this case getpwnam) instead of calling sub-processes.

此外，有些開發者認為僅僅拒絕含破折號的使用者名稱是一種變通方案，而非結構性的修正。更穩健的做法應該是使用 -- 分隔符，該分隔符表示命令列旗標的結束，確保所有後續參數皆被視為位置參數。

Tailscale SSH 與 OpenSSH 的比較

此事件重新點燃了使用專有或較新 SSH 實作與業界標準 OpenSSH 之間的辯論。多位社群成員表示偏好 OpenSSH，因其經過數十年實戰驗證的安全紀錄。

tailscale ssh: replacing a 25-year-old battle-tested codebase with a startup's Go rewrite and then acting surprised when it has bugs

一些組織仍然僅因其 NAT 穿透與 VPN 功能而使用 Tailscale，同時依賴傳統的 OpenSSH 與 SSH 憑證來進行實際的驗證與存取管理，以降低攻擊面。

影響概覽

功能	漏洞類型	影響	修復措施
Tailscale SSH	透過 getent 的參數注入	Root 權限提升	阻止以破折號開頭及純數字的使用者名稱

摘要： Tailscale 已修補漏洞 TS-2026-009，此漏洞源於 Tailscale SSH 中的不安全參數處理，允許具有效 ACL 存取權的使用者透過模仿命令列旗標的使用者名稱取得 root 權限。

標題： Tailscale SSH 安全漏洞 TS-2026-009