OpenClaw 安全吗？基于官方公告的风险梳理与使用建议

最近 OpenClaw 很受关注。它最吸引用户的地方，不只是“能聊天写代码”，而是它能直接调用终端、使用工具、安装技能、处理本地项目文件。这也是为什么它的安全问题比普通 AI 助手更值得关注。

如果你还不熟悉这个项目的背景和传播脉络，可以先看这篇站内解析：Clawdbot：一天获得 9000 星的开源 AI 助手深度解析。由于 Clawdbot 就是此前的 OpenClaw，这篇文章更聚焦它的安全边界与使用风险。

围绕 OpenClaw，用户最关心的通常是几个问题：

• OpenClaw 安全吗
• OpenClaw 是否有公开漏洞
• OpenClaw 会不会泄露数据
• OpenClaw 会不会误删内容

下文只基于 openclaw/openclaw 官方可核实来源，梳理目前已经公开披露的问题，以及这些问题对开发者/用户意味着什么。

先说结论：OpenClaw 可以用，但不应按“普通本地工具”对待

截至 2026 年 3 月 12 日，OpenClaw 官方公开信息已经足以说明一件事：更适合把它当成具备本地执行能力的高权限 agent 来管理，而不是低权限编辑器插件。

OpenClaw 官方 trust 页面明确写到，它主要面向本地、单用户开发环境，并不承诺把系统做到“对敌对输入、敌对页面或敌对多租户场景都强隔离”的级别。官方同时提醒用户：

• 不要把它当成经过强化隔离的沙箱（hardened sandbox）
• 不要默认信任外部内容和技能
• 需要谨慎处理工作目录、凭证与审批策略

这些提示很重要，因为它们决定了 OpenClaw 应被如何看待：它不是“回答错一段代码”那么简单，而是一旦配置失当，就可能演变成真实的本地安全问题。OpenClaw Trust Center

为什么 OpenClaw 的安全争议最近会变多

OpenClaw 官方安全文档同样写得很直接：prompt injection 这类问题无法完全依靠模型能力根除，所以高风险工具调用、凭证映射、危险模式开关和技能安装，都需要用户自己建立防线。OpenClaw Security Docs

换句话说，OpenClaw 的安全边界横跨了几层：

• 本地 shell 与命令执行
• 浏览器与 dashboard
• 凭证、环境变量和 token
• 技能安装与本地文件写入

这也解释了为什么它的公开问题不会只落在一个方向上。这里看到的并不是“一个偶发小 bug”，而是一类 AI agent 产品进入真实开发环境后逐步暴露出的攻击面。

时间线：OpenClaw 官方已公开披露了哪些问题

下面这些问题，均只保留 OpenClaw 官方 Security Advisories 能直接对应上的内容。

2026 年 3 月 8 日：Dashboard 认证材料泄露到 URL 和 localStorage

官方安全公告 GHSA-rchv-x836-w7xp 的标题非常直接：“Dashboard leaks gateway auth material via browser URL query parameters and localStorage.”
这意味着某些认证材料会出现在 URL 查询参数和浏览器本地存储里。官方公告

这类问题最危险的地方在于，它不需要传统意义上的“拖库”。只要 token 或认证材料进了 URL，它就可能进一步进入：

• 浏览器历史
• 录屏和截图
• 代理日志
• 监控与分析链路
• 用户复制粘贴的链接

如果再叠加 localStorage，泄露面就会继续扩大。对 OpenClaw 这类产品来说，认证材料本身就是核心资产。

2026 年 3 月 8 日：fetch-guard 可能把自定义认证头带到跨域重定向目标

同一天公开的 GHSA-6mgf-v5j7-45cr 标题指出：“fetch-guard forwards custom auth headers across cross-origin redirects.”
从标题本身就能看出问题性质：某些自定义认证头本不该跨域带出，但在特定重定向链路里被继续转发了。官方公告

这个问题和上一条不完全一样。上一条更像“浏览器侧泄露”，这一条更像“请求链路把本不该带走的认证信息带走了”。如果开发者在真实环境里把 API key、gateway token 或其他敏感头直接接入相关流程，这类问题就会变成非常现实的凭证外泄风险。

2026 年 3 月 8 日：system.run 环境覆盖过滤存在危险 helper-command 绕转空间

官方安全公告 GHSA-j425-whc4-4jgc 的标题是：“system.run env override filtering allows dangerous helper-command pivots.”
这条公告的重点不是“普通命令执行”，而是环境覆盖过滤与 helper command 之间出现了危险绕转空间。官方公告

这个标题虽然偏技术，但核心含义并不复杂：原本想限制的执行边界，可能被某些辅助命令路径重新绕开。对于本身就具备命令执行能力的 agent 来说，这类问题值得重点关注，因为它影响的是看似已经被限制住的能力，是否真的被限制住。

2026 年 3 月 11 日：技能安装下载流程可被重绑定到 tools 根目录之外

官方安全公告 GHSA-vhwf-4x96-vqx2 标题写的是：“skills-install-download can be redirected outside tools root by rebinding the previously validated base path.”
换句话说，技能安装下载过程在特定条件下，可能被引导到预期 tools 根目录之外。官方公告

这条公告值得特别关注，因为它已经不是单纯的“读信息”问题，而是和技能安装、本地路径边界、文件落地位置直接相关。只要一个 agent 支持自动下载和安装技能，这类路径边界问题天然就很敏感，因为它可能影响本地文件写入与后续执行链。

2026 年 3 月 11 日：沙箱会话初始化 host ACP spawn 请求的边界问题

官方安全公告 GHSA-9q36-67vc-rrwg 标题是：“Sandboxed sessions can initialize host ACP spawn requests.”
这条标题本身就说明，沙箱会话与宿主侧进程创建请求之间存在不应出现的初始化边界问题。官方公告

这类问题不如“token 泄露”直观，但从安全视角看，它更接近一个根本性问题：看似处于沙箱中的会话，仍可能接触到宿主机侧的执行链。 对任何本地 AI agent 来说，这都属于需要重点评估的边界问题。

现实事故补充：公开案例显示误执行风险并不抽象

除了官方安全公告，2026 年 2 月下旬还有一件受到广泛关注的公开事件。

2026 年 2 月 23 日，Meta AI 安全研究员、Meta Superintelligence Labs 对齐负责人 Summer Yue 在 X 上发文称，她原本要求 OpenClaw “先确认再执行”，但 agent 仍然开始快速删除她的邮箱内容。她写道，自己无法通过手机远程制止，只能“跑去 Mac mini 像拆弹一样”手动停下进程。X 贴文

TechCrunch 在 2026 年 2 月 23 日 跟进了这起事件，并补充了 Yue 后续给出的解释：她此前先在一个较小的“toy inbox”里测试成功，随后接入真实邮箱；真实邮箱体量更大，触发了 agent 的 compaction，导致系统丢失了“不要直接执行”的原始约束。TechCrunch 同时明确写道，其无法独立核实邮箱里究竟发生了什么。TechCrunch

这条案例的价值，不在于它是否构成传统意义上的 CVE，而在于它把一种常被轻描淡写的风险具体化了：

• prompt 里的“先确认再执行”并不等于可靠的安全控制
• 长上下文、压缩总结和状态漂移会直接影响 agent 是否还记得关键约束
• 当 OpenClaw 这类 agent 被接进真实邮箱、真实文件或真实工作流后，误操作造成的损失并不抽象

从报道口径看，这更适合被归类为公开用户事故与风险信号，而不是“官方已确认漏洞”；但对一篇讨论 OpenClaw 安全性的文章来说，这种案例恰恰能说明一个现实问题：很多风险未必先以 GHSA 的形式出现，而是先以真实损失案例的形式出现。

这些官方公告共同说明了什么

如果把这些公开问题放在一起看，会发现 OpenClaw 的风险并不是单点问题，而是分布在几个连续层面上：

1. 浏览器与 dashboard 层
2. 请求与认证头层
3. 命令执行与 helper command 层
4. 技能安装与本地路径层
5. 沙箱与宿主边界层

这意味着“OpenClaw 安全吗”其实不能只回答一句“安全”或者“不安全”。更准确的说法是：

• 它有官方已披露的真实安全问题；
• 这些问题已经覆盖了泄露、执行、路径与边界控制；
• 它并不适合在“无隔离、无审批、带真实生产凭证”的环境里裸跑。

OpenClaw 会不会误删文件？官方公告暂无，但公开误执行删除案例已经出现

从能力上看，OpenClaw 当然具备修改乃至删除文件的条件；截至 2026 年 3 月 12 日，在 openclaw/openclaw 官方 Security Advisories、官方 docs 与 trust 页面中，尚未见到一个已公开、可核实的“误删文件事故”公告。

但这并不意味着“误删”只停留在理论层面。公开信息里已经出现了更接近这一风险的现实案例：Summer Yue 披露的 OpenClaw 误删邮箱内容事件，说明当 agent 失去原始约束后，确实可能对真实数据执行错误动作。

更准确的结论是：官方公开来源尚未披露“误删文件”事故，但公开可追溯的“误删邮件/误执行删除动作”案例已经出现。 对安全评估来说，这已经足够说明 prompt 约束本身并不可靠。

如果继续使用 OpenClaw，最值得先做的 5 件事

1. 第一时间升级到包含修复的最新版本

既然官方已经连续发布多条安全公告，最基本的动作就是先升级。继续停留在受影响版本，再去谈审批策略和隔离，意义会小很多。

2. 别把 dashboard 和相关服务随便暴露到外网

从已披露问题看，浏览器、请求链路和认证材料都是高风险点。把 dashboard、gateway 或相关入口暴露到不必要的网络边界，只会放大问题。

3. 默认保留人工审批，不要轻易关掉危险模式

官方 docs 已经反复提醒用户谨慎处理危险模式、审批策略与凭证映射。OpenClaw Security Docs
如果为了图方便把这些保护一口气都关掉，实际效果就等于把 OpenClaw 当成高权限自动执行器来运行。

4. 技能安装应按“本地可执行代码”标准来审视

只要功能涉及自动下载、安装和落地到本地目录，就不能把技能当成“随便装的小插件”。技能来源、代码内容、安装路径和权限边界，都应该先看清楚。

5. 不要把长期高权限密钥直接塞进默认环境

一旦认证材料进入浏览器、请求头、本地存储或日志链路，问题就不再只是“会不会回答错”，而是“会不会把真正值钱的东西带出去”。

FAQ：关于 OpenClaw 安全的几个高频问题

OpenClaw 有官方公开漏洞吗？

有，而且不止一条。至少可以直接在 openclaw/openclaw 仓库的 Security Advisories 页面看到多条官方公告。
Security Advisories

OpenClaw 出现过数据泄露类问题吗？

有。官方已公开披露 dashboard 认证材料出现在 URL 与 localStorage，以及认证头在跨域重定向中被转发的问题。

OpenClaw 会不会被黑客利用？

从官方公告类型来看，它存在可被利用的现实攻击面。因为问题已经不仅是“回答不准确”，而是涉及认证材料、命令执行边界、技能安装路径和沙箱隔离。

OpenClaw 现在还能用吗？

能用，但前提是将它当成高风险本地 agent来管理，而不是低权限小工具。

总结

基于这些官方来源，至少可以确认几点：

• OpenClaw 已有多条官方安全公告
• 风险覆盖泄露、执行、路径边界和沙箱边界
• 官方自己也没有把它描述成“可以默认信任的强化隔离沙箱”

所以更准确的结论不是“OpenClaw 很危险所以别碰”，而是：OpenClaw 可以用，但更适合在升级、隔离、审批和最小权限都到位的前提下使用。

相关资源

• OpenClaw 仓库
• OpenClaw Security Advisories
• OpenClaw Trust Center
• OpenClaw Security Docs
• Clawdbot：一天获得 9000 星的开源 AI 助手深度解析
• TechCrunch: Meta AI security researcher said an OpenClaw agent ran amok on her inbox
• Summer Yue 相关 X 贴文索引
• GHSA-rchv-x836-w7xp
• GHSA-6mgf-v5j7-45cr
• GHSA-j425-whc4-4jgc
• GHSA-vhwf-4x96-vqx2
• GHSA-9q36-67vc-rrwg