zkSecurity 用 AI 审计 Cloudflare CIRCL：7 个漏洞已修复

过去 24 小时里，zkSecurity 把一条更值得长期观察的 AI 安全案例摆到台前。它不是只展示模型“会不会找 bug”，而是把 AI 候选发现、人类验证、最小化 PoC、HackerOne 披露和上游修复放在同一条链路里。

对象也不是玩具项目。Cloudflare CIRCL 是一个真实维护中的 Go 密码库，覆盖后量子密码、阈值签名、BLS、HPKE、属性基加密等模块。zkSecurity 把 AI audit pipeline 指向这个仓库，最后确认并披露 7 个真实漏洞，相关修复已经进入上游。

这件事对 AI 早报的价值在于，它给“AI 安全审计”提供了一个可核验样本。过去很多安全演示停留在截图、prompt 或 benchmark 分数；这一次可以看到博客、漏洞表、修复 commit、严重度差异和人工验证边界。

发生了什么

zkSecurity 在 2026-07-07 发布文章，复盘其 AI 审计 pipeline 在 Cloudflare CIRCL 中找到的问题。文章标题是 “AI meets Cryptography 1”，定位为系列开篇，后续还会继续写其它开源密码项目。

文章给出的核心事实是：AI pipeline 产生了大量候选发现，其中 7 个被人类研究员确认值得报告。它们覆盖 threshold RSA、BLS aggregate、HPKE PSK、CP-ABE 等模块。zkSecurity 称这些问题都已在上游修复，多数也通过 Cloudflare 的 HackerOne 计划确认并获得 bounty。

这里最需要读者注意的是“候选发现”这四个字。zkSecurity 没有把 AI 输出直接当作最终报告，而是明确说人类团队仍然完成了验证、exploitability 检查、PoC 最小化和披露处理。这条边界决定了本案例的参考价值。

7 个漏洞与严重度对照

模块	问题类型	AI 自评严重度	Cloudflare 确认严重度	修复状态
threshold RSA	float64 精度损失影响 polynomial evaluation	Critical	High	已修复
threshold RSA	share 验证路径存在边界问题	High	Low	已修复
BLS aggregate	aggregate signature 验证缺陷	High	Medium	已修复
HPKE PSK	PSK 使用路径存在不一致风险	Medium	Low	已修复
CP-ABE	AND-share 访问控制绕过	Critical	Critical	已修复
CP-ABE	attribute 组合处理缺陷	High	Medium	已修复
辅助工具链	测试或边界处理问题	Medium	Informational	已修复

这张表的重点不是数字本身，而是严重度差异。AI 对其中一些问题的严重度判断偏高，也有问题被 Cloudflare 下调到 Low 或 Informational。说明模型可以发现候选线索，但风险分级仍然需要部署场景、可达性、默认配置和补偿控制一起判断。

threshold RSA 的修复 commit 显示，相关代码改为使用 Horner 方法做 polynomial evaluation，避免原实现路径中的精度问题。BLS aggregate 和 CP-ABE 的修复也已经能在 CIRCL 仓库里看到对应 commit。这些 commit 是本案例区别于一般演示的关键锚点。

为什么值得放进 AI 早报

AI 早报不是安全漏洞通报站。把这条放进今日主线，是因为它触到了 AI 工具进入专业工作流时最难的一环：从“模型能提出问题”到“组织能信任并处理问题”。

安全审计过去是高度人力密集的工作。研究员需要读代码、形成威胁模型、构造 PoC、判断可达性，再写出维护者能接受的报告。AI 介入之后，最容易被放大的环节是候选发现；最难自动化的环节是验证和沟通。

zkSecurity 这次复盘说明，AI pipeline 可以把候选空间大幅前移，但不能取消人类判断。候选发现便宜，可信报告昂贵。真正有价值的工具，应该减少研究员在定位、复现、去噪和最小化 PoC 上的时间，而不是把更多未验证告警扔给维护者。

这个判断也解释了为什么 CIRCL 案例比普通 benchmark 更有意义。benchmark 能说明模型在固定题库上的能力，但很难说明它面对真实仓库、历史包袱、测试缺口和维护者反馈时的表现。真实 commit 和披露流程能够压住一部分宣传噪音。

对安全团队的影响

对安全团队来说，这个案例的第一层影响是 triage 成本会变成核心指标。未来评估 AI 安全工具时，不能只看“发现了多少问题”，而要看每个有效问题需要多少人工验证时间、误报如何聚类、是否自动生成可运行 PoC、能否给出维护者可读的修复建议。

第二层影响是披露流程会承压。AI 工具让候选漏洞的生成成本下降，HackerOne、开源维护者和企业 PSIRT 都可能收到更多半成品报告。平台需要更明确地区分候选线索、可复现漏洞和可利用攻击链，否则维护者会被低质量报告淹没。

第三层影响是安全研究的技能结构会变化。研究员不再只是在代码里寻找第一条线索，还要设计 agent 技能、评估模型失败模式、建立严重度校准规则，并判断哪些候选值得继续投入人工验证。

对开源维护者的影响

对开源维护者来说，AI 审计会带来两种相反压力。一边是更早暴露深层问题的机会，尤其是长期缺少安全审计预算的基础库。另一边是报告数量上升后的维护负担，特别是没有复现、没有受影响版本、没有攻击前提说明的候选问题。

因此维护者需要更明确的报告格式。一个可处理的 AI 辅助报告至少应该包含受影响代码路径、触发条件、最小复现、可能影响、建议修复和不确定性。只有一句“模型认为这里有漏洞”，对维护者没有实际帮助。

企业买方也会改变评估口径。采购 AI 安全工具时，真正要问的不是模型用哪个版本，而是它能否接入现有代码托管、CI、issue 系统和披露流程。能把候选发现转成可验证任务的工具，才会进入预算讨论。

这也给安全平台提出了治理要求。平台可以要求 AI 生成报告显式标注“候选发现”或“人工确认”，并对重复提交、无法复现、严重度夸大建立降权机制。否则，AI 降低发现成本的同时，也会把噪音成本转嫁给维护者。

对模型和 agent 厂商的影响

对模型厂商来说，CIRCL 案例把安全能力叙事从“模型懂安全”拉到“模型能否进入闭环工作流”。如果厂商只给出漏洞发现 demo，而没有复现、分级、修复建议和披露配套，那么它更像研究展示，不像可采购产品。

对 agent 厂商来说，机会在于把上下文管理和验证链路做深。密码库审计不是简单 grep，也不是让模型读完整仓库后直接判断。高质量系统需要把威胁模型、协议背景、测试生成、差分执行和 commit 定位接起来。

这也是 zkSecurity 文中提到 zkao 的原因。它希望把专家维护的 skills 编码进 agent，让模型不只是“读代码”，而是按安全研究员的工作习惯持续检查。这个方向能否扩展，还要看后续案例的误报率、覆盖面和可复现性。

仍需保留的边界

第一，CIRCL 是密码库，漏洞类型和验证方式有一定特殊性。AI 在密码实现里可能更容易围绕边界条件、数学假设和 API 误用形成候选；这不等同于它在大型业务系统、前端仓库或分布式服务里有同样表现。

第二，公开材料还不能完整还原 pipeline。读者能看到结果、表格、部分 commit 和披露边界，但看不到候选发现总量、误报率、模型组合、prompt 设计、技能库内容和人工验证耗时。没有这些指标，就不能把 7 个漏洞直接换算成生产效率提升。

第三，严重度校准仍然是短板。AI 自评与 Cloudflare 确认严重度之间有差异，这不一定是坏事；保守分级可以避免漏报。但如果工具长期把大量 Low 或 Informational 问题标成 High，维护者会很快失去耐心。

接下来看什么

• zkSecurity 后续系列是否披露更多开源密码库，尤其是不同语言、不同协议栈和更大规模仓库的结果
• Cloudflare 是否公开 7 个漏洞的完整 HackerOne 报告，包含赏金等级、影响范围和修复时间线
• zkao 或同类工具是否公布候选发现总量、误报率、人工验证耗时、PoC 自动生成比例等效率指标
• 开源维护者是否开始要求 AI 生成报告附带最小复现、受影响版本、可达性分析和修复建议
• 安全团队是否把 AI 审计接入 CI 或 nightly scan，并建立人类研究员审核队列

附：读者判断这类 AI 审计案例时可以看哪些信号

• 是否有具体仓库、具体 commit 和可追溯修复
• 是否区分 AI 候选发现与人类确认报告
• 是否公开候选发现总量、误报率和验证耗时
• 是否给出严重度对照，而不是只展示最高级别案例
• 是否说明披露流程、维护者反馈和补偿控制
• 是否能在不同类型仓库中复现，而不是只适配单一 benchmark