安全公司zkSecurity披露，其AI审计工具zkao在zkVM项目OpenVM的配对验证库openvm-pairing中发现一处严重漏洞，编号CVE-2026-46669：恶意证明者能伪造任意配对等式，让本该失败的验证通过。漏洞覆盖BN254和BLS12-381两条曲线路径，已在修复提交a720e2c中堵上，随OpenVM 1.6.0发布。
这条新闻真正的价值不在"AI又抓到一个大漏洞"，而在于它示范了专用AI审计工具和通用大模型之间的差距到底体现在哪——不是知识量，是能不能读懂跨模块的隐含假设。漏洞本身也有边界：出问题的是调用方使用的guest库，不是OpenVM底层证明系统的健全性。
三行检查漏掉了，等式就能被伪造
配对验证的标准做法是算$e(P,Q)$的乘积，再判断结果是否等于1。直接做这一步的"final exponentiation"运算量很大，OpenVM采用了论文里的优化：让证明者自己算一个中间值和一个"缩放因子"作为提示，电路只做一次便宜的等式检查。
这个优化能成立，前提是缩放因子必须落在$\mathbb{F}_{p^6}$子域里——也就是它的三个奇数位系数必须为零。OpenVM的代码只检查了提示值不为零，漏掉了子域成员检查。结果是，恶意证明者只要令$c=1$、缩放因子等于$f^{-1}$，等式照样通过，一个原本错误的配对乘积也能被判定成立。
- 结论.受伤的是站在库上面的验证逻辑，不是zkVM本身的证明可靠性。
通用大模型扫了两轮，专用工具用了9.5小时
四个月前，zkSecurity先用普通流程扫过一遍OpenVM：一个简单提示词跑一遍Opus 4.6和Codex 5.3，再叠加自家审计经验做的技能提示。模型给出的候选发现不少被自己标成Critical或High，但逐一核实后全是"信息性"的，没有一个真能利用。Opus 4.7和Codex 5.4发布后重跑一遍，结果一样。
原因不难理解：一个zkVM不像普通密码学库那样能按模块拆给子任务分头审计。模块A和模块B各自可证明安全，组合起来未必安全——子代理需要产出的不是"这段代码有没有bug"，而是"这个模块依赖调用者遵守了什么隐含约定"，这种知识很难用有限上下文完整传递。
zkao针对这类问题做了专门的上下文工程，用一条叫cryptopsy的流程，让代码实现和背后的学术文献反复对照。扫描跑了约9.5小时，产出大量候选发现，团队没有逐条细看，但这处配对检查漏洞一眼就冒出来了。
AI给出候选，人工才拍板可利用性
zkSecurity团队自己也提醒：不能靠让模型自己写PoC来判断漏洞是否真实——模型写出的PoC经常靠隐藏假设、打了补丁的辅助函数或关掉的检查"跑通"，看起来像真的。最终确认可利用性、评估受影响项目、走披露流程，还是人工完成的。
该升级的项目，风险不该被泛化
会受影响的是那些在OpenVM guest程序里验证Groth16证明、KZG开放证明、BLS签名，或者用这个库模拟以太坊ecPairing预编译（地址0x08）的项目——典型场景是构建在OpenVM上的L2 rollup、跨链桥和隐私协议。zkSecurity表示，据其了解，所有基于OpenVM构建的合作方都已升级到1.6.0。
- 风险.目前没有证据显示这个漏洞被实际利用过，只有可利用性经PoC验证；"合作方已升级"是zkSecurity一方的说法，具体项目该不该信，值得各自核实版本号。
对使用OpenVM配对库的团队来说，动作很简单：检查依赖版本是否已到1.6.0。对其他在评估AI审计工具的安全团队来说，这个案例的参考价值是——判断一款工具好不好用，别只看它标了多少"Critical"，看它能不能在组合逻辑里读出被隐藏的假设。