OpenClaw把权限校验做成了"盲盒"

2026年3月28日前的OpenClaw版本里，藏着一个让产品经理看了会沉默的漏洞。一个只有"配对设备"权限的普通用户，能通过标准流程给自己发一张管理员通行证——就像酒店前台用客房钥匙刷开了金库。

这个漏洞的编号还没被大规模讨论，但技术细节已经公开。问题出在/pair approve这条命令路径上，系统忘了把调用者的权限范围（caller scopes）带进核心的审批检查环节。换句话说，审批流程在验证"这个请求能不能过"时，根本不知道"是谁在点同意"。

权限系统的"传话游戏"是怎么崩的

OpenClaw的设备配对流程设计得不算复杂。用户发起配对请求，管理员审批，设备获得相应权限。但代码实现时，两个关键文件各自为政：extensions/device-pair/index.ts负责扩展层的请求处理，src/infra/device-pairing.ts管底层的基础设施逻辑。

漏洞就卡在这个交接处。当用户通过/pair approve命令批准一个待处理的设备请求时，扩展层没有把自己手里的"调用者权限清单"递给底层。底层只看到"有人在批准"，没看到"批准的人只有配对权限，没有管理员权限"。

更麻烦的是，待处理的设备请求本身可以索要更广泛的权限范围——包括管理员访问权限。于是审批流程成了一个单向漏斗：上层不拦，下层不查，恶意请求直接穿透。

攻击路径简单到像在设计测试用例：先发起一个索要管理员权限的配对请求，再用自己的普通账号批准它。

为什么这种"低级错误"会进生产环境

权限校验的漏洞通常分两类：一类是逻辑设计缺陷，比如"管理员可以删自己"这种规则层面的矛盾；另一类是工程实现漏洞，规则写对了，代码没传对参数。OpenClay这次属于后者，而且是最隐蔽的那种——功能完全可用，安全策略被静默绕过。

从公开的代码路径看，问题出在跨层调用的数据传递上。TypeScript的类型系统本可以在这里设防，如果callerScopes被定义为必填字段，编译时就能拦住。但要么是类型定义宽松，要么是调用方用了类型断言强行过关，最终让undefined或空对象溜进了审批核心。

这种漏洞在代码审查里很难被肉眼发现。评审者看到approve函数被调用，默认参数已经传齐，不会逐层追踪每个字段的流向。自动化测试同理——功能测试验证的是"审批能成功"，而非"审批在错误条件下应该失败"。

修复窗口与行业镜鉴

OpenClaw在3月28日的更新中修补了这个问题。对于运行旧版本的用户，缓解措施包括限制配对权限的分配范围，或监控/pair approve调用中权限范围异常放大的行为。

这个案例给权限系统的设计者提了个醒：跨层调用时的上下文传递，不能依赖"约定"或"惯例"，必须在接口层面强制约束。一个可能的工程实践是，在审批函数的签名里把callerScopes和requestedScopes绑成一对，审批逻辑必须显式比较两者，否则编译不过。

另一个观察是，这类漏洞的利用门槛极低——不需要构造畸形数据，不需要竞态条件，标准API按顺序调两次就行。这意味着攻击脚本可以被高度自动化，批量扫描暴露的OpenClaw实例，用普通账号钓鱼获取初始权限后一键提权。

目前公开渠道尚未看到大规模利用的报告，但NIST的CVE数据库已经收录。对于依赖OpenClaw做设备管理的团队，检查版本号比读十篇分析文章都管用。

最后一个细节：漏洞描述里特意提到了两个文件路径，extensions/和src/infra/的目录结构暗示这是一个插件化架构。核心基础设施与扩展模块之间的信任边界，往往是安全审计的盲区——你上次review自己项目的跨模块调用，是什么时候？