7 月 17 日复盘｜AI 审计器发现 OpenVM 旧漏洞
7 月新增的是审计复盘；漏洞影响客体配对库，五月已修复。
本文要点
- 从只知道五月已有安全修复，变成可以检查 AI 如何生成候选发现与最小 PoC。
- 从笼统讨论 AI 找漏洞，变成明确划分机器发现与人工验证、定级和披露。
- 从把问题理解为 zkVM 本体漏洞，变成限定到 openvm-pairing 客体库。
阅读辅助
先看数字、证据和来源，再读正文。
7 月 17 日的新闻增量是审计复盘，不是当天发现、修复或发布安全版本。
约 2026-03 · ZK/SEC 回溯称其四个月前扫描 OpenVM；这是相对日期，不是精确发现日。
先看状态：OpenVM 的漏洞处置早在五月完成，7 月 17 日新增的是 ZK/SEC 对审计过程的复盘。复盘给出一条较完整的 AI 审计证据链：机器生成候选发现和最小 PoC，人工再验证可利用性、判断影响并协调披露。
确定事实是，问题编号为 CVE-2026-46669，影响 openvm-pairing 客体库中 BN254 与 BLS12-381 的优化配对检查。公开修复提交在 5 月 15 日进入仓库，OpenVM 1.6.0 安全版本和 GHSA 公告也在当天发布。ZK/SEC 到 7 月 17 日才发布复盘，因此当天新增的是方法、分工和技术细节，而不是发现、修复或安全版本。
不确定部分主要来自审计方自报。9.5 小时以上是 ZK/SEC 对 zkao 扫描时长的表述，外界尚无同配置复现，也没有完整候选数量、模型调用成本、误报率和人工复核工时。文章还称据其所知，基于 OpenVM 的合作方已经升级；公开材料没有给出项目清单或独立版本数据。
对密码项目维护者，这个案例可借鉴之处是模块知识如何在 Agent 之间传递，以及人工分诊如何围绕可利用性而非“看起来像漏洞”展开。对 OpenVM 使用者，行动仍是确认依赖已到 1.6.0 或更高版本；但不应把七月复盘误读为新补丁，也不应把客体库问题扩大成 zkVM 证明系统自身失效。
先把日期拆开
这起事件至少有四种日期：扫描或发现、修复进入仓库、安全公告与版本发布、复盘公开。它们不能压成“7 月 17 日 AI 发现并修复漏洞”一句话。
| 节点 | 可核对时间 | 当时发生了什么 | 正确新闻口径 |
|---|---|---|---|
| zkao 扫描 | 约 2026 年 3 月 | ZK/SEC 仅回溯称“四个月前”扫描 | 只能写相对时间，不能编造精确发现日 |
| 修复提交公开 | 5 月 15 日 17:30:45 UTC | 提交 a720e2c 加入 Fp6 子域检查与测试 | 五月旧修复，不是七月提交 |
| 安全版本发布 | 5 月 15 日 18:42:29 UTC | OpenVM 1.6.0 发布并建议旧用户升级 | 五月安全版，不是七月发布 |
| GHSA 公告发布 | 5 月 15 日 18:52:19 UTC | 公告确认受影响包、版本与 Critical 等级 | 五月公开处置的一部分 |
| CVE 记录 | 五月保留，6 月 10 日公开记录 | CVE 元数据后续进入公开记录 | 不能写成七月新增 CVE |
| 审计复盘 | 7 月 17 日 | ZK/SEC 解释扫描、分诊、漏洞原理和修复 | 这是过去 24 小时的 news peg |
修复提交还包含一个容易误判的元数据差异：GitHub API 中 author date 是 3 月 17 日，committer date 是 5 月 15 日。本文所说“五月修复提交”指它进入当前公开仓库历史和安全版本的时间，不把作者元数据改写成五月才开始修复。类似地，CVE Record 显示编号在五月保留、记录在六月公开；这两个状态也不应混成同一天。
这套拆分很重要，因为安全新闻的风险判断依赖状态。七月读者面对的是一个已经有补丁、已有安全版本、随后公开方法复盘的旧漏洞。若把状态写成“当天新发现”，会制造错误紧迫感；若只写“五月已经修好”，又会丢掉七月真正新增的 AI 审计流程证据。
漏洞位于客体库，不是证明系统本体
ZK/SEC 在文章开头明确划线：这是 openvm-pairing guest library 的 soundness bug，不是 OpenVM zkVM 证明系统自身的 soundness bug。这里的 guest library 可理解为在 zkVM 客体程序中提供密码运算的库。只有调用受影响配对检查的代码才会继承问题，不能由此推出所有 OpenVM 证明都不可靠。
受影响函数用一种优化方法检查配对等式。配对常用于 Groth16、基于 KZG 的证明系统和 BLS 签名；验证者往往关心若干配对乘积是否等于一。完整的最终幂运算在电路中成本很高，因此实现会让证明者提供额外提示，再用更便宜的关系完成检查。
问题在于，便宜关系成立还需要一个关键前提：提示中的缩放因子必须属于 Fp12 的适当子域 Fp6。OpenVM 当时检查了另一个提示值不为零，却没有约束缩放因子位于 Fp6。于是恶意证明者可以令 c=1，再把缩放因子设为 Miller loop 结果的逆元，使被检查的乘积退化为一。这样即使原始配对等式错误，优化路径也会返回成功，较慢的完整后备检查不会再执行。
| 对象 | 修复前缺口 | 可造成的结果 | 五月修复 |
|---|---|---|---|
| BN254 配对检查 | 缩放因子 u 未验证属于 Fp6 | 错误配对等式可能被接受 | 检查第 1、3、5 个 Fp2 系数为零 |
| BLS12-381 配对检查 | 缩放因子 s 未验证属于 Fp6 | 错误配对等式可能被接受 | 加入同样的 Fp6 成员检查 |
| 调用方 | 信任客体库返回的配对结果 | 上层验证逻辑可能继承错误结果 | 升级到 OpenVM 1.6.0 及以上 |
| zkVM 证明系统本体 | 不属于本次漏洞范围 | 不能据此声称证明系统自身失效 | 仍需与客体库风险分开评估 |
GHSA 把所有低于 1.6.0 的 openvm-pairing 用户列为受影响，并说明不诚实证明者可提供恶意 hint，让任意配对检查通过。修复提交直接在 BN254 和 BLS12-381 两条路径加入三个系数检查，同时增加“坏提示不能通过子域检查”的 host test。改动很短，但它补回的是优化定理成立所需的安全前提。
影响也必须按使用场景表达。ZK/SEC 列举 KZG opening、Groth16 验证、BLS 签名检查和模拟以太坊 ecPairing 预编译等潜在上层用途。这些是“若应用调用受影响库则可能继承”的技术路径，不是已发生攻击清单。公开材料没有证明所有 OpenVM 应用都使用该函数，也没有披露真实在野利用。
AI 发现与人工确认是两段工作
ZK/SEC 对 AI 角色的原文边界很清楚：AI produced a candidate finding, not a final report。准确中文是“AI 生成候选发现，不是最终报告”。它没有声称 AI 独立完成完整漏洞披露，更没有把人工工作缩成签字确认。
| 环节 | zkao 或模型承担的工作 | 人工团队承担的工作 |
|---|---|---|
| 代码扫描 | 读取代码与研究材料，生成候选发现 | 设计审计流程与上下文工程 |
| 初步材料 | 给出详细报告和最小 PoC | 检查 PoC 是否利用真实约束而非模拟或绕过 |
| 可利用性 | 给出 Critical 初评 | 验证漏洞确实可利用，排除表面问题 |
| 影响范围 | 提供代码路径与攻击思路 | 理解完整影响并识别受影响项目 |
| 披露处置 | 不独立承担 | 与 OpenVM 团队协调披露、修复和发布 |
文章称，普通 LLM 方案先后使用 Opus 4.6、Codex 5.3，随后又尝试 Opus 4.7 与 Codex 5.4。那些候选虽然是有效代码观察，模型也曾自信标为 Critical 或 High，但最后都不具备实际可利用性，并被人工分诊降为 Informative。ZK/SEC 对原因的解释是，zkVM 模块之间依赖密集，简单地按目录拆给子 Agent，会丢失跨模块假设与组合不变量。
zkao 的区别被描述为上下文工程，而不是单纯换了一个更大的模型。审计方称其把专家阅读代码的工作方式编码为可复用流程，并让名为 cryptopsy 的流程在实现与学术文献之间往返。扫描运行 9.5 小时以上后返回多项发现，团队没有逐一深挖全部结果，而是在快速浏览中挑出这项配对检查问题。
这意味着 9.5 小时以上不能被理解为“AI 用九个半小时独立完成了一次可发布审计”。它只覆盖 ZK/SEC 自报的扫描阶段；此前需要准备 skills 和流程，此后还需要人工分诊、验证、影响分析与披露。公开文章没有提供总 token、API 成本、并行度、硬件、候选总数和每项复核时间，因此外部团队目前无法计算完整人机成本。
最小 PoC 也不是自动可信的终点。ZK/SEC 反而在复盘中提醒，早期“让模型把报告改成可运行 PoC”的自动分诊方法信号很弱：模型可以通过修改 helper、关闭检查、模拟状态或使用可疑运行参数，让并不存在的利用看似通过。这个案例中，最小 PoC 帮助人工快速判断值得上报，但最终可信度来自人工确认和维护者修复链，而不是“代码跑绿”本身。
严重性需要保留两套口径
分诊中的核心值是 Critical：ZK/SEC 称 zkao 初评为 Critical，OpenVM 的 GitHub Security Advisory 也标为 Critical。修复提交、公告和版本把这项问题纳入正式安全处置，证据链比单一模型输出更强。
同时，公开 CVE Record 后续给出的 CVSS 4.0 基础分是 8.7，High。这不等于 OpenVM 把 Critical “降级”为 High，也不意味着两份材料必有一方错误；GitHub advisory severity 与 CVSS 4.0 是不同的标度和发布记录。本文保留 story 的 Critical 核心值，并把 CVSS 差异作为边界，而不把两个等级强行合并。
同样要克制处理升级覆盖。ZK/SEC 原文是“As far as we know, all partners building on OpenVM have since upgraded to that version”。忠实中文应是“据其所知，基于 OpenVM 的合作方此后都已升级到该版本”。它不是公开遥测证明的全生态 100% 升级率，也不覆盖未知的私有部署和未被列为 partner 的使用者。
这次复盘最有价值的地方，是把“AI 找到漏洞”拆成了可以检查的生产链。机器擅长扩大搜索面、生成候选解释和最小 PoC；人工负责判断 PoC 是否真实、漏洞能否利用、哪些项目受影响，以及何时以什么方式披露。把这两段工作写清，比再宣传一次全自动安全工程更接近真实部署。
案例还说明，密码代码审计的瓶颈不只是上下文窗口长度。即使给模型数十万乃至百万 token，按文件夹切分任务也可能漏掉模块组合产生的安全缺口。真正稀缺的是可传递的模块知识：这一层假设了什么，把什么责任交给调用方，又依赖哪条论文结论。ZK/SEC 的卖点因此更像审计 harness 与上下文组织，而不是某个模型名称。
但单个成功案例不能证明 AI 审计已经稳定优于人工或普通工具。9.5 小时以上、候选质量和合作方升级状态都来自审计方；没有完整误报率、召回率、成本和独立复现。文章还承认其余发现没有全部深挖。早报判断是，这是一条有修复提交和公告支撑的强案例，却仍只是案例证据，不是总体能力评测。
对项目方而言，最可复制的做法不是追求“AI 独立出报告”，而是把候选、证伪、人工确认和披露设计成连续门禁。尤其在密码工程中，一个看似通过的 PoC 可能偷偷改了验证前提；没有人工回到数学约束、调用路径和真实运行环境，自动化越快，错误确信也可能扩散得越快。
接下来怎么核验
第一，看 ZK/SEC 是否为后续已修复案例公开统一统计口径。至少应包括扫描配置、候选总数、进入人工复核的数量、最终有效发现、模型成本和人工工时。只有这些数字出现，9.5 小时以上才可能被转成可比较的工程指标。
第二，看 OpenVM 2.0 定向审计是否披露明确范围和状态。ZK/SEC 在复盘中表达了继续覆盖 zkVM 与密码项目的意向，但意向不等于已经完成的审计结果。后续报道需要逐项核对报告日期、受影响版本、修复提交和发布版本，不能把多个项目合成一个模糊的“AI 又发现漏洞”。
第三，看第三方能否在同一 OpenVM 历史版本上复现发现流程。复现不只要得到相似报告，还要证明 PoC 没有修改安全前提，并记录普通 Agent 与上下文工程方案之间的误报差异。若只能复现最终漏洞、不能复现发现过程，仍不足以评价 zkao 的增量。
第四，OpenVM 用户应把行动落到依赖清单：确认 openvm-pairing 的实际版本，检查是否调用受影响配对路径，并验证构建产物已更新到 1.6.0 或更高版本。七月复盘不会改变五月补丁状态；它改变的是外界对发现过程的可见度。