这是该系列的第二篇文章。如果您还没有阅读关于 Cloudflare 的 CIRCL 的第一篇文章，建议您先阅读，因为它提供了更多我们进行这些实验的背景信息，以及我们的流程是如何设置的。在这篇文章中，我们将 zkao（我们的人工智能审计员）指向 OpenVM 的 zkVM，它在其客户库 openvm-pairing 中发现了一个关键的健壮性漏洞，允许恶意的证明者伪造任何配对等式。请注意，这不是 zkVM 证明系统本身的健壮性漏洞；它仅影响使用了易受攻击库的代码。本文中的漏洞被分配为 CVE-2026-46669，并已在 OpenVM 1.6.0 中修复。据我们所知，所有基于 OpenVM 构建的合作伙伴都已升级到该版本。请注意澄清，和第一篇文章相同：人工智能生成了一个候选发现，而不是最终报告。我们团队中的人类随后验证了这个问题，确认了可利用性，理解了完整的影响和受影响的项目，并处理了披露。在这种情况下，由于 zkao 生成的详细报告和最小的 PoC，快速的人工排查足以决定与 OpenVM 团队分享这一发现。发生的经过 四个月前，我们在我们的人工智能实验中扫描了 OpenVM，首次扫描的方法是使用简单提示的 LLM，然后使用我们专家维护的技能组合的 LLM。我们使用的是 Opus 4.6 和 Codex 5.3。一旦 Opus 4.7 和 Codex 5.4 发布，我们又重新扫描了一次。候选发现都是有效的观察，模型自信地将其中几个标记为关键或高危，但它们实际上都无法被利用。我们的假设是 zkVM 对于一个简单的 LLM 设置来说过于复杂，无法处理 30 万个令牌，甚至 100 万个令牌的上下文。模块之间的依赖关系远比典型库中的要密集。一个密码学库通常可以并行审计，只需将映射到单个密码原语的文件夹交给每个子代理。每个子代理读取少量行，仅应用相关技能，将其发现写入 Markdown 文件，而主代理将这些文件拼接在一起。所有这些都可以通过流行的编程工具如 Claude Code 和 Codex 开箱即用，几乎不需要人工干预。这种方法无法转移到更复杂的代码库，如 OpenVM。在那里，除了低悬果实，子代理的有用输出并不是漏洞列表。您可以有一个可证明安全的模块 A 和一个可证明安全的模块 B，但它们的组合仍然不安全。因此，在这种“孤立”的模式下寻找漏洞无法发现有意义的漏洞。相反，子代理的输出应该是关于模块的知识：它假设什么，将什么委托给调用者，以及它静默依赖的什么不变条件。然而，良好地表示这种类型的输出是困难的。太短了会跳过漏洞实际所在的实现细节。太长了会在主代理将其与其他内容结合之前溢出上下文。根据我们所见，至少在撰写本文时，上述提到的代理编码工具并没有有效地解决这个问题。在这一假设的指导下，我们决定在 OpenVM 上运行 zkao，尽管我们最初设定的规则是只有在 LLMs 已经找到了真正的漏洞之后才运行 zkao。我们已经花了很多时间为 zkao 进行上下文工程，并将我们专家的工作方法编码为可重用的发现漏洞流程，因此它似乎是这个情况的合适工具。在扫描超过九个半小时后，它返回了许多发现。与之前的实验类似，我们没有时间逐一深入检查每个发现。在快速检查后，有一个发现立即引起了注意：在一个客户库中的配对检查中存在一个关键的健壮性漏洞。我们的假设得到了验证，多个月的努力得到了回报！尽管只有一个漏洞可以分享，为了与第一篇文章保持一致，下面是漏洞的概况。漏洞的严重性和修复概况 # 漏洞 人工智能严重性 OpenVM 严重性 修复提交 发现者 1 openvm-pairing 配对检查缺少对缩放因子的适当子字段检查 关键 关键 a720e2c zkao 这次，人工智能严重性与维护者严重性一致。漏洞 1：openvm-pairing 配对检查缺少对缩放因子的适当子字段检查 背景 配对是 Groth16、PLONK 与 KZG 和 BLS 签名的引擎。在所有这些协议中，验证者通常不是在询问一个配对值。它是在询问配对的乘积是否为一：$$ \\prod_i e(P_i, Q_i) = 1.$$ 从这个是或否的答案中，验证者得出 SNARK 证明是有效的，KZG 开放是正确的，或者签名是有效的。因此，如果证明者能够伪造一个虚假的配对乘积看起来为一，则建立在其之上的一切将不再健壮。配对是一个双线性映射 $$ e : G_1 imes G_2 o G_T，$$ 其中 $G_1$、$G_2$、$G_T$ 是阿贝尔群。在我们的案例中，$G_1$ 和 $G_2$ 是