AI 协助漏洞发现的工程基线:从 curl 六个 CVE 看专用系统的实战能力 2026 年 8 月下旬,一个专门做 AI 安全研究的小团队在 curl 这个被全球 200 多亿台设备部署的开源项目上发现 6 个 CVE,让 AI 在攻防两端的能力差距从理论争议变成了可量化的实证。这件事的可信度来自于一个极其干净的对比基线:在 AISLE 跑自家系统之前,curl 创始人在 Mastodon 上公
AI 协助漏洞发现的工程基线:从 curl 六个 CVE 看专用系统的实战能力
2026 年 8 月下旬,一个专门做 AI 安全研究的小团队在 curl 这个被全球 200 多亿台设备部署的开源项目上发现 6 个 CVE,让 AI 在攻防两端的能力差距从理论争议变成了可量化的实证。这件事的可信度来自于一个极其干净的对比基线:在 AISLE 跑自家系统之前,curl 创始人在 Mastodon 上公开发文,说 Anthropic 推出的 Mythos 和 OpenAI 推出的 Codex Security 都报告零个漏洞。这种"公开发布零结果,数天后被超越"的对比,把"通用 AI 系统能不能挖到 0day"这个一直有争议的问题,变成了一个工程基线问题。
这件事的工程意义在于,它把"AI 找漏洞"这件事从"模型基准测试"变成了"实际系统能力对比"。这种对比的核心不是哪个模型更聪明,而是哪个系统在真实的开源代码审计场景下,能真的挖出可被维护者接受为 CVE 的问题。curl 这个被全球 200 多亿台设备部署、经过数十年人类审计、又被 Mythos 与 Codex Security 反复扫描过的代码,是一个接近零噪声的基准 —— 任何系统在这里发现的洞,都是真正可被独立验证的零日漏洞。
从时间线看"专用 AI 系统"的工程优势
这 6 个 CVE 的发现过程给出了一个非常清晰的时间线。8 月 24 日,curl 创始人在 Mastodon 发文,说 Mythos 找不到任何新 CVE,Codex Security 显示空列表。同一天,AISLE 跑了自己的自主系统,生成了 29 份报告。第二天,创始人在 Mastodon 公开对比:"Mythos: 0,AISLE: 29"。三天时间内,AISLE 报告的 6 份被 curl 安全团队确认为"严重到值得公开 CVE 级别"。到 8 月 28 日,curl 待发布的 CVE 数从 3 升至 10,增加的 7 个里 6 个来自 AISLE。
这种时间线揭示了 AI 找漏洞这件事的关键不在"模型能想到什么",而在"系统能不能把想法变成可被维护者接受的报告"。一个 AI 模型想到了一个可能的安全问题,但如果不能把它定位到具体的代码行、写出可复现的概念证明、说明攻击场景的影响范围,这个想法对维护者来说和不存在没有区别。专用 AI 安全系统的价值在于它把这些"从想法到报告"的环节都做了工程化,让模型的想法可以直接进入开源社区的漏洞处理流程。
这件事对其他开源项目同样有效。Linux stable 内核的长期维护者在看到 curl 的结果后说:"I'm seeing the same for Linux as well. No idea what Aisle is doing differently, but wow..."。这意味着 AI 找漏洞这件事不是 curl 的特例,而是一种适用于所有被广泛审计的开源项目的通用能力 —— 通用模型看到的是已知漏洞和已知攻击模式,专用系统看到的是人类审查员也会漏掉的角落。
从 CVE 细节看 AI 系统找洞的实际能力
被认领的 6 个 CVE 全部是 Low severity,这本身就是一个值得展开的工程信号。curl 是一个工程成熟度极高的项目,大部分明显漏洞早被挖光,剩下的都是隐藏在窄配置或微妙交互里的 Low severity 问题。这说明 AI 系统在 curl 这种成熟代码上不是发现"明显的安全漏洞",而是发现"在特定 TLS 后端、特定 cookie 语义、特定属性绕过场景下才出现的细微问题"。这种发现能力和人类审计员的能力是同级别的 —— 不是"机器代替人类",而是"机器在人类已经看过的代码里找到了人类可能漏掉的东西"。
具体的 6 个 CVE 也揭示了 AI 系统关注的代码类型谱:OpenSSL provider use-after-free、OpenSSL pinning bypass、native CA store connection reuse、secure attribute bypass with tab、wolfSSL CA-cache hit overrides callback、domain-scoped public-suffix cookie。这六类问题里有四类是 TLS / CA 相关,一类是 HTTP cookie 语义,一类是属性处理。AI 系统对加密栈相关代码的关注度,和人类安全审计员的关注度基本一致 —— 加密栈是公认的错误高发区,因为它的正确性依赖很多微妙的状态管理。
这些漏洞都被 curl 安全团队独立验证并在 curl 8.22.0 中修复,公开署名 该 AISLE 报告人 来自 AISLE 作为报告者。这种"被独立验证、被公开署名、被修复在产品里"的完整循环,才是 AI 找漏洞这件事真正有工程价值的部分 —— 不是"AI 想到了某个可能",而是"AI 的想法被独立验证、被修复、被部署到生产环境"。
从 curl 案例看 AI 协助漏洞发现的工程新基线
把这次事件和类似的 AI 漏洞发现案例放在一起,可以给企业 AI 协助漏洞发现这件事划出五条工程新基线。第一条基线是 AI 找漏洞的价值要看应用,不是看想法。一个想法无论多有洞察,如果不能定位到具体代码行、写出可复现的攻击路径、说明影响范围,对安全工程来说就和不存在没有区别。专用 AI 安全系统的工程价值在于它把"从想法到报告"的所有环节都做了工程化。
第二条基线是 AI 找漏洞的对比必须在公开基线上进行。这次 AISLE 的对比之所以有说服力,不是因为 AISLE 报告多,而是因为 Mythos 和 Codex Security 的零结果是 curl 创始人公开写的,时间戳清晰可比。如果对比基线是私密的、不可验证的,任何一方都可以声称自己更强。AI 找漏洞这件事需要公开基线、可重复实验、可独立验证的结果,不能靠单一方的市场宣传。
第三条基线是 AI 找漏洞的能力在成熟代码上展现。一个系统能在 toy 项目上找到漏洞并不稀奇,但能在 curl、Linux kernel、Wireshark、FFmpeg 这些被广泛审计的项目上找到 CVE,说明这个系统的能力已经达到了和人类审计员相当的水平。企业评估 AI 安全工具时,应该看它在被广泛审计的项目上的表现,而不是它在 CTF 题目上的成绩。
第四条基线是 AI 找漏洞不限于 0day 突破。AISLE 之前已经在 Wireshark 发现 16 个 CVE,在 FFmpeg 发现 6 个高危或严重 CVE,在 MySQL/MariaDB/PostgreSQL 发现 8 个 CVE,在 Cursor/VSCode/Antigravity 发现一键 RCE。这说明 AI 找漏洞是跨编程语言、跨应用类型、跨抽象层次的通用能力,不局限于某一类漏洞。企业在选型 AI 安全工具时,要看它在多种代码类型上的覆盖度,而不是只关注某一类漏洞的发现能力。
第五条基线是 AI 找漏洞必须可被独立验证。这次 curl 的 6 个 CVE 全部被 curl 安全团队独立验证,确认了 AISLE 报告的真实性和严重性。AI 安全工具不能停留在"我发现了某些问题",必须给到维护者能验证、能复现、能接受的报告。这种"独立验证"的标准是 AI 安全工具可信度的最基础要求。
从工程新基线到企业安全工具采购
把这次 AISLE 的发现案例放回企业 IT 的安全工具采购语境,可以看出 2026 年下半年的 AI 安全市场正在出现一个重要的工程拐点。过去几年 AI 在网络安全领域的主要价值是辅助分析 —— 给安全分析师提供建议、加速信息整合、生成事件报告。AISLE 在 curl 上的结果说明 AI 已经从"辅助分析"进入"主动发现"阶段 —— 不再是给分析师建议,而是能直接产出可被 CVE 编号确认的发现。
这种从"辅助"到"主动"的转变,在企业安全工具采购上的影响是直接的。第一,企业需要重新评估 AI 安全工具在采购清单上的位置 —— 不再是"额外的锦上添花",而是"能和人类审计员对等的能力"。第二,企业在选择 AI 安全工具时,要关注工具的"独立验证能力" —— 工具发现的问题能不能被人类审计员独立验证,而不是只看工具自己声称的"发现了多少问题"。第三,企业要把 AI 安全工具纳入"持续安全"的流程 —— 不再是"年度渗透测试 + 偶尔审计",而是"持续运行 AI 安全工具 + 人类复审关键发现"。
把这条工程基线落到企业 IT 的预算和流程里,就是把 AI 安全工具的预算从"年度支出"变成"持续运营支出",把 AI 安全工具的 SLA 从"年度报告"变成"持续发现 + 实时告警"。这是 2026 年下半年企业安全治理正在发生的具体转变,也是这次 curl 6 个 CVE 案例给整个行业最直接的工程启示。