未修补的 Tailscale SSH 漏洞或允许被攻陷的设备获得其他服务器的 root 权限

一位安全研究员本周发布了研究结果，指出 Tailscale 网络上一台被攻陷的设备可被用来获得其可达的其他服务器的 root 访问权限。

该攻击需要两个条件：Tailscale SSH 被配置为允许端口转发，以及攻击者已经控制了网络访问规则允许连接到目标的一台设备。

这些发现于 10 月 25 日由 Cyberdione Labs 的 Erica Windisch 发布在一份名为 Tailworm 的报告中。Windisch 在实验室用三天时间测试了 Tailscale 1.104.2 版本和 headscale 0.29.5 版本——后者是一些网络用来代替该公司托管服务而自托管运行 Tailscale 的服务器。

该报告描述的是针对该软件的测试，而非针对真实网络的攻击。截至发稿，Tailscale 尚未发布安全公告、CVE 编号或修复版本。

Tailscale 已作出公开回应。该公司工程副总裁 Mike Shaver 在 Reddit 上写道，Tailscale 已收到该报告，此前已与外部安全专家共同关注相同领域，并发现了一些正在修复的问题。Shaver 表示，公司仍在确定哪些配置受到影响，并"不建议所有人禁用 Tailscale SSH"。

Tailscale SSH 的工作方式不同于普通 SSH 服务器。它不检查连接用户的密码或密钥，而是识别设备，由单条访问规则决定该设备是否可对目标开启 SSH 会话。

因此，该攻击不需要窃取的密码或密钥。它需要先在一台设备上获得立足点，报告称攻击者可以通过常见方式获得：易受攻击的 Web 应用、被投毒的软件包、钓鱼或窃取的登录凭据。Tailscale 并不会制造这第一个立足点。

管理员能做什么取决于网络的运行方式。在 Tailscale 托管服务上，可以按规则关闭转发。在 headscale 0.29.5 上，转发根本无法关闭。报告因此表示，那里的每一条 SSH 授权都应被视为授予目标上的 root 权限。

在实验室中，Windisch 分阶段展示了这个问题。利用标准 SSH 端口转发，一个普通会话导致 root 级别的 Tailscale 进程连接到一个只有 root 才应访问的系统套接字，测试几乎立即获得了 root 权限并读取了系统密码文件，且无需管理员权限。

第二种方法将一个 root 拥有的套接字替换为攻击者的，从而允许对某些服务直接执行 root 命令。

第三种方法通过对系统在检查文件路径与使用文件路径之间的时间差进行竞态攻击，击败了一个旨在限制转发可访问哪些文件的安全检查。报告称，这条链在实验室中走得更远：它捕获了一个用于注册新设备的密钥，并使用该密钥将攻击者自己的机器作为受信任服务器加入网络。

最后一步仅在未启用 Tailscale 的 Tailnet Lock 功能的网络上从头到尾成功。在启用了该功能的网络上，所需的机密在传输中被捕获，但最后一步未能完成。

Windisch 将总体结果描述为"可蠕虫式传播"。在实验室中，一台被攻陷的设备可以在访问规则允许的范围内扩散到每台设备，无需密码、无需窃取的密钥、无需用户操作，每步耗时不到一秒。

用报告的话说："这种网格以机器速度将一个普通立足点转化为全域特权访问。"这种扩散是在实验室中测得的，并非在真实网络上观察到。

报告指出了两个阻碍它的因素：以单一源到目标对形式编写的访问规则，它们本身就能阻止扩散；以及绑定到 TPM 或 Secure Enclave 等硬件的设备密钥。

一些读过该报告的研究者公开质疑"可蠕虫式传播"的描述，而另一些人则认为 root 访问的发现很严重。

这个 SSH 问题是报告中 11 项发现之一，报告还涉及 Tailscale 的 app connectors、其 serve 功能、设备间使用的 DERP 中继，以及 headscale。Windisch 告诉 The Hacker News，SSH 权限提升"令人担忧"，但 app connector 的发现"对某些组织的影响可能更大"。app connector 发现在一个名为 conn25 的实验性功能中，允许被授权用户将流量发送到安全团队从未批准的目的地，包括云提供商的元数据服务——该服务可分发服务器凭据。

所有发现仅基于 Windisch 的报告。没有其他研究者公开复现它们，Tailscale 也未确认具体的技术主张。Windisch 表示，发现背后的概念验证代码未公开，她只提供给了 Tailscale 的安全联系人。

Windisch 将此次披露描述为"已报告但未协调"，并在 Ycombinator HN 上如此写道，那里至少有一位评论者称不先向 Tailscale 报告就发布是不负责任的。

在回答 The Hacker News 的提问时，Windisch 表示她实际上在公开发帖前已将报告和概念验证代码的副本交给 Tailscale，提前的周六就发送到了该公司的安全联系人。她还表示，此前曾向该公司首席执行官提出过对 Tailscale 架构的担忧，并公开发布了一个文件哈希，建议用户禁用 Tailscale SSH。

该报告是 Tailscale 同一部位一系列问题的最新一起。2026 年早些时候，该公司在 1.98.9 版本中修复了多个 Tailscale SSH 和服务器套接字处理缺陷，其中包括 SSH Unix 套接字转发可触及特权套接字的一个缺陷。

现在该怎么做

由于没有补丁，可用的措施是更改 Tailscale SSH 及相关功能的配置方式。报告和 Tailscale 自己的建议在大多数方面重合。

• 审查你的 Tailscale SSH 访问规则。将它们写成命名一台设备和一台目标的单一源到目标对，并删除按身份或标签授予权限的宽泛规则。报告称按对编写的规则是测试中唯一阻止扩散的控制措施。
• 尽可能关闭 SSH 端口转发。在 Tailscale 托管服务上，这是按规则设置的。在 headscale 0.29.5 上无法关闭，因此那里的每条 SSH 授权都应被视为授予目标 root 权限。
• 从不需要的设备上移除 app connector 权限。
• 移除任何指向 Unix 套接字的 tailscale serve 转发。
• 启用节点密钥过期，使被盗的设备密钥不会永远有效。
• 如果设备被攻陷，请在控制平面将其删除。重装系统镜像并不会撤销攻击者可能已经复制走的密钥。

Tailscale 还建议启用 SSH check mode（它在会话开始前增加一个登录步骤）以及启用自动更新。Check mode 并不能修复权限提升问题，它只是在其前面增加了一道屏障。