OpenClaw 完成 Trail of Bits 安全审计并公开全部修复结果

OpenClaw 的安全是一项持续开展的工作，而其中一部分就是对我们发现和修复的问题保持透明。

OpenClaw 最近通过 OpenAI 的 Patch the Planet 计划，与 Trail of Bits 完成了一次广泛的安全审计，让我们更清楚地看到 OpenClaw 的安全边界在哪些地方需要加强。今天我们分享审计结果。

摘要：

Trail of Bits 提交了 27 份私有仓库安全公告和 3 个独立的加固拉取请求。
在这些公告报告中，24 份描述了已评定严重级别的漏洞。其中 23 份被归类为已确认漏洞，不过有些因在进入稳定版本前就已修复，所以关闭时未公开发布。剩下的 1 份涉及一个在提交前就已修复的漏洞。
这 24 份报告的评级为 0 个严重、2 个高危、16 个中危和 6 个低危。另外 3 份被归类为纵深防御类发现，未获得严重级别评级，因为它们并未跨越有明确记录的信任边界。
所有可处理的问题均已修复，3 个独立的加固 PR 也全部合并。

合作是如何进行的

Patch the Planet 将 AI 辅助的安全研究与人工审查相结合。Trail of Bits 使用 Codex 辅助的工作流来搜索问题并开发修复方案，然后人工核查这些发现，再提交给我们。

我们对照 OpenClaw 的信任模型和发布历史审查了每一份报告。随后我们修复并测试了被接受的问题，同时通过私有的 GitHub Security Advisories 协调披露。

此次审查覆盖了核心权限以及 OpenClaw 在各功能中处理用户数据的方式。虽然涉及的功能各不相同，但反复出现的是同一类安全挑战。

最常见的问题是在步骤之间丢失权限。一个请求进入 OpenClaw 时可能只有有限访问权限，随后启动的另一项工作却不再带有这些限制。

有时正确的修复方式是把原始权限延续下去。而在另一些情况下，后续工作本来就不需要访问权限。例如，一个文件名生成器并不需要工具。

在整个 OpenClaw 中，后续工作不能仅仅因为丢失了原始请求的上下文就获得访问权限。

OpenClaw 有时对同一事物有多个名称，以便旧配置继续可用。当安全检查看到的是一个名称，而系统之后使用的是另一个名称时，问题就出现了。

这同时影响了用户身份和功能名称。修复方式是先确定系统实际会使用什么，再应用安全策略。

有几份报告发现 OpenClaw 检查的内容与其之后实际使用的内容之间存在差距。

有一处归档检查在完整内容被解压之前只查看了归档的一部分。另一例中，文件路径在 OpenClaw 已经批准之后发生了变化。这些检查单独看都合理，但并未覆盖最终操作。

修复方式是将批准绑定到实际会被使用的确切文件、身份或操作。如果之后有任何变化，OpenClaw 需要重新检查。

有些功能在启动时检查了权限，但在之后运行时没有检查。在配置中关闭某个功能，并不总能影响到已经在运行或已缓存的工作。

我们将这些检查移到了更接近使用时刻的位置。对于耗时的工作，OpenClaw 可能还需要在返回结果前再次检查。

一项发现展示了这种情况可能如何发生。一个 agent 可能在请求开始后很久仍在继续工作，因此只在开始时检查权限是不够的。如果一次运行开始时启用了内存访问，而操作员在中途将其禁用，那么该次运行可能会继续读取内存，直到结束。

修复方法是让工具在每次执行操作时都检查当前设置。该问题只影响已经获得访问权限的运行，但它表明权限变更也需要传达到已经在进行中的工作。

只要 OpenClaw 仍在处理某个请求，权限和身份就必须始终跟随该请求。安全检查必须针对将要使用的确切资源，而关闭访问权限必须影响到已经在运行的工作。测试需要检验真正的安全边界，而不是止步于恰好出现 bug 的辅助函数。

所有问题均已在 main 上修复，并随 2026.8.1 和 2026.7.33 LTS 稳定版本发布。

感谢 Samuel Judson、Lucas Bourtoule、更广泛的 Trail of Bits 团队，以及 OpenAI 发起 Patch the Planet 计划。🦞