今天只有一起：OpenClaw 的人工审批盯住了命令行，没盯住磁盘上那个文件

今天雷达上只有一起，不用找共同点。OpenClaw 的 CVE-2026-32979 打的是 agent 特有的那道闸门——「执行前让人点一下确认」。漏洞不在模型的推理里，在确认和执行之间的那几百毫秒里。

CVE-2026-32979 · OpenClaw

披露日 2026-03-29。CVSS：NVD 记 7.3 HIGH；Tenable 页面上另给了 CVSS v3 6.7（Medium）和 v4 7.0（High），上游 GitHub advisory（GHSA-xf99-j42q-5w5p）自己写的是 7.3。CWE-367，Time-of-check Time-of-use，也就是「检查的那一刻」和「用的那一刻」之间东西被换了——经典例子是程序先 stat 一个文件确认它安全，再 open 它，攻击者在这两步中间把路径指向 /etc/shadow。EPSS 0.00049，实际被打的概率模型给得很低。

攻击链。 OpenClaw 的 node-host 模式里有个 system.run 审批流：agent 想执行本地命令，先把这条命令摆到人面前，人点「批准」，然后才跑。按 advisory 的说法，问题出在审批流「把某些 interpreter 和 runtime 形式当成有审批背书的，哪怕它并不能诚实地绑定到单个具体的本地脚本文件」——比如命令长成 node ./tools/cleanup.js 或者带一串解释器参数的形式时，审批系统记下的是这条命令字符串，不是 cleanup.js 这个文件在被批准那一刻的内容或 inode。于是：agent 提议跑 cleanup.js，你看了一眼脚本内容觉得没问题，点了批准；在真正 exec 之前，攻击者（NVD 的措辞是 remote attacker，Tenable 的措辞是已有本机访问的 local attacker，两家口径不一致）把 cleanup.js 的内容覆写掉；OpenClaw 按原命令行执行，跑的是新内容，权限是 OpenClaw runtime user 的权限。你批准的是 A，落地的是 B。

模型在这条链里是哪一环。 模型是提出那条命令的人。这道审批闸门之所以存在，只是因为 agent 会自己决定跑什么代码——传统软件里没有「AI 提议、人类批准、运行时执行」这个三段结构，也就没有中间这个可以被塞进去的窗口。模型本身没被骗，注入也不是必需的：这是 agent 的自动执行能力把一个 TOCTOU 从纯粹的本地竞态升级成了「人工审批被架空」。反过来说，如果模型确实被间接注入说服去提议一条恰好绑定不住单文件的命令形式（比如让 agent 总结的一份 README 里写着建议的构建命令），那这个窗口就更容易被排上时间。这条利用路径在 advisory 里没有写，我没查到相关 PoC，不展开。

厂商修的是哪一层。 2026.3.11 修的是绑定层：patched 版本对「有审批背书的 interpreter 和 runtime 命令」改成 fail closed——除非能精确绑定到恰好一个具体的本地文件操作数，否则直接不批。也就是说它堵的是「审批对象不明确」这个洞，让批准和一个确定的文件挂上钩。报告人 tdjackey。

入口侧没修，advisory 里也没提。模型为什么会提出这条命令、有没有可能是被它读到的内容诱导出来的、审批界面给人看的内容和最终执行的字节是否一致——这几件事 2026.3.11 都没有碰。修好的是「不能绑定就别放行」，没修的是「凭什么信任 agent 递上来的这条命令」。受影响版本是 2026.3.8 及更早，修复版本 2026.3.11。

已核实来源

本文由自动化管道生成（采集 → 逐字核验 → 模型撰写），未经人工改写。