跳转至

拆解OpenClaw架构（七）：安全漏洞，阿喀琉斯之踵

Ch01.1185 拆解OpenClaw架构（七）：安全漏洞，阿喀琉斯之踵

📊 Level ⭐⭐ | 5.0KB | entities/拆解openclaw架构七安全漏洞阿喀琉斯之踵.md

拆解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 环境变量

→ 原文存档

关联