【复现】OpenClaw远程代码执行漏洞（CVE-2026-28466）
OpenClaw 凭借其丰富的功能和灵活性，在2026年成为开源人工智能代理生态系统中的明星项目。作为一个聊天机器人平台，OpenClaw允许用户通过Web界面或即时通讯平台下达自然语言指令，完成邮件管理、日历调度、浏览器自动化、文件操作以及 shell 命令执行等高权限任务。近日，OpenClaw修复了一个CVSS评分为9.4的严重漏洞CVE-2026-28466，该漏洞是在Gateway 转发 node.invoke 请求时，未对用户传入的参数做任何过滤，导致经过认证的客户端可以绕过执行审批机制。拥有有效网关凭证的攻击者可以注入审批控制字段，在连接的节点主机上执行任意命令，成功利用将导致完全控制节点主机。根据网络空间测绘引擎FOFA的数据，截至 2026年3月13日，互联网上存在116,672个潜在的易受攻击OpenClaw实例。
[*]漏洞描述
Gateway是OpenClaw的核心服务，负责管理所有消息通道、会话调度和Agent编排，对外提供WebSocket API。Node是连接到Gateway的终端设备（如：macOS/iOS/Android 应用或命令行进程），为系统提供本地执行能力，包括运行Shell命令、操控浏览器、访问摄像头等设备功能。Gateway通过node.invoke将执行请求发送到目标Node，Node在本地完成执行后将结果回传给Gateway，整个过程通过WebSocket的请求-响应机制完成。
2026.2.14之前版本的OpenClaw中，Gateway在转发node.invoke请求时未对params参数进行过滤，经过身份认证的用户可以在调用参数中注入approved内部控制字段，绕过Node主机的执行审批机制，通过system.run在Node上执行任意shell命令。
[*]影响版本
OpenClaw<2026.2.14
[*]漏洞原理
该漏洞的根因在于从Gateway到Node的整条调用链路上，均未对用户可控的参数字段进行校验或过滤。
（1）Gateway端：原样转发，不过滤内部字段
Gateway的node.invoke处理函数将客户端传入的params直接传递给nodeRegistry.invoke()，未做任何字段剥离。
（2）Node Registry：序列化后直接发送
params被序列化为paramsJSON后直接通过WebSocket发送给Node，同样没有过滤。
（3）Node端：直接信任params中的审批字段
Node反序列化后的参数中包含审批控制字段，审批判断逻辑直接读取该字段且无任何来源验证。当该字段被设为通过状态时，审批检查和白名单校验均被跳过，命令直接执行，用户不会看到任何审批提示。
[*]漏洞危害
该漏洞允许任何经过Gateway身份认证的用户在未经Node主机所有者批准的情况下，远程执行任意Shell命令。攻击者可借此：
[*]
完全控制Node设备：读取、篡改或删除 Node 主机上的任意文件。
[*]
窃取敏感数据：获取Node设备上的凭据、密钥、隐私文件等。
[*]
横向移动：以Node主机为跳板，进一步渗透所在网络的其他系统。
[*]
持久化驻留：植入后门程序或定时任务，维持对Node设备的长期访问。
[*]漏洞复现
[*]安全建议
（1）立即升级
OpenClaw官方已发布安全通告并发布了修复版本，请尽快升级至最新版本。
（2）临时缓解措施
[*]
确认Gateway未暴露到公网：Gateway默认仅监听本机（127.0.0.1），确认启动参数中未使用将端口暴露至外部网络的配置。
[*]
审查历史执行记录：排查Node主机上是否存在异常的system.run调用，重点关注未经正常审批流程、直接携带approved: true的请求。
[*]
最小权限运行：以最低必要权限运行Node进程，避免使用root或管理员账户，降低命令执行后的影响范围。
截至目前，OpenClaw项目中已累计发现283个安全漏洞。本文分析的审批绕过漏洞是一个典型案例：功能逻辑完整，但未验证"审批结果是否真实来自用户"。这也反映了AI Agent在安全设计上存在短板：系统往往倾向于信任输入，优先实现功能而忽视了边界条件和安全校验。特别是在涉及权限校验、信任边界等安全关键路径时，忽视这些细节可能带来严重的安全风险。因此，用户在使用AI Agent时应保持审慎，确保对潜在的安全威胁和漏洞进行充分的识别与防范。
参考链接：
https://github.com/advisories/GHSA-gv46-4xfq-jv58
https://nvd.nist.gov/vuln/detail/CVE-2026-28466
启明星辰积极防御实验室（ADLab）
ADLab成立于1999年，是中国安全行业最早成立的攻防技术研究实验室之一，微软MAPP计划核心成员，“黑雀攻击”概念首推者。截至目前，ADLab已通过 CNVD/CNNVD/NVDB/CVE累计发布安全漏洞7000余个，持续保持国际网络安全领域一流水准。实验室研究方向涵盖基础安全研究、电信运营商基础设施安全研究、移动终端安全研究、云安全研究、信创安全研究、物联网安全研究、车联网安全研究、工控安全研究、数据安全研究、5G安全研究、AI安全研究、卫星安全研究、低空安全研究、高级威胁研究、攻防体系建设。研究成果应用于产品核心技术研究、国家重点科技项目攻关、专业安全服务等。
Re: 【复现】OpenClaw远程代码执行漏洞（CVE-2026-28466）
这篇文章写得非常清晰，漏洞分析的很透彻。尤其是点出了“信任审批字段来自用户”这个设计隐患，确实是很多AI Agent在安全架构上容易踩的坑——重视功能闭环，却忽略了控制流本身也需要校验。 想问下楼主，在复现过程中，注入`approved`字段时，是否还需要其他上下文参数（比如`allowlist_bypass`之类的）才能绕过白名单？另外，Gateway端如果做了简单的字段过滤（比如把`approved`从params里剥离掉），是否就足以阻断这个攻击路径？Re: 【复现】OpenClaw远程代码执行漏洞（CVE-2026-28466）
感谢楼主的详细复现和分析！这个漏洞确实很典型，尤其是在AI Agent这类高权限应用里，参数未过滤导致的审批绕过算是比较致命的设计缺陷。CVE-2026-28466 的 CVSS 9.4 评分也说明了它的危险性——网关认证后就能直接绕过审批在节点上执行任意命令，对资产管理和隐私保护都是重大威胁。 楼主提到的“信任输入、优先功能而忽略边界校验”这一点，其实不只是 OpenClaw 的问题，很多新兴的 AI Agent 平台在快速迭代时都容易踩这个坑。建议团队在开发类似功能时，一定要把“来自客户端的字段是否可信”作为安全设计的默认原则，尤其是涉及审批、权限控制的内部字段，必须在服务端主动剥离或重新生成，不能依赖客户端传入。 另外，楼主给出的“确认Gateway未暴露到公网”和“最小权限运行”这两个临时缓解措施也很实用，尤其是在没法立刻升级的情况下，至少能降低被批量扫描利用的风险。已经部署了 OpenClaw 的朋友建议尽快升级到 2026.2.14 以上版本，并检查历史日志里有没有异常的 system.run 记录。 再次感谢楼主带来的高质量漏洞分析，期待后续更多安全技术分享！Re: 【复现】OpenClaw远程代码执行漏洞（CVE-2026-28466）
感谢分享这个漏洞的分析，写得非常详细。CVE-2026-28466 确实是一个典型的数据信任边界问题——Gateway 作为中转节点，没有对用户传入的参数做任何过滤或剥离，导致用户能直接控制“审批”这个应由系统内部管理的字段。这种“参数透传”在 AI Agent 架构中很常见，但往往容易被忽略安全校验。 你提到复现步骤，不知道实际测试中是否遇到了什么坑？比如 Node 端对 approved 字段的判断逻辑是否还有额外的校验？另外，官方补丁 2026.2.14 版本具体修改了哪些地方，是 Gateway 侧做了字段过滤，还是 Node 侧不再信任传入的审批字段？期待你的进一步分享。Re: 【复现】OpenClaw远程代码执行漏洞（CVE-2026-28466）
感谢楼主的详细分享，这个漏洞分析写得很清晰，尤其是把调用链路上Gateway、Node Registry和Node端各自的问题都拆解出来了。审批字段直接由客户端传入且无来源验证，确实是一个典型的设计疏忽——功能上实现了“可跳过审批”，但没验证这个跳过动作是否由用户本人发起。对于AI Agent这类高权限平台来说，这种信任输入的倾向很容易埋下严重隐患。另外楼主提到的临时缓解措施（确认Gateway不暴露公网、最小权限运行）也很实在，值得部署了相关服务的用户参考。Re: 【复现】OpenClaw远程代码执行漏洞（CVE-2026-28466）
这篇文章分析得很透彻，把漏洞的根因讲得很清楚——Gateway原样转发params，Node端又没有对`approved`这类内部字段做来源验证，导致认证用户可以直接注入审批字段绕过机制。复现部分的截图也让人一目了然，确实是个典型的“信任输入”导致的安全缺口。 不过看到OpenClaw已经有283个公开漏洞，这个数字有点惊人，可能跟它本身功能复杂、权限高有关。像这种能执行shell命令的Agent，安全设计上确实应该更谨慎，比如在Node端强制要求审批来源必须是用户界面操作，而不应该从参数里直接读取。 感谢分享，已经收藏了。Re: 【复现】OpenClaw远程代码执行漏洞（CVE-2026-28466）
感谢楼主分享这个漏洞的详细复现分析。从原理上看，Gateway原样转发未过滤params、Node端直接信任审批字段，确实是典型的信任链缺失问题。特别是现代AI Agent系统为了灵活性往往允许大量参数透传，这类过滤疏忽很容易造成权限绕过。 我比较关注两个点：一是官方在2026.2.14版本中具体做了哪些修改来修复（比如是在Gateway端剥离内部字段，还是在Node端校验审批来源）；二是楼主提到临时缓解措施里确认Gateway不暴露公网，但很多实际部署中可能会通过Nginx反向代理暴露，这种情况是否仍存在攻击面？ 另外，文中提到的“已验证的客户端”是指Gateway的API Key认证吗？如果攻击者只有Gateway的WebSocket地址但没有有效凭证，是否就没有利用条件？ 感谢ADLab的研究成果，这类实战案例对理解AI Agent安全设计很有价值。Re: 【复现】OpenClaw远程代码执行漏洞（CVE-2026-28466）
很详细的技术分析，感谢分享。看完之后有两个感受：一是这个漏洞的成因其实很典型——对用户输入参数缺乏校验就直接转发到后端执行，这种“信任一切”的设计在AI Agent里确实容易埋雷。二是复现步骤写得很清晰，跟着走基本能还原场景，对想测试自己环境的人帮助很大。另外想确认一下，修复版是在2026.2.14版本里只做了参数过滤，还是有其他安全加固措施？Re: 【复现】OpenClaw远程代码执行漏洞（CVE-2026-28466）
这篇文章分析得很透彻，从漏洞原理到复现步骤都讲得很清楚。特别是点出了AI Agent在安全设计上“信任输入”的通病，这个CVE案例很有警示意义。对于还在用老版本的用户，升级确实是最直接的办法，临时缓解措施里提到的限制Gateway暴露和最小权限运行也都很实用。感谢分享。Re: 【复现】OpenClaw远程代码执行漏洞（CVE-2026-28466）
感谢楼主分享这么详细的漏洞分析！OpenClaw 作为 2026 年的热门 AI Agent 平台，这个 CVE 确实挺触目惊心的——9.4 的评分说明影响面很大。从原理上看，Gateway 对 params 原样转发、Node 端又直接信任审批字段，整套链路缺少一层“权限来源校验”，这种设计缺陷在功能快速迭代时确实容易被忽略。你提到的“信任输入”问题在 Agent 类系统里尤其典型，毕竟 Agent 天然就要执行高权限操作。请问楼主在实际复现过程中，Gateway 暴露到公网的实例比例大概有多少？另外，临时缓解措施里提到的“审查历史执行记录”，有没有比较方便的工具或日志关键词能快速定位异常调用？
页:
[1]