curl 项目自 1998 年发布以来，已累计披露 188 个 CVE。作为部署规模超过两百亿实例的网络传输库，其安全性始终是社区重中之重。2026 年 5 月，Anthropic 通过 Alpha Omega 项目向 curl 提供了 Mythos 模型的源码扫描机会，本文聚焦此次扫描的完整工作流程：模糊候选生成、语义等价比对验证、补丁 diff 定位、置信度阈值设定，以及最终漏洞披露链路。
Mythos 扫描的背景与接入方式
Anthropic 在 2026 年 4 月发布公告，称其新模型 Mythos 在自动化漏洞发现方面 “危险地出色”，并宣布将通过 Linux Foundation 的 Alpha Omega 项目向部分开源项目提供受限访问。curl 项目维护者 Daniel Stenberg 代表 curl 接受了这一邀请。
值得注意的是，此次扫描并非由 curl 团队直接操作模型，而是由拥有 Mythos 访问权限的第三方人员代为执行，扫描对象为 curl git 仓库 master 分支的特定提交（commit 455bebc2c76223a1be26042f6d2393715c0df0cd），覆盖 src/ 与 lib/ 目录下约 17.8 万行 C 代码。
候选生成阶段：多路径语义探索
Mythos 的分析方法并非传统模糊测试的直接变种，而是一种基于 LLM 子代理的并行源码检查策略。根据 Daniel 披露的报告结构，Mythos 在此次扫描中采用了以下候选生成路径：
并行文件读取子代理。Mythos 启动多个子代理同时遍历 curl 代码库，每个子代理负责特定目录或模块（如 HTTP/1、TLS、URL 解析、认证机制等），在语义层面识别潜在异常。报告明确指出，Mythos 认识到 curl 是 “被 fuzz 程度最高的 C 代码库之一”，因此主动将搜索范围扩展到非常规路径，包括所有次要协议、所有文件解析器、所有 TLS 后端的验证路径、mprintf、x509asn1、DOH、各类认证机制、连接复用、会话缓存、平台特定代码以及 CI / 构建供应链。
协议规范交叉验证。Mythos 声称具备协议层面的语义知识，能够识别 curl 实现与 RFC 规范之间的矛盾之处。这一能力使其可以发现传统静态分析工具难以触及的逻辑漏洞 —— 代码在语法层面无懈可击，却在协议语义层面存在缺陷。
第三方库 API 滥用检测。Mythos 内置了对 curl 所依赖的第三方库（如 OpenSSL、GnuTLS、NSS 等）的 API 调用知识，能够识别不安全的调用模式或版本相关的行为差异。
注释与实现一致性检查。Mythos 可以识别代码注释所述行为与实际实现之间的偏差，这是传统工具难以完成的任务。例如，当开发者通过注释声明某个函数应满足特定不变式，但实现存在细微偏差时，Mythos 能够捕捉这一不一致。
语义验证与误报过滤机制
Mythos 报告最终输出 5 个 “已确认漏洞”。然而，这里的措辞值得玩味：模型自称 “确认”，但这一结论源于模型自身的推理，并未经过下游验证。curl 安全团队在耗费数小时人工审查后，将 5 个候选缩减为 1 个真正的 CVE，其余判定为误报。
三类误报模式。在此次扫描中，Mythos 报告的 3 个误报均指向 API 文档中已明确记录的行为。LLM 在缺乏完整上下文的情况下，可能将 “预期行为” 误判为 “缺陷”。这一现象揭示了语义验证环节的关键挑战：模型需要区分 “设计决策” 与 “实现错误”。
第四个候选降级为普通缺陷。另一个被标记为漏洞的候选，经审查后被判定为 “仅是一个 bug”，不属于安全影响范畴。
阈值设定的重要性。Mythos 报告同时包含约 20 个非安全类 bug，这些 bug 的描述与解释质量较高，假阳性率低。这一差异表明 Mythos 在安全漏洞检测上设置了较高的不确定性容忍度 —— 宁可多报也不遗漏，这一策略在攻击者视角下合理，但在防御者视角下需要额外的人工过滤成本。
补丁定位与 CVE 定级
最终确认的单一 CVE 被定级为 “低危”，计划随 curl 8.21.0 版本在 2026 年 6 月底同步发布。在正式披露前，curl 团队对此漏洞细节严格保密，仅透露其影响范围有限。
补丁 diff 定位过程。从候选漏洞到正式 CVE 的转化涉及对源码的精确定位。Mythos 报告通常包含候选区域的描述与（部分情况下）建议修复补丁，但 Daniel 明确指出，这些补丁通常 “并非 100% 完整修复”。因此，curl 安全团队需要自行分析漏洞触发条件、构造测试用例、编写完整补丁，并通过标准代码审查流程合并。
定级依据。CVE 定级需要综合考量漏洞可利用性、影响范围与攻击复杂度。低危定级意味着该漏洞的利用条件较为严苛，或影响范围有限。curl 作为广泛部署的库，选择低危漏洞随常规版本发布而非紧急修补，说明该漏洞不具备蠕虫传播或远程代码执行的风险。
与传统工具的效果对比
Daniel 在博客中指出，在 Mythos 之前，curl 团队已使用 AISLE、Zeropath、OpenAI Codex Security 等 AI 工具进行持续扫描，这些工具在 8 至 10 个月内共同推动了近 300 个 bugfix，其中部分已作为 CVE 披露。Mythos 报告的漏洞数量（5 个候选，最终 1 个 CVE）并未显著超出此前工具的发现效率。
这一对比揭示了一个重要现实：随着代码库安全状况改善，发现新漏洞的难度递增。Mythos 的价值并非在于一次性发现大量漏洞，而在于其持续扫描能力与对长尾路径的覆盖。
负责任披露与安全研究伦理
Daniel 特别强调了 “高质量混沌”—— 安全研究者正以前所未有的规模使用 AI 工具挖掘漏洞。这一趋势对负责任披露实践提出了新要求：
预披露协调。CVE 通常遵循协调披露流程，给予供应商修复窗口期。AI 驱动的自动化发现可能缩短发现到披露的时间线，但修复与部署仍需周期。
假阳性处理成本。大量 AI 生成的安全报告可能淹没安全团队的响应能力。如何高效过滤误报、识别真正可利用的漏洞，成为防御侧的核心挑战。
披露粒度控制。在修复版本发布前，漏洞细节应严格保密。Mythos 报告的 5 个候选在人工审查前即被冠以 “已确认漏洞” 之名，这一措辞若被不当引用，可能导致不必要的安全焦虑。
工程化参数建议
基于此次 Mythos 扫描的经验，以下参数可作为 AI 驱动安全扫描的工程化参考：
候选报告置信度阈值。建议对 AI 报告设置分层置信度标记（如高 / 中 / 低），高于阈值的报告直接进入人工审查，低于阈值的报告批量归档待后续评估。Mythos 报告包含约 20 个非安全类 bug，假阳性率低，说明其底层置信度模型在非安全类问题上的校准优于安全类问题。
人工复核时间预算。5 个候选漏洞耗费数小时人工审查。按此比例，若 AI 工具报告 100 个候选，安全团队需要约 100 小时的复核时间。建议在扫描启动前明确资源约束，并优先处理高危场景（如网络边界组件、身份验证逻辑、特权代码路径）。
持续扫描频率。单次扫描的发现有限，建议将 AI 扫描集成到 CI/CD 流水线中，每次代码变更触发增量扫描，以捕捉新引入的漏洞。
与模糊测试协同。Mythos 擅长语义层面的逻辑漏洞发现，而传统模糊测试（如 AFL、libFuzzer）专注于内存安全与崩溃触发。两者互补：AI 扫描提供候选优先级，模糊测试提供可利用性验证。
结语
Mythos 对 curl 的首次扫描揭示了 AI 驱动漏洞发现的真实工作流程：多路径语义探索生成候选、语义验证过滤误报、人工复核确认 CVE、补丁定位与定级、负责任披露。从 5 个候选缩减为 1 个低危 CVE 的过程，正是 AI 能力与人类判断协作的缩影。
Daniel 的结论冷静而务实：Mythos 并未展现出与此前 AI 工具本质不同的能力，但 AI 代码分析工具整体上已显著优于传统静态分析工具。任何尚未引入 AI 安全扫描的项目，通过 Mythos 或其他工具大概率能发现大量缺陷与漏洞。关键在于建立高效的候选过滤机制与负责任的披露流程。
资料来源：Daniel Stenberg，curl 项目维护者，《Five Findings Became One》，2026 年 5 月 11 日。
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。