2026 年 10 月 15 日，我们把 OpenClaw 官方仓库的 GitHub Security Advisory（GHSA）全量清单拉下来做了逐条解析。结论有点反直觉：这个项目 100 条安全公告里，严重级别排第一的问题不是”代码有洞”，而是”权限校验写漏了一处”。CWE-863（Incorrect Authorization，授权错误）出现 49 次，CWE-862（Missing Authorization，缺失授权）出现 30 次——两者相加 79 条，占全部公告的 79%。
更值得看的是修复节奏：这些修复被压缩进极少数几个补丁版本里，其中 2026.8.1 一个版本就关掉了 51 条公告，占整个账本的 51%。换句话说，你只要从 2026.8.1 之前直接升到最新，就一次性跨过了全部历史安全债；而如果你卡在 extended-stable 通道的 2026.8.35 上，有 3 条公告在那个版本上根本没修。
本文所有数字来自 GitHub REST API 的原始 JSON 字段（severity、cvss.score、cwes[].cwe_id、vulnerabilities[].patched_versions），逐条统计，不做抽样。抓取时间 2026-10-15。
一、先把账本摊开：100 条公告到底长什么样
OpenClaw 的安全公告没有散落在博客或论坛，而是统一发布在仓库的 Security Advisories 页面。这个页面在 GitHub 侧栏显示为 “Moderate 100″，共 4 页、每页 25 条。
先看整体的严重度分布。需要说明的是，这 100 条的 published_at 字段只有两个日期：2026-06-30（25 条）和 2026-09-11（75 条）。这不是漏洞突然爆发，而是项目在这个时间点把积压的公告集中公开、补齐了披露流程。
| 严重级别 | 条数 | 占比 | 最高 CVSS 3.1 基础分 |
|---|---|---|---|
| High | 51 | 51% | 8.8 |
| Medium | 44 | 44% | 6.5 |
| Low | 5 | 5% | 2.6 |
| 合计 | 100 | 100% | — |
值得注意的是：100 条公告里没有一条 Critical（CVSS ≥ 9.0），最高分是 8.8。GitHub 的 severity 字段与 CVSS 基础分的 High 档（7.0–8.9）在这批数据里 100/100 完全一致，没有出现”标了 High 但分数不到 7″的错配。这是一份口径干净的账本。
另外，100 条公告全部没有分配 CVE 编号（cve_id 均为 null）。如果你在企业漏洞管理平台里按 CVE 检索，这 100 条一条都查不到——只能按 GHSA ID 或 npm 包名匹配。这是一个实操上容易踩空的点。
完整列表可以在 OpenClaw Security Advisories 页面按发布时间查看。
二、核心发现：79% 的公告是同一个根因
按 CWE（Common Weakness Enumeration，通用弱点枚举）统计，前两位是授权类问题：
| CWE | 名称 | 出现次数 | 占比 |
|---|---|---|---|
| CWE-863 | Incorrect Authorization | 49 | 49% |
| CWE-862 | Missing Authorization | 30 | 30% |
| CWE-200 | 敏感信息暴露给未授权主体 | 7 | 7% |
| CWE-918 | 服务端请求伪造（SSRF） | 7 | 7% |
| CWE-400 | 不可控资源消耗 | 6 | 6% |
| CWE-78 | OS 命令注入 | 5 | 5% |
| CWE-22 | 路径遍历 | 4 | 4% |
| CWE-269 | 权限管理不当 | 4 | 4% |
| CWE-639 | 用户可控键导致的授权绕过 | 3 | 3% |
单条公告可以挂多个 CWE，所以这张表的次数总和会超过 100。但趋势毫无争议：授权校验是绝对主战场。
如果你熟悉 OWASP Top 10，会发现一个错位。CWE-863/862 属于访问控制类（OWASP 2021 的 A01），而 SSRF（CWE-918）、命令注入（CWE-78）这些通常更”上头条”的注入类问题，在这里各自只有个位数。一个 AI Agent 项目的攻击面和传统 Web 应用很不一样：它的入口不是表单，而是 IM 消息、语音通话、浏览器会话、MCP 工具调用——每一条都是”谁在说话、这个人有没有权限”。
授权类问题的四种典型写法
从 100 条摘要文本看，授权失败几乎只有四种句式。以官方公告的英文原句为准：
其一，”could omit”（漏掉了检查）——共 12 条。这是最高频的形态：代码路径存在，但某个分支没有调用授权函数。典型如 GHSA-rx8p-qcpv-c7vr：”Prometheus diagnostics could omit operator.read enforcement”（Prometheus 诊断接口可能漏掉 operator.read 权限校验）。这类问题的隐蔽性最强——主流程是对的，只有诊断/边缘端点漏了。
其二，”could ignore”（忽略了已配置的策略）——4 条。系统里有策略配置，但被忽略。危害在于”你明明配了却以为生效”。GHSA-wwcw-jfpp-gpxw（High）：”Codex native tools could ignore per-chat policy”。
其三，”could skip”（跳过了授权）——大量出现在 IM 集成包。授权逻辑存在，但在跨 provider 或跨会话时没被调用。
其四，”without authorization/checks”（根本没有检查）——涉及新加的入口，新功能上线时根本没接授权层。
三、真正值得警惕的：exec 审批被绕过的那一族
授权类问题里，有一个子集的破坏力明显高于其他——exec 审批（approval）被绕过。这一族全部是 High，涉及的是 Agent 唯一真正能造成不可逆损害的动作：在宿主机上执行命令。
我们从账本里完整提取了这一族：
| GHSA | 严重度 | CVSS | 受影响版本 | 修复版本 | 官方摘要 |
|---|---|---|---|---|---|
| GHSA-3fp5-v549-9v66 | High | 8.8 | <= 2026.6.6 |
2026.6.9 | flock 包装器可绕过持久化 exec 审批绑定 |
| GHSA-9f86-pvv5-rxfw | High | 8.0 | < 2026.8.1 |
2026.8.1 | 转义换行符可干扰 exec 白名单解析 |
| GHSA-74gc-hg2m-79p9 | High | 7.5 | < 2026.8.1 |
2026.8.1 | 可复用的 exec 审批可授权被改动的参数 |
| GHSA-3mq7-q27j-mq7q | High | 7.3 | < 2026.8.1 |
2026.8.1 | exec 审批的生命周期可能长于它审核过的工作目录 |
| GHSA-224w-vfr9-h35c | High | 8.8 | < 2026.7.1 |
2026.7.1 | Google Meet 节点命令可跳过 exec 审批 |
| GHSA-7jfq-rmfm-29wp | Medium | 6.4 | < 2026.8.1 |
2026.8.1 | 文件传输审批可扩大持久化权限范围 |
| GHSA-356g-m7rx-7pm3 | Medium | 5.5 | = 2026.7.1-2 |
2026.8.1 | ACP file URL 可跳过工作目录之外的读取审批 |
| GHSA-r88x-r7jj-f2cf | High | 7.1 | < 2026.7.1 |
2026.7.1 | Signal 表情回应可能绑定到错误的审批 |
这八条串起来看，是一个完整的审批生命周期被逐段击穿的过程。举其中最典型的一条：GHSA-3fp5-v549-9v66，官方原文写明"flock wrapper could bypass durable exec approval binding"，影响 openclaw <= 2026.6.6，CVSS 8.8，攻击向量是网络、低复杂度、低权限、无需用户交互，且保密性/完整性/可用性三项全 High。官方 Impact 段落说得直白：攻击者可以让执行或持久化动作绕过调用方的既定授权。
这八条里最值得警惕的是 GHSA-74gc-hg2m-79p9（"可复用的 exec 审批可授权被改动的参数"）和 GHSA-3mq7-q27j-mq7q（"审批的生命周期长于它审核过的工作目录"）。前者的危险在于审批被复用于不同的命令——你批准了 git status，某个逻辑缺陷让这次批准被拿去执行别的东西。后者则是授权范围随时间漂移——审批时目录是安全的，之后目录被替换成了敏感位置，审批却仍然有效。
这两条揭示的是一个设计层面的事实：在 Agent 系统里，"审批"不是一次性动作，而是一份需要持续绑定的授权凭据。它必须绑定到：具体命令 + 具体参数 + 具体工作目录 + 特定时间窗。这四个绑定里少任何一个，审批就会退化成一句"我批准过了"。
白名单解析也是攻击面
GHSA-9f86-pvv5-rxfw 揭示了一个容易忽略的点：exec 白名单本身是一个解析目标。官方摘要"Eescaped newlines could confuse exec allowlist parsing"，配合 CWE-78（OS 命令注入）和 CWE-863 双重标注。这意味着攻击者不需要绕过白名单，只需要让待执行字符串里的换行符被错误解释——解析器视角和白名单策略视角看到的不是同一行。
同类还有 GHSA-ghpx-6xwq-2w4w（"exec 包装器白名单可能信任任意内层命令"，High，2026.8.1 修复）。白名单机制的强度，取决于解析层有多严格，而不是规则列表有多长。
四、修复节奏：一个版本关掉 51 条
这是整份账本里对运维最有操作价值的一张表。把 103 条漏洞条目（部分公告覆盖多个包）按修复版本归并：
| 修复版本 | 关闭条目数 | 累计关闭 | 占全部条目 | 该版本 npm 发布时间 |
|---|---|---|---|---|
| 2026.6.1 | 1 | 1 | 1.0% | 2026-06-03 |
| 2026.6.6 | 10 | 11 | 10.7% | 2026-06-12 |
| 2026.6.8 | 1 | 12 | 11.7% | 2026-06-16 |
| 2026.6.9 | 10 | 22 | 21.4% | 2026-06-21 |
| 2026.7.1 | 20 | 42 | 40.8% | 2026-07-13 |
| 2026.8.1 | 51 | 93 | 90.3% | 2026-08-31 |
| 2026.8.2 | 1 | 94 | 91.3% | 2026-09-01 |
| 2026.8.11 | 3 | 97 | 94.2% | 未在 npm 上 |
| 2026.9.2 | 1 | 98 | 95.1% | 2026-09-05 |
| 2026.9.3 | 2 | 100 | 97.1% | 2026-09-08 |
2026.8.1 一个补丁版本关掉了 51 条，占全部安全债的 51%。 这个版本自身在 npm 上的发布时间是 2026-08-31 02:45:39 UTC，距它所关闭的第一批公告公开（2026-06-30）刚好两个月。
这带来一个非常具体的运维结论：OpenClaw 的安全状态是"版本台阶型"的，不是"持续修补型"的。你不需要逐条跟踪 100 个公告——你只需要判断自己在哪一级台阶上。
- 在 2026.8.1 之前 → 升级即可一次性跨过 90% 的历史安全债
- 在 2026.8.1~2026.9.1 之间 → 还剩 10 条（1 + 3 + 1 + 2，另加 3 条 iOS）
- 在 2026.9.3 及以上 → 全部 103 条已覆盖
五、三个容易踩空的实操细节
5.1 一条公告修四个包
GHSA-g7fw-3gjp-g5hf 是个特例：它在 vulnerabilities 数组里挂了 4 个包——@openclaw/feishu、@openclaw/googlechat、@openclaw/matrix、@openclaw/msteams，受影响版本都是 < 2026.8.1，修复版本都是 2026.8.1，CWE-862 + CWE-863。标题是"Channel read actions could skip target allowlists"（频道读取动作可能跳过目标白名单）。
这意味着 100 条公告实际覆盖 103 个包版本条目，涉及 12 个不同的包名：
| 包名 | 条目数 |
|---|---|
openclaw（主包） |
84 |
@openclaw/feishu |
4 |
OpenClaw iOS |
3 |
@openclaw/discord |
2 |
@openclaw/slack |
2 |
@openclaw/matrix |
2 |
@openclaw/diagnostics-prometheus |
1 |
@openclaw/whatsapp / @openclaw/voice-call / @openclaw/line / @openclaw/msteams / @openclaw/googlechat |
各 1 |
主包占 84 条，另外 19 条散落在 11 个卫星包和 iOS 客户端里。 如果你的资产清单只登记了 openclaw 主包，会漏掉将近五分之一的公告。
5.2 extended-stable 通道并不覆盖全部安全修复
这是最容易被忽略的一条。npm 上 openclaw 的 dist-tags 显示：latest = 2026.10.3，beta = 2026.10.5-beta.4，extended-stable = 2026.8.35。
extended-stable 的设计意图是给生产环境一个稳定的落点。但交叉核对后有三条公告的修复版本高于 2026.8.35，也就是这个通道上的用户拿不到：
| GHSA | 包 | 修复版本 | 摘要 |
|---|---|---|---|
| GHSA-5x6q-wg56-rxg8 | openclaw | 2026.9.2 | Discord 实时转录可能继承另一位说话者的 owner 身份 |
| GHSA-rx8p-qcpv-c7vr | @openclaw/diagnostics-prometheus | 2026.9.3 | Prometheus 诊断接口可能漏掉 operator.read 校验 |
| GHSA-xvwp-wmh2-fq48 | @openclaw/discord | 2026.9.3 | Discord 资源上传可能跳过发送者媒体策略 |
加上 3 条 iOS 公告（修复版本 2026.8.11，该版本从未在 npm 上发布过——iOS 客户端走的是 App Store 分发链路），extended-stable 通道上一共滞留 6 条公告。
如果你用 extended-stable 是为了避开 beta 的变更风险，那这 6 条是你需要单独评估的敞口。其中 GHSA-rx8p-qcpv-c7vr 的影响面要特别注意：Prometheus 是运维监控组件，接入它的通常是有较高权限的基础设施。
5.3 版本区间写法有四种形态，手工核对容易漏
103 条漏洞条目里的 vulnerable_version_range 字段不是统一格式：
| 写法 | 条数 | 示例 |
|---|---|---|
< 版本（简单上界） |
65 | < 2026.8.1 |
>= 低, < 高（区间窗口） |
24 | >= 2026.7.2, < 2026.9.2 |
<= 版本（闭区间上界） |
8 | <= 2026.6.6 |
= 版本（精确锁定） |
3 | = 2026.7.1-2 |
那 3 条精确锁定是最容易在自动化扫描里被漏掉的：
- GHSA-356g-m7rx-7pm3：
= 2026.7.1-2，修复版本 2026.8.1 - GHSA-v7hx-r36p-f68m：
= 2026.6.6，修复版本 2026.6.9 - GHSA-3pmr-x9g8-m55r：
= 2026.6.6，修复版本 2026.6.9
前者的 2026.7.1-2 是一个 npm 上真实存在的预发布版本号，而大多数 semver 范围匹配逻辑处理带连字符后缀的版本时会走到特殊分支。手写 >= 2026.7.1 && < 2026.8.1 这类判断很容易把它算进去，但如果你的规则是"低于 2026.8.1 全部命中"，那另外 24 条区间窗口型条目又可能被误判。
这也是为什么不要自己解析版本区间——用官方通道。GitHub 的 Security Advisories 文档 说明了通告结构与查询方式，npm 上的包元数据也会带上受影响版本信息。
六、怎么判断你的实例处在哪一级台阶
把上面的分析转成一份可执行的自查清单：
第一步：查你的当前版本落在哪个区间
npm view openclaw version
第二步：对照四个关键分界线
| 你的版本 | 状态 | 建议 |
|---|---|---|
< 2026.6.6 |
存在 CVSS 8.8 的 exec 审批绕过 | 立即升级，不要评估 |
< 2026.7.1 |
仍受 exec 审批族 2 条影响 | 尽快升级 |
< 2026.8.1 |
90.3% 的历史安全债未修复 | 升级，这是最重要的台阶 |
2026.8.1 ~ 2026.9.1 |
剩余 7 条（不含 iOS） | 评估是否接受 |
>= 2026.9.3 且非 extended-stable |
全部 103 条已覆盖 | 可以放松跟踪频率 |
2026.8.35（extended-stable） |
6 条未覆盖 | 单独评估这 6 条是否命中你的配置 |
第三步：确认资产清单的完整性
检查你是否同时追踪了 IM 集成包。如果只跟踪 openclaw 主包，19 条公告会被漏掉。具体看哪些集成在用——飞书是条目最多的（4 条），Discord/Slack/Matrix 各 2 条。
第四步：验证 exec 审批的绑定方式
这是本文最想传达的一条工程建议。基于 GHSA-74gc-hg2m-79p9 和 GHSA-3mq7-q27j-mq7q 这两条 High，你的审批配置应当做到：
- 审批绑定到完整命令字符串，而非命令名前缀
- 审批绑定到绝对工作目录，且目录内容变更即失效
- 审批设置有效时间窗，不长期复用
- 对 exec 白名单的输入解析做严格转义，特别是换行符
七、这份数据不能证明什么
为避免过度解读，明确标注本文的口径边界：
UNKNOWN / 未验证项：
- 公告数量上界未知。 GitHub API 对该仓库返回的 100 条是当前全量（侧栏显示 Moderate 100，4 页），但我们只通过 API 分页取到 100 条，无法排除存在未公开或已撤回的条目。100 是已公开量的观测值，不是安全问题的真实总数。
- 未验证任何漏洞的实际可利用性。 本文所有结论来自公告元数据字段，未做任何渗透测试或漏洞复现。CVSS 8.8 是官方评分，不是实测影响。
- 未在真实环境验证升级路径。 版本号与发布时间取自 npm registry 元数据与 GitHub Releases，未实际执行升级、未验证各版本间的兼容性。2026.8.1 一次性关闭 51 条公告这一事实，可能包含相关联的一组修复，但它们是否构成一个可独立回滚的变更集，官方未说明。
- extended-stable 滞留 6 条的判断基于版本号比较，未核实 OpenClaw 是否通过其他方式（如补丁分发）向该通道回补了这几条修复。
- IM 集成包的分发渠道未核实。
@openclaw/feishu等卫星包的版本发布节奏是否与主包同步，官方未公开说明；我们只比对了公告声明的修复版本与 npm 上的发布时间。 - 100 条公告全部无 CVE 编号这一观察基于 GitHub API 的
cve_id字段当前值。CVE 编号存在滞后分配的可能，不能据此断言这些漏洞永远不会有编号。
八、来源
本文全部数据来自以下来源，抓取时间 2026-10-15：
- OpenClaw Security Advisories 列表页 — 100 条公告的官方发布入口
- GitHub Advisory Database：影响 openclaw 的公告 — 跨仓库视角的交叉核对
- GHSA-3fp5-v549-9v66 — flock 包装器绕过持久化 exec 审批绑定，CVSS 8.8
- GHSA-74gc-hg2m-79p9 — 可复用 exec 审批授权改动参数
- GHSA-3mq7-q27j-mq7q — exec 审批生命周期超出审核过的工作目录
- GHSA-jjpc-p3xf-8g7p — iOS Control UI 未强制已保存的 Gateway TLS 固定
- GHSA-g7fw-3gjp-g5hf — 一条公告覆盖 4 个 IM 集成包
- GitHub Docs：Security Advisories — 通告结构与官方查询方式
- npm registry: openclaw — 各版本发布时间与 dist-tags
- OpenClaw Releases — 官方发布记录
- FIRST CVSS v3.1 规范 — CVSS 评分口径
- CWE-863 Incorrect Authorization / CWE-862 Missing Authorization — 弱点分类定义
方法说明：通过 GitHub REST API GET /repos/openclaw/openclaw/security-advisories?per_page=100 拉取原始 JSON，逐条解析 severity、cvss.score、cwes[].cwe_id、vulnerabilities[].package.name、vulnerable_version_range、patched_versions 六个字段，聚合统计得出。全量解析，未抽样。同一公告覆盖多个包时按 vulnerabilities 数组分别计数，故条目总数 103 大于公告数 100。
