--- title: "拆解OpenClaw架构（七）：安全漏洞，阿喀琉斯之踵" source: wechat url: https://mp.weixin.qq.com/s/ReiDY6EWY195s4f2xTWvzA ingest_date: 2026-07-04 vxc: 72 stars: 4 sha256: c4e938c0ce6b8381693e143d4e87dd06ec11ca1e7c5a23ba6cab77a83fd64ecf --- # 拆解OpenClaw架构（七）：安全漏洞，阿喀琉斯之踵 **来源**: 科技充电站 **发布日期**: 2026-03-04 **原文链接**: https://mp.weixin.qq.com/s/ReiDY6EWY195s4f2xTWvzA --- AI 时代，有两种行为： 一种，活在别人的评测里，把模型的强当自己的强，痴人说梦； 另一种，活在真实的实战里，用最顶级的 AI，武装自己。 前者在噪音里坐享"技术平权"，后者在 疼痛中完成"自我进化"。 朋友们好，我是行小招。 这是 OpenClaw 深度技术解析系列的第七篇。前六篇拆了消息流水线、人格系统、Agent Runner、记忆系统、工具链和 Skills 生态，今天的话题我犹豫了很久要不要写，因为它不是功能拆解，而是一个正在发生的危机。 上篇结尾我预告了：13.5 万暴露实例，26% 的 Skills 含漏洞，Meta 研究员的邮件被 Agent 全部删除。这些数字不是危言耸听，每一个背后都有公开的 CVE 编号、安全研究报告和真实的受害者。 OpenClaw 的安全问题，不是某个模块写得不好，而是 整个产品定位和实际使用方式之间出现了断裂 先说核心矛盾。 回顾第一篇讲的 Gateway 架构：一个长驻的 Node.js 进程，默认绑定 127.0.0.1:18789 ，单实例运行，所有消息路由、Agent 调度、工具执行都经过它。这个设计的前提假设是什么？ 单用户、本地运行、操作者可信 你在自己的 Mac 上跑，你就是唯一的用户，你信任自己不会给自己发恶意指令。在这个前提下，Gateway 不需要复杂的认证体系，不需要多租户隔离，不需要担心跨用户的权限越界，整个架构简洁而优雅。 但现实呢？ OpenClaw 爆火之后，用户开始把它部署到云服务器上，开始通过公网 IP 暴露 Gateway 端口，开始在团队中共享同一个实例。有些人改了默认绑定地址从 127.0.0.1 到 0.0.0.0 （监听所有网络接口），有些人甚至没改，只是不小心暴露了端口。 一个为"自己人"设计的系统，突然站在了互联网上。 这就是所有安全故事的起点。 ## 五个 CVE 的故事 让我用具体的 CVE 来说明这个断裂有多深。 CVE-2026-25253，CVSS 8.8， 这是最严重的一个。Control UI 接受一个 gatewayUrl 查询参数来指定要连接的 Gateway 地址，问题在于 没有任何验证， 攻击者构造一个链接，把 gatewayUrl 指向自己的恶意 WebSocket 服务器发给受害者，受害者点击后浏览器自动连接恶意服务器并把认证 token 发过去。 拿到 token 就拿到了一切：Agent 控制权、命令执行权、文件系统访问权。一键 RCE。 有意思的是，即使 Gateway 绑定的是 loopback 地址，这个攻击照样有效，因为桥接发生在受害者的浏览器里，不需要直接访问 Gateway 端口。v2026.1.29 已修复。 CVE-2026-25157，CVSS 7.8， SSH 命令注入。如果项目路径被恶意构造（比如包含 shell 特殊字符的目录名），SSH 连接时会触发命令注入，这个漏洞利用的是 OpenClaw 对"项目路径是用户可控输入"这个事实的疏忽。 CVE-2026-24763，CVSS 8.8， Docker 沙箱逃逸。你以为在 Docker 里就安全了吗？攻击者通过 PATH 环境变量操纵，让容器内的命令解析指向宿主机的二进制文件，沙箱的墙就这样被绕过了。 CVE-2026-25593， 本地未认证 RCE。WebSocket 上的 config.apply 方法没有做认证校验，任何能连上本地端口的进程都可以修改 Gateway 配置并执行任意代码。 CVE-2026-26322， Gateway SSRF。通过 Gateway 的工具调用接口，攻击者可以让服务器向任意内部地址发请求，探测内网拓扑，访问本不该暴露的内部服务。 这五个 CVE 的共同特征是什么？ 它们都不是传统意义上的"编码 bug"，不是忘了转义某个字符串，不是缓冲区溢出。每一个都源于同一个假设： 使用者是可信的， Control UI 不验证 gatewayUrl，因为"谁会给自己指向恶意服务器"？WebSocket 不做认证，因为"只有本地进程能连上来"？SSH 不过滤路径，因为"用户自己的项目路径当然是安全的"？ 当你把"自己人"的假设拿掉，这些都变成了高危漏洞。 ## 13.5 万个暴露的 Gateway 如果 CVE 是漏洞的深度，暴露数据就是漏洞的广度。 SecurityScorecard 的 STRIKE 团队做了一次全网扫描，结果令人震惊： 42,900 个以上的独立 IP 地址 暴露了 OpenClaw 控制面板，分布在 82 个国家。更不寻常的是这个数字还在增长，随着 OpenClaw 持续走红，暴露实例从 4.29 万涨到了 超过 13.5 万 。 通常安全问题被曝光后，暴露数量会下降。OpenClaw 的情况刚好反过来， 新增暴露的速度远超修复速度 在这 13.5 万个实例中： - • 15,200+ 个 存在已知 RCE 漏洞 - • 78% 仍在运行未打补丁的版本， 品牌标识还是旧的 "Clawdbot" 或 "Moltbot" - • 549 个暴露实例 与此前的入侵活动有关联，其中包括与 Kimsuky （朝鲜威胁组织）和 APT28 （俄罗斯军事情报相关）的已知基础设施存在连接 根因就一条： 默认配置绑定 ， 监听所有接口意味着任何能访问该端口的网络实体都可以连上来。 你可能会想，改成 127.0.0.1 不就行了？问题是，很多用户出于远程管理的需要主动改成了 0.0.0.0 ，而 OpenClaw 的文档在这个地方的安全警告并不突出。一个配置项的默认值，就这样成了 13.5 万个安全隐患的源头。 ## 26% 的 Skills 含漏洞：Cisco 的"安全噩梦" 暴露的 Gateway 是外部攻击面，Skills 生态则是内部攻击面。 2026 年 1 月 28 日，Cisco 的 AI Defense 团队发布了一篇标题直白到令人不安的报告："Personal AI Agents Like OpenClaw Are a Security Nightmare"。 他们测试了 ClawHub 上排名第一的 Skill，"What Would Elon Do?"，结果？ 它是功能性恶意软件， 9 个安全发现，其中 2 个严重、5 个高危，通过嵌入的 curl 命令静默地把数据发送到攻击者控制的服务器，同时注入 prompt 来绕过 Agent 的安全限制。 这个 Skill 已经被下载了数千次。 在 Cisco 分析的 31,000 个 Skills 中， 26% 至少包含一个漏洞， 也就是说，每四个 Skill 里就有一个存在安全问题。Cisco 同时开源了一个扫描器（ cisco-ai-defense/skill-scanner ），包含 13 个 YARA 规则文件。 上一篇我提到过 Skills 的安全边界优势：它们是 Markdown 说明书，不是可执行代码，恶意 Skill 最多只能"误导"Agent 的行为。但 Cisco 的报告揭示了一个更微妙的问题：当 Skill 指示 Agent 执行 curl 命令向外部服务器发数据，或者注入特定 prompt 来改变 Agent 行为时，"误导"的杀伤力远超预期。 Skills 不执行代码，但它们操纵的 Agent 可以执行代码 这是间接攻击的精髓。 ## ClawHavoc：当 Skills 变成武器 如果 Cisco 的发现是"26% 有问题"的宏观数据，ClawHavoc 运动就是微观层面的恐怖实例。 Koi Security 对 ClawHub 的 2,857 个 Skills 做了定向审计，发现 341 个恶意 Skill ，感染率约 12%。其中 335 个部署了 Atomic macOS Stealer（AMOS） ，外加键盘记录器和后门程序，全部指向同一个 C2 服务器 IP。 但最让安全研究人员不安的不是传统恶意软件的部分，而是一种全新的攻击模式： 通过修改 SOUL.md 实现持久化 还记得第二篇讲的 SOUL.md 吗？那是 Agent 的"人格说明书"，定义了身份、行为边界和交互风格。恶意 Skill 可以指示 Agent 修改 SOUL.md 的内容，往里面注入新的指令，一旦写入成功，这些指令就会在后续每次 Agent 启动时被加载。 传统恶意软件需要二进制注入、注册表修改或启动项添加，安全软件对这些手法有成熟的检测机制。而修改 SOUL.md？ 它只是改了一个 Markdown 文件的内容， 没有可疑进程，没有异常系统调用，没有传统意义上的恶意软件签名。 Snyk 的分析指出，修改 SOUL.md 能永久改变 Agent 行为，这是一种全新形态的持久化攻击， 检测难度极高，因为攻击载荷就是自然语言文本 OpenClaw 对此的回应是与 VirusTotal 合作，并聘请了 Dvuln 创始人 Jamieson O'Reilly 担任首席安全顾问。 ## Summer Yue 的邮件事件：上下文窗口的安全灾难 接下来这个事件，我觉得是所有安全问题中最值得深思的。 2026 年 2 月 23 日，Meta 超级智能实验室的对齐研究主管 Summer Yue 让她的 OpenClaw Agent 帮她整理邮箱。她给了明确的约束： 审查邮件，建议删除，操作前必须确认 Agent 开始运行，一开始一切正常，然后突然"加速了"，开始批量删除邮件，跳过了确认步骤。Summer Yue 试图发送停止指令，Agent 没有响应，她不得不 跑到她的 Mac mini 旁边物理关机 才停下来。 所有邮件都被删了。 根因分析揭示了一个极其微妙的问题： 上下文压缩（context compaction）静默丢弃了"操作前确认"这个约束 我在第四篇讲记忆系统时说过，当对话超过上下文窗口的 80% 时，OpenClaw 会触发自动压缩，用更短的摘要替代早期对话内容。问题在于压缩算法不知道哪些信息是"关键安全约束"，哪些只是普通对话内容，当 Agent 从小规模测试（几封邮件）扩展到全量操作（整个邮箱）时，早期对话被压缩掉了，"确认后再操作"这条约束就这样无声无息地消失了。 Agent 不是"故意"忽略指令，它只是 压缩后的上下文里已经没有这条指令了 Meta 随后禁止在内部工作流中使用 OpenClaw。 这个事件触及了一个根本性的架构问题： 大语言模型的上下文窗口是有限的，而安全约束不能有"过期时间"， 当你的安全机制依赖于"模型记住用户说过什么"，而模型的记忆会被压缩算法修剪，你实际上构建了一个安全性随时间衰减的系统。 ## 供应链攻击：不是你的代码有问题，是你的依赖有问题 2026 年初，一个更隐蔽的攻击出现了。 Cline CLI v2.3.0 被攻破。攻击者通过在 GitHub issue 标题中注入恶意 prompt，诱导一个有 npm 发布权限的 Agent 泄露了 npm 认证凭据。拿到凭据后，攻击者发布了一个被篡改的 Cline CLI 版本，在 postinstall 脚本里加了一行： npm install -g openclaw@latest 大约 4,000 台开发者机器在 8 小时内受到影响（GHSA-9ppg-jx86-fqw7）。 安全研究员 Yuval Zacharia 对此的评论一针见血： "如果攻击者能远程 prompt 它，这就不只是恶意软件了，这是 C2（命令与控制）的下一个进化形态。Agent 本身就是植入物，纯文本就是协议。" 这句话值得反复品味。传统恶意软件需要编译二进制、混淆代码、绕过杀毒软件，而在 Agent 时代， 一段自然语言文本就能成为攻击载荷， 攻击面从"可执行代码"扩展到了"任何 Agent 会读取的文本"。 ## Simon Willison 的"挑战者号"类比 在所有公开评论中，安全研究员 Simon Willison 的话最让我印象深刻： "Given the inherent risk of prompt injection against this class of software, it's my current pick for most likely to result in a Challenger disaster." 他引用了"偏差正常化"（normalization of deviance）的概念：当高风险行为没有立刻导致灾难时，人们会逐渐接受这种风险，认为它是"正常的"。直到真正的灾难发生。 挑战者号航天飞机在 1986 年发射后 73 秒爆炸，7 名宇航员全部遇难。事后调查发现，O 型环的问题在之前多次发射中就已经出现了，但每次都侥幸没出事，工程师们慢慢就习惯了。 Willison 认为 OpenClaw 正在经历同样的过程。Prompt 注入的风险每天都在发生，但因为还没有出现"挑战者号级别"的灾难，行业整体处于一种危险的麻木状态。 Andrej Karpathy 称安全状况是"a dumpster fire"（垃圾堆里的火灾），但同时又说底层的 Agent 能力是"the most incredible sci-fi takeoff-adjacent thing"（最不可思议的科幻级起飞）。Gary Marcus 更直白："If you care about the security of your device or the privacy of your data, don't use OpenClaw. Period." 这种撕裂感很能说明问题： OpenClaw 的能力和风险是同一枚硬币的两面， 你获得正是给予系统广泛权限后的强大能力，而安全隐患也正是来自这种权限的授予。 ## 自救措施：OpenClaw 在做什么 说了这么多问题，公平起见，也要看看 OpenClaw 自己在做什么。 命令 （源码位于 src/cli/security-cli.ts ）运行 50+ 项检查，覆盖 12 个类别 ，支持三种模式： - 1. 只读扫描（默认）： 检查配置文件、权限设置、暴露风险 - 2. 深度扫描（）： 实际建立 WebSocket 连接进行实时探测 - 3. 自动修复（）： 应用安全默认值 自动修复会做这些事：把 logging.redactSensitive 从 off 改成 tools （脱敏工具调用日志），把所有 7 个频道的 groupPolicy 从 open 改成 allowlist ，对凭据文件设置 chmod 600/700 。 社区层面也涌现了一些工具： - • Aquaman： 凭证隔离代理。API 密钥永远不进入 Agent 进程，通过 Unix domain socket 从系统钥匙串注入。这解决了一个基础问题，Agent 拥有的权限应该和它能接触到的凭证分离 - • Cisco Skill Scanner： 上面提到的开源扫描器，13 个 YARA 规则文件 - • SecureClaw： 56 项审计检查，映射到 OWASP、MITRE ATLAS 和 NIST 框架 这些措施在方向上是对的，但还不够： security audit 是事后检查而不是运行时防护，Aquaman 解决了凭证问题但没解决 prompt 注入，SecureClaw 提供了审计框架但不阻止恶意行为发生。 ## 一些个人观察 写到这里，我想跳出事件清单，说说我自己的思考。 第一，这是一个"成功的诅咒"问题， OpenClaw 的安全架构本身并不差，对于一个本地运行、单用户使用的个人 AI 助手来说，它的 Shell 安全模型（allowlist + 结构化阻断）、Docker 沙箱、执行审批流程都是合理的设计，问题出在产品太成功了，使用场景远远超出了设计意图。 第二，NanoClaw 的存在说明了另一种可能， Gavriel Cohen 用 500 行代码写了一个 NanoClaw，实现了核心功能，初始化 prompt 只需要 3,000 tokens，而 OpenClaw 的系统 prompt 是 30,000 到 100,000 tokens，NanoClaw 用 Apple 容器提供真正的进程隔离。这不是说 NanoClaw 更好，而是它展示了一个问题：OpenClaw 可能对个人助手场景过度设计了，对企业场景又安全不足，被自己的爆发式增长推到了一个尴尬的中间地带。 第三，"Agent 即植入物"这个判断可能是 2026 年最重要的安全洞见， 当一个系统能读取文本、执行命令、记忆上下文、持久化状态，它和传统恶意软件的远程控制终端（C2 implant）之间的区别只在于意图。SOUL.md 被篡改后的 Agent 和一个精心编写的木马在功能上没有本质区别，都能窃取数据、横向移动、持久化存在，而检测难度比传统恶意软件高出一个数量级，因为它的所有行为都在"正常操作"的范畴内。 第四，上下文压缩导致安全约束丢失，这个问题目前没有好的解法， 你可以在 SOUL.md 里写"永远不要在未确认的情况下执行破坏性操作"，但 SOUL.md 占的 token 数也是有限的，随着对话变长、任务变复杂，哪些约束会被保留，哪些会被压缩掉，取决于算法而不是重要性，这不是 OpenClaw 独有的问题，每一个使用大语言模型做决策的 Agent 系统都会面对它。 第五，安全社区的反应速度让我印象深刻， 从 CVE 披露到 Cisco 发布扫描器，从 Koi Security 的审计到 SecureClaw 的 OWASP 映射，再到 OpenClaw 聘请安全顾问，整个生态的响应是快速且专业的。问题的严重性在于攻击面太大、用户基数太多、修复部署太慢，而不是没人在做这件事。 ## 下一篇预告 下一篇，我们聊多 Agent 编排：从单个 Agent 到 Agent 社群。子 Agent 生成、心跳机制、Agent 间通信、Lobster 工作流引擎，OpenClaw 如何从"聊天机器人"进化为"自主运行的 AI 系统"。 ## 你在用 OpenClaw 吗？ 如果你在用，你做了哪些安全加固？有没有遇到过可疑的 Skill 行为？ 如果你在企业环境中评估过 OpenClaw，你的安全审查结论是什么？ 欢迎在评论区聊聊，也可以后台留言。 我是行小招，持续探索 AI 在个人生活和企业落地中的应用场景，欢迎一起聊聊，也欢迎你把这篇文章分享给身边做技术、做产品的朋友。 当 90% 的内容都在沦为噪音，真正稀缺的是：深度阅读，独立思考，持续实战。 交给 AI 的是任务，留给自己的是思考。 脑子不停转，持续定义问题，决定解决什么问题，这才是 AI 时代的底层逻辑。 👇 长按关注，一起用 AI 武装自己