curl 创始人 Daniel Stenberg 在8月24日的一条动态里写道，下一个版本的待处理 CVE 只有三个；在让两家前沿 AI 网络安全系统扫描过 curl 之后，他补充道：Anthropic 的 Mythos 表示再也找不到更多问题，OpenAI 的 Codex Security 则给出了一份空列表。curl 部署在全球超过 200 亿个实例上，从智能冰箱到航天器都在运行这份代码，这个零发现因此被不少人当成了权威结论。
转折发生在随后几天。安全公司 AISLE 把自家自主 AI 系统对准 curl，第二天 Stenberg 就贴出了公开对比：Mythos 零报告，AISLE 29 份报告。curl 安全团队在数日内审阅了其中 6 份，认为严重到足以授予公开 CVE 编号，并随 curl 8.22.0 一并发布。六个漏洞分别是：CVE-2026-80229 OpenSSL provider 使用后释放、CVE-2026-80230 OpenSSL 证书固定绕过、CVE-2026-80231 原生 CA 存储连接复用、CVE-2026-80255 secure 属性绕过、CVE-2026-82208 wolfSSL CA 缓存命中覆盖回调，以及 CVE-2026-82209 域级公共后缀 cookie 问题。
六份报告背后的时间线
按 AISLE 公布的细节，六个 CVE 的提交时间是8月24日三份、8月26日两份、8月27日一份，发现者统一署名为 AISLE 的 Stanislav Fort。六个漏洞全部被评为低危，AISLE 对此的解释并不意外：curl 的工程质量异常成熟，剩下的漏洞往往藏在狭窄的配置组合与细微的交互路径里，这类问题恰好是自主 AI 长时间地毯式扫描的强项，而对按流程走查的传统审计来说性价比极低。
AISLE 特意强调这次实验与常见评测的区别：它不是夺旗赛，也不是答案可能早已混进训练数据的标准基准，而是对生产环境真实代码的现役分析，漏洞是否成立的裁判权完全在 curl 维护者手里。这个设计规避了 AI 安全评测里最常被质疑的数据污染问题，也让零发现与二十九份报告之间的落差更有说服力。
前沿模型评测的公信力问题
这件事的余波大概率不止于 curl。Mythos 与 Codex Security 的零结果都是公开、带时间戳的表态，如今被同一份代码库上的 29 份报告直接对照，厂商宣传与实战表现之间的距离被摆上了台面。对采购方来说，教训相当具体：评估 AI 安全产品时，静态演示与营销话术的权重应当下调，在自有代码库上的实测结果才是唯一可信的依据。
六个CVE的技术分布
从技术分布看，六个 CVE 里有四个集中在 TLS 证书校验相关路径：两个出在 OpenSSL provider 后端，一个出在 wolfSSL 后端，还有一个涉及原生 CA 存储的连接复用。同一类问题在不同 TLS 后端反复出现，说明多后端策略带来的组合爆炸正是 curl 维护成本的大头——curl 需要同时伺候十几种 TLS 实现，而每一种实现的细微行为差异都可能变成安全边界上的缺口。
安全社区对这组数字的解读很快分成两派。一派认为 AISLE 的系统在算力和扫描时长上占优，长时间无人值守的枚举本来就能在人类审计停下的地方继续挖；另一派则指出，报告数量从来不等于漏洞数量，29 份报告只有 6 份获得 CVE 编号，召回与精度之间的平衡仍是自主扫描系统最难的部分。两派共同承认的是：单次运行的对比说明不了模型优劣，但零结果被公开推翻这件事本身，已经足以改写厂商评测的预期。
对 curl 项目而言，结果倒算皆大欢喜：六个低危漏洞在 8.22.0 中全部修复，代码库经受了又一次高强度审计。真正的悬念在于 Stenberg 会不会把自主 AI 扫描纳入常规流程——29 份报告中仍有 23 份待审，如果其中再产出几个 CVE，这场零与二十九的对照还会继续刷新人们对 AI 安全工具的认知。