OpenClaw安全实战:4天暴露9个漏洞,我怎么补上的

4 天、9 个 CVE、最高 9.9 分、31.6 万 GitHub Stars。 而我这边，是 6 个天天帮我干活的 AI Agent，和 20 多个绕着 OpenClaw 转的定时任务。

有一晚我真的被吓出了一身冷汗：我突然意识到——如果有人在那几天里扫到我这套 OpenClaw，然后往调度中心发了一条特制的 WebSocket 消息，我的 6 个 Agent 可能会在几秒钟内集体“叛变”。

不是电影情节，也不是安全专家的威胁建模，而是被官方点名的一个真实 CVE：“只要在 WebSocket 里谎报身份，就能直接当管理员。”

这篇文章，我不打算讲什么高深的安全原理，也不打算复述官网公告。我只想从一个重度 OpenClaw 实战用户的视角，复盘这场 4 天 9 个 CVE 的暴击，是怎么从 PDF 公告，变成我半夜爬起来改配置的直接原因。

如果你也在用 OpenClaw 跑 Agent、跑 Workflow，或者打算把团队工作流搬上来，希望这篇真实复盘，能帮你少踩一些我已经踩过的坑。

一、那晚，我的 6 个 Agent 差点被一条 WebSocket 消息“团灭”

先把最吓人的部分说清楚。

1. 我的 OpenClaw「生产现场」长什么样？

我是一人公司创始人，平时对外说的是：“我有 6 个 AI 员工，24 小时轮班帮我干活。”

这 6 个 Agent 分布在不同的 Workflow 里，有的盯内容平台，有的做数据分析，有的连着协作平台和工具协议，帮我处理各种零碎活。外面看起来是一个人做内容、写代码、运营账号，实际上后台全是 Agent 在跑：

• OpenClaw 上常驻 6 个核心 Agent（内容、增长、开发、运维、质检、整理）

• 每天有 20+ 定时任务，按分钟级、小时级把 Workflow 调度起来

• 调度中心常年开在一个稳定的节点上，方便我随时远程连上去看日志

• 部分 Workflow 会直接接触到合作平台、内容平台的敏感数据（cookie、session token、私聊内容草稿等）

说白了，OpenClaw 对我来说不是玩具，是业务中枢——它挂了，我这个“一人公司”当天就歇菜。

2. 那个 9.9 分的 CVE 到底多离谱？

3 月中下旬，安全圈开始密集刷屏：

“OpenClaw 在 4 天内披露了 9 个 CVE，其中一个 CVSS 评分 9.9。”

这个 9.9 分的漏洞编号是 CVE-2026-22172，核心问题一句话可以说清楚：

通过 WebSocket 连接调度中心时，客户端可以自己声明自己是什么角色；如果你说自己是管理员，OpenClaw 就信了。

稍微展开一点，就是：

• 正常情况下，OpenClaw 会在 WebSocket 链路上维护一个“我是哪个用户、有什么权限”的上下文；

• 但这次的实现里，有一段逻辑直接信任了客户端传上来的 scope；

• 结果就是：一个原本只有只读权限的用户，只要在 WebSocket 握手之后，发一条“我现在是 operator.admin”的消息，就能获得整个集群的管理权限。

这个场景有多现实？

• 不需要什么花里胡哨的 RCE、buffer overflow；

• 不需要绕沙箱，也不需要逃逸容器；

• 甚至不需要撞什么复杂的 token ——只要能连上你的调度中心，就能“一句话当管理员”。

当我看到这个描述的时候，我脑子里蹦出来的是一句很粗糙的感受：

“这也太像我现实里的部署形态了吧。”

二、4 天 9 个 CVE：不是安全新闻，而是我的系统体检报告

如果你只把这次事件当成“一次安全新闻”，那大概率只会得到两个结论：

1. OpenClaw 火得离谱，才会引来这么多安全研究者；

2. 官方已经连夜出补丁，升级一下就行了。

但如果你的 OpenClaw 上像我一样跑着一堆 Agent 和 Workflow，这 9 个 CVE 其实更像是一次强制体检单：

它告诉你：你到底把多少东西，丢在了一个你“以为安全”的地方。

1. 事件时间线：4 天里的 9 声警报

官方公开的信息大致是这样一个节奏：

• 3 月 18–21 日：4 天内连发 9 个 CVE 公告；

• 其中 1 个 9.9 分（CVE-2026-22172），6 个高危，2 个中危；

• 另外还有十几条相关的安全公告，在安全社区和第三方分析里陆续放出；

• 到 3 月底，第三方统计：

• OpenClaw 5 个月从 0 到 31.6 万 GitHub Stars；

• 公网上可被扫描到的 OpenClaw 实例数已经是 四万多级别；

• 其中一部分没有任何前置保护，调度中心直接暴露在外网。

如果把这些数字翻译成我自己的语言，大概是：

“你现在把你的个人助理、数据分析师、运营团队，全部丢进了一个大家都在研究的系统里； 而且，有不少人，连门都没锁。”

2. 这 9 个 CVE，扎在了我系统的哪些位置？

我不想逐条翻译官方文档，而是想按“一个重度实战用户”的视角来拆：

CVE-2026-22172：一句话当管理员（WebSocket 授权绕过）

刚才已经讲了，这是那晚让我冷汗直冒的那条：

• 只要能连到调度中心 WebSocket；

• 发一条“我现在是 operator.admin”的 scope；

• OpenClaw 就默认你是管理员。

对我这种把所有 Agent 都跑在一个统一调度中心上的用户来说，这意味着：

一旦入口暴露，攻击者可以：

• 查看 / 修改 所有 Workflow 配置；

• 读取 Agent 的运行日志（里面全是各类平台的敏感返回）；

• 通过现有的工具协议调用真实外部服务；

• 直接重写某些 Workflow 逻辑，让 Agent 在你不知道的情况下“帮别人干活”。

而且别忘了，很多人（包括我当时）会为了方便管理，把调度中心绑在一个“比较好连”的地址上，而不是严格做内网隔离。

CVE-2026-32025：“打开一个网页，你的 Agent 就可能被劫持”

这条的核心是：

• 调度中心在本地监听时，对本机访问没有额外限制；

• 恶意网页可以通过浏览器里的一段 JavaScript，主动去连接本机的调度中心 WebSocket；

• 如果你在本机上开着管理页面，同时浏览其他网页，就有可能被“借壳”发命令。

换成人话：

“你在后台看着自己 Agent 跑任务，前台随手打开了一个不太干净的网站； 结果那边网页的脚本，开始帮你不停地尝试登录、爆破、发指令。”

当时看到这里，我回想了一下：

• 我是不是经常在同一台电脑上，一边看 OpenClaw 日志，一边刷信息流？

• 我有没有给调度中心配过太宽松的本地绑定？

答案都不太好看。

CVE-2026-32048：“沙箱关着，但门没锁”

很多人用 OpenClaw 会有一种心理安慰：

“反正我把 Agent 都跑在沙箱里了，就算 Prompt 被人搞坏了，顶多崩一下。”

这条 CVE 的问题在于：

• 在沙箱模式下委派出来的子进程，并没有完全继承沙箱限制；

• 某些情况下，子进程可以用一种“沙箱关闭”的状态继续跑；

• 结果就是：

• 你以为被限制的 Agent，其实有更大的系统访问权；

• 一旦被绕过，攻击者可以在宿主机上做更多事情。

我看的时候，脑子里有一个很直观的画面：

“你把孩子锁在家里，觉得门关上就安全了； 结果才发现门根本没上锁，甚至还有一扇窗开着。”

其他几条，对我这个一人公司意味着什么？

有一些 CVE 乍一看会觉得“离我很远”，但仔细想想，都是跟现实 Workflow 有关系的：

• 某些下载功能可以写任意文件 —— 如果你挂了协作平台、网盘的同步，就要小心路径遍历；

• 某些 shell 环境变量没做好隔离 —— 你的 Agent 可能在你不知道的情况下，拿起了“不该拿”的权限；

• 某些资源接口没有限流 —— 只要有人知道你在用 OpenClaw，就能发一堆超大 payload 让你宕机。

对团队来说，这些是“安全风险”； 对我这样的一人公司来说，这些就是：

“今天到底是我在用 Agent，还是别人通过我的 Agent 在用我？”

▲ 一句话提权的完整攻击路径

三、冷汗瞬间：我突然意识到自己暴露了什么

讲讲那天晚上我自己的心理变化。

1. 认知转折：从“OpenClaw 很安全”到“我有多不安全”

在这之前，我对 OpenClaw 的安全认知非常朴素：

• 开源社区这么多人盯着，出事会很快修；

• 官方的默认配置应该比较稳；

• 我又不是银行，不会有那么多专业黑客盯着我。

结果这波 CVE 公告出来之后，我的脑子里被强行写入了一件事：

“你不是目标，但你在射程内。”

因为：

• OpenClaw 现在的体量，足够让安全研究者持续挖；

• 安全研究者发出来的 PoC，任何人都能照抄；

• 你哪怕只是那些“批量脚本”扫过的一员，只要配置不当，就会成为顺手牵羊的对象。

2. 我意识到自己暴露了什么？

我开始用一个很残酷的角度来盘点：

“假设有个人成功通过 CVE-2026-22172 登上了我的调度中心，他能看到什么？”

列表大概是这样的：

• 所有内容平台的发布 Workflow：

• 草稿内容；

• 内部摘要、未公开的选题；

• 各种平台的 cookie / session 处理逻辑；

• 协作平台相关的 Agent：

• 我的日常工作记录；

• 头脑风暴的原始笔记；

• 一些还没决定要不要公开的想法；

• 系统层面的东西：

• Agent 之间是怎么互相委派的；

• 我是怎么通过工具协议让 Agent 操作外部服务的；

• 各种定时任务到底在什么时候触发了什么动作。

这还不包括一个攻击者可以“悄无声息地改点东西”的场景：

• 把某些 Workflow 的调用频率调高，让你白白烧算力；

• 在某个不引人注意的 Agent 里加一段“把摘要发到某个地址”；

• 或者更简单：直接删掉你辛苦维护的 Workflow，让你以为是自己误操作。

那一刻，我非常清楚地意识到：

“我已经不再是‘自己一个人玩玩自动化’了，而是把整个一人公司的大脑，放到了一个暴露面很大的系统里。”

四、我实际做了哪些补救？（不是教科书，而是真实操作）

下面是我在那几天里，按照自己能控制的范围，逐条做的事情。它不一定是最标准的安全方案，但至少是一个重度用户能在有限时间内做完的 “止血+加固”。

1. 版本层面：先把地基补齐

第一步是最简单的：

• 把 OpenClaw 升级到包含所有补丁的最新稳定版本；

• 升级前简单备份下核心配置（尤其是 Agent、Workflow 定义相关的部分）；

• 升级后，重点确认：

• WebSocket 授权逻辑是否已经修复；

• 沙箱相关的配置有无变更；

• 各种默认端口和绑定行为有没有微调。

这一段没有太多可讲的技巧，只是一个很直接的认知：

“你不能指望用一个有已知 9.9 分漏洞的版本，撑起一个长期运行的 Agent 系统。”

2. 网络暴露面：先假设“别人一定能扫到你”

我接下来做的事情，就是彻底从“攻击者视角”看自己的 OpenClaw：

1. 调度中心还能不能直接从外网访问？ - 能的话，至少加一层前置保护（比如只允许特定网段、特定入口）； - 更理想的做法，是通过更封闭的通道访问（比如 VPN、自建跳板机等）。

2. 有没有“顺手就开的”服务端口？ - 曾经为了方便调试而开的临时端口，要么关掉，要么收紧； - 不再使用的实验环境，能拆就拆，不要长期遗留。

3. 日志和监控有没有暴露敏感信息？ - 很多时候，攻击者不需要直接拿到你的权限，只要通过日志就能推理出你的系统结构； - 所以后面我也有意识地，让 Agent 日志里少出现“可被直接利用”的信息。

这一圈下来，对我的直接影响是：

以后我再部署一个新的 OpenClaw 环境，第一件事不再是“跑起来做业务”，而是先问自己：

“从公网看，我这台机器长什么样？”

3. Agent 权限模型：把“万能 Agent”拆开

在这之前，我有一个非常典型的“工程师懒惰”：

• 为了提高效率，会倾向于做一些“万能 Agent”；

• 一个 Agent 能管很多平台、很多 Workflow；

• 权限也会配得比较宽，觉得“反正以后扩展方便”。

这次事件之后，我开始系统性地做一件事：

把万能 Agent 拆成“小而专”的 Agent。

具体落地大概是：

• 把涉及敏感操作的功能（比如访问协作平台私聊、操作内容平台后台）拆成专门的 Agent；

• 这些敏感 Agent 的 Workflow 输入输出，尽量只接受“已经脱敏处理过”的数据；

• 给一些“只做内容加工”的 Agent，限制它们可以访问的工具协议范围，不再让它们有机会直接触碰系统层面；

• 对“会对外发送东西”的 Workflow，加了一层人工确认或延迟机制，让自己有时间发现异常。

这套调整还没完全做完，但它已经改变了我设计 Workflow 的习惯：

以后只要有一个新 Agent / 新 Workflow，我会先问：

• 它最低需要什么权限才能完成任务？

• 如果这个 Agent 完全被攻破，最坏能影响到哪里？

4. 定时任务：从“放心跑”变成“可追踪”

在 OpenClaw 里，我有很多定时任务是“写好就丢那儿不管”的：

• 每天自动同步一些数据；

• 每小时跑一遍监控脚本；

• 定期整理记忆、生成报告。

这波 CVE 之后，我做了两件事：

1. 给重要定时任务加“心跳”和“报警”： - 如果某个关键任务没有按时完成，协作平台会推送提醒； - 如果某个任务突然异常频繁地失败，也会触发报警。

2. 定期审计任务列表： - 把已经不再需要的任务彻底关掉，而不是“先留着以后说不定用”； - 给每个定时任务写一个简短说明，方便以后回头看的时候知道它存在的意义。

这样做的另一个副作用是：

我开始把“让 Agent 持续跑下去这件事”，当成一个需要被运营的“产品”，而不只是一个写完就算的脚本。

▲ Agent 系统的主要攻击面

五、更大的问题：OpenClaw 的安全，不只是“官方打补丁”的事

这次 CVE 风波让我意识到一个更现实的问题：

OpenClaw 正在变成很多人数字工作的“操作系统”，但大家对它的安全预期，很多还停留在“脚本工具”的阶段。

1. 三层安全责任：官方、生态、用户

如果用一个很粗糙的划分，我现在会把 OpenClaw 的安全责任看成三层：

1. 官方层面： - 修复已知的实现问题（就像这次的 9 个 CVE）； - 设计合理的默认配置，避免“开箱即用 = 开箱即暴露”； - 提供清晰的安全指南和最佳实践（尤其是部署相关）。

2. 生态层面： - 工具协议的提供方，需要对自己的调用边界有更严格的设计； - 社区里分享的各种 Workflow 模板，最好能对安全风险有基本提示； - 安全研究者继续做“白帽子”，多拉一些红线出来。

3. 用户层面（也就是我这种重度玩家）： - 不要再把 OpenClaw 当成本地脚本跑一跑，而是当成一个“长期在线的服务”； - 把 Agent 权限、Workflow 边界当回事，而不是“先全开，出了问题再说”； - 把部署形态、网络边界、日志暴露当成日常运维的一部分。

2. 对我这种一人公司的现实意义

说得再具体一点，对我这种“一人公司 + 多 Agent 队伍”的模式来说，这次事件起码敲了三个警钟：

1. 用 OpenClaw 搭业务 = 接受持续安全投入 - 它不是拿来写完脚本就扔的工具，而是一个长期在线的基础设施； - 你不能只在功能上迭代，而忽略它的攻击面在变大。

2. Agent 越多，越要收紧 Workflow 边界 - 每多一个 Agent / Workflow，就多一个潜在的攻击入口； - 从设计之初就要给每个 Agent 一个清晰的 SOUL.md、明确的权限边界，而不是做万能管家。

3. “我不是大公司”不是安全豁免理由 - 很多攻击不是精准打击，而是广撒网； - 你只要用了一个足够热门、足够复杂的系统，就是潜在的被击中的那个 IP（虽然我现在尽量不让 IP 直接暴露）。

▲ 实际操作的安全加固步骤

六、给正在用 OpenClaw 的你的一些建议

如果你看到这里，说明你大概率也是 OpenClaw 的重度用户，或者至少在考虑把更多任务搬上来。我根据这次踩坑的经历，总结了几个相对“工程化”的建议，它们不完美，但至少都是真实做过、有效果的。

1. 把“部署拓扑图”画出来

哪怕只是手绘，也建议你做一件事：

把你的 OpenClaw 环境画成一张图：

• 调度中心在哪台机器上；

• 外网 / 内网入口分别在哪里；

• 哪些 Agent 会访问哪些外部服务；

• 哪些 Workflow 之间存在链式调用。

光是画完这张图，你就会清楚很多：“哦，原来这个地方这么关键，原来这个 Workflow 的输入这么敏感。”

2. 从今天开始，把 Agent 当“员工”管理

我现在给每个重要 Agent 都写一个 SOUL.md，大致包括：

包括角色定义、权限范围、安全边界等核心模块。

这听起来有点形式主义，但实践下来一个好处是：

当你想给某个 Agent 新增功能时，会先下意识地问：

“这还算是它的职责吗？如果算，那我是不是要调整一下它的保护级别？”

3. 对所有“对外可连”的入口保持偏执

无论你用不用这次提到的这些 CVE，建议你对所有“对外可连”的入口做三重思考：

1. 有没有可能被扫到？

2. 扫到之后，有没有任何默认安全假设会被打破？

3. 就算被打到这一层，能不能再挡住一手？

OpenClaw 本身会不断变得更安全，但你的部署环境、你的 Workflow 习惯、你的 Agent 设计，仍然决定着你整体的风险暴露面。

4. 把“漏洞公告”当成你的系统实战教材

这次 4 天 9 个 CVE，对我最大的价值其实不是“吓人”，而是提供了一份非常生动的实战教材：

• 每一个 CVE，都对应着一类真实存在的误用模式；

• 你可以借着官方和社区的分析，逐条对照自己的部署；

• 把这些踩坑经验提前吸收掉，比“哪天真翻车了再补救”便宜太多。

如果你愿意把 OpenClaw 当成长期基础设施来用，那么“跟着漏洞公告学安全”这件事，其实迟早要做。

▲ AI Agent 系统的多层安全防御

七、我这次学到的 7 个教训

最后，用一人公司视角，总结一下这次事件给我的 7 个直观教训：

1. OpenClaw 越强，越要把它当“生产系统”而不是“开发玩具”。

2. Agent 越多，越不能偷懒做“万能 Agent”，小而专才好管。

3. 调度中心能不暴露就不暴露，能多一层保护就多一层保护。

4. 沙箱不是护身符，实际的继承边界必须自己验证。

5. 定时任务不是“写完就忘”，而是需要运营和审计的长期资产。

6. 官方补丁只能解决一部分问题，部署习惯和 Workflow 设计同样关键。

7. “我不是目标”不代表“我不在射程内”，热门基础设施的每个用户都在雷达上。

这 7 条看上去很朴素，但它们确实改变了我之后几周里设计新 Workflow、上线新 Agent 的方式。

▲ 最小权限原则的落地实践

往期精选

📌 OpenClaw实战：20个定时任务的血泪史——AI自动化不是自动躺平

📌 OpenClaw实战：Agent输出总翻车？踩坑30天后找到的几个核心原因

📌 OpenClaw实测：稳定输出——记一个3w星框架如何帮我炼出5条AI管理铁律

📌 OpenClaw实战：记忆架构升级——给AI Agent Teams建一个集体大脑

📌 OpenClaw实战：让AI越变越聪明的秘密——每日复盘，自我进化

📌 OpenClaw 实战：AI Agent 团队从1个扩到8个，再砍回4个的真实原因

📌 给 OpenClaw Agent Team 装上记忆——踩了19天坑，终于搞明白了

📌 AI Agent 说“完成了”，我信了——然后被打脸了

📌 实战复盘：OpenClaw 6人Agent Team险些全军覆没

作者：Wesley｜一人公司 × 6个AI员工

转载请联系作者，商业转载需授权。