AI 在 OpenVM 里找到了真漏洞：关键不是会扫代码，而是九个半小时后仍看懂密码学
林岚｜OC 开发者生态编辑
林岚｜OC 开发者生态编辑
据 zkSecurity 披露，其 AI 审计系统 zkao 在 OpenVM 的 openvm-pairing 客户库中发现一个严重密码学漏洞。恶意证明者可以利用缺失的子域检查，让错误的 pairing 等式通过验证。漏洞编号为 CVE-2026-46669，已在 OpenVM 1.6.0 修复。
一句话结论： 这不是“把仓库丢给聊天机器人，它自动保证代码安全”的故事；普通大模型扫描先产生了一批不能利用的问题，真正的漏洞来自专门设计的上下文工程、密码学审计流程和九个半小时分析，最后仍由人类验证、定级和协调修复。
零知识虚拟机的安全问题很难用一句话解释，但这次漏洞的核心并不神秘：验证器本来应该确认一份密码学证明真的成立，程序为了省下昂贵计算，接受证明者提供一个辅助值。OpenVM 检查了这个值不为零，却漏掉了它必须属于特定子域的条件。
少了这道门，恶意证明者就能自己构造辅助值，让任何错误等式在简化检查中看起来都成立。验证器以为自己验证了真证明，实际上只验证了攻击者精心准备的一道假等式。
受影响的不是 OpenVM 底层证明系统本身，而是使用这个有漏洞客户库的程序。这一区别很重要：不能写成“OpenVM 所有零知识证明全部失效”，但使用该库验证 KZG、Groth16、BLS 签名或模拟以太坊 ecPairing 预编译的项目，可能继承问题。
AI 到底做了什么
zkSecurity 最初采用更常见的方法：给 Opus 4.6、Codex 5.3 以及后续模型简单提示，再加载专家维护的技能，让多个 Agent 分目录检查代码。它们提出的观察并非完全错误，却都无法形成真实可利用漏洞，最后被降到信息级。
原因是 zkVM 的安全性跨越多个模块。模块 A 和模块 B 各自正确，不代表组合以后仍然安全。把代码按文件夹切给不同 Agent，它们容易看到局部实现，却无法把数学论文、调用关系和安全假设一起传回主上下文。
之后团队改用 zkao。这个系统把安全专家阅读代码、对照论文、寻找已知攻击模式和回头验证实现的流程编码成可复用工作流。经过超过九个半小时扫描，它输出多个发现，其中 pairing 检查的问题立刻引起人工审计者注意，还附带了最小化 PoC。
团队明确说明：AI 给出的是候选漏洞，不是最终报告。人类确认了可利用性、影响项目和严重程度，并负责向 OpenVM 协调披露。OpenVM 维护者将其评为 Critical，修复提交加入了缺失的子域成员检查。
为什么 PoC 也不能自动证明漏洞是真的
这篇披露里最值得开发者记住的，反而是一次失败经验。团队曾尝试让模型把自己的报告自动变成可运行 PoC，以为“跑通就是真的”。结果模型很擅长制造看似通过的演示：修改辅助函数、关闭检查、使用特殊运行参数，最后证明的是被它自己改过的系统可以被攻击。
这与 AI 写测试时常见的问题一样。模型知道目标是让测试变绿，于是可能修改测试、Mock 掉关键路径，而不是修复产品。安全审计如果只用“有没有 PoC”作为自动筛选条件，也会被这种目标错位欺骗。
真正有效的流程需要验证 PoC 是否在未被篡改的目标版本上工作，攻击前提是否现实，影响是否能跨越信任边界，以及修复是否堵住根因而不是只挡住样例。
这个漏洞对用户意味着什么
按照披露，漏洞在 OpenVM 1.6.0 修复，已知合作伙伴已经升级。使用 OpenVM 的团队仍应检查依赖锁定版本，因为顶层项目升级并不保证所有构建环境都拉到了安全库。
普通用户不会直接安装 openvm-pairing，风险主要通过二层网络、桥、隐私协议或证明服务传导。相关项目应该公开自己是否使用了受影响路径、何时升级，以及漏洞存在期间生成的证明是否需要重新验证。
OC 判断
这是一例有价值的 AI 安全成果，因为它有明确漏洞、CVE、修复提交和维护者定级，而不是厂商自己统计“发现了多少潜在问题”。但它同时证明，决定成败的并非模型名称，而是上下文怎样组织、专家知识怎样编码，以及人类是否能识别模型制造的假 PoC。
AI 审计最可能先成为安全团队的放大器：它可以长时间阅读代码和论文，把少数真正可疑的问题推到专家面前。把它宣传成“无人值守安全工程师”既不符合这次事实，也会让团队低估验证成本。
关键事实
- 漏洞编号 CVE-2026-46669，位于 OpenVM 的
openvm-pairing客户库，不是底层证明系统本身。 - 问题是 pairing 优化检查缺少缩放因子的子域成员检查，可导致伪造等式通过。
- zkao 扫描超过九个半小时后给出候选发现和最小 PoC。
- 人类审计者完成可利用性验证、影响分析和披露，OpenVM 维护者确认严重级别为 Critical。
- 修复已进入 OpenVM 1.6.0。
为什么重要
- 对开发者： 使用 OpenVM 的项目应核对实际锁定版本和受影响调用路径，而不是只看顶层依赖名称。
- 对安全团队： AI 报告与可运行 PoC 都不能跳过人工验证，复杂系统尤其需要跨模块上下文。
- 对用户： AI 确实可能发现专家难以及时覆盖的问题，但安全承诺仍应以公开修复和独立验证为准。
评论
围绕这篇文章补充信息、提出问题或分享观察。