Aisle 在 curl 中发现 6 个新 CVE，包括有史以来报告的最古老问题

# AISLE 发现 curl 的 6 个 CVE，包括有史以来最古老的问题 来源：https://aisle.com/blog/aisle-discovers-6-new-cves-in-curl-including-the-oldest-issue-ever-reported curl 运行在超过 300 亿台设备上。作为全球最重要的软件之一，它促进了操作系统、容器、设备、CI 流水线、包管理器、SDK、汽车之间的数据传输，甚至出现在火星上的 NASA 机智号直升机中。数十亿用户从未直接运行过 `curl` 命令，但仍然通过其他产品依赖 curl 背后的引擎 libcurl。 2026 年 5 月 11 日，curl 创始人兼首席开发者 Daniel Stenberg 宣布，Anthropic 的 Mythos 模型在 curl 中发现了一个 CVE。他的[博客文章](https://daniel.haxx.se/blog/2026/05/11/mythos-finds-a-curl-vulnerability/)引发了一波研究浪潮，导致大量安全报告涌向 curl 项目，最终 curl 版本发布的 CVE 数量达到了历史最高——18 个。 AISLE 在所有安全组织中脱颖而出，获得了这 18 个 CVE 中的 6 个（[来源](https://curl.se/mail/lib-2026-06/0026.html)），此外还有 curl 和 libcurl 的其他有效发现。紧随其后的 AI 驱动组织获得了 3 个 CVE，而使用 Anthropic 和 OpenAI 模型的研究人员各发现 1 个。这些发现进一步证明了 AISLE 的[模型无关系统](https://aisle.com/blog/system-over-model-zero-day-discovery-at-the-jagged-frontier)能够以极低的成本[超越前沿模型](https://aisle.com/blog/mythos-at-home-and-its-called-aisle)，并适用于[任何部署环境](https://aisle.com/blog/your-security-shouldnt-depend-on-someone-elses-api)。 所有 AISLE 的发现均已负责任地向 curl 项目披露，并在 2026 年 6 月 24 日发布的 [curl 8.21.0](https://curl.se/ch/8.21.0.html) 中修复。我们敦促所有人更新到最新版本。 ## 发现 curl 有史以来报告的最古老安全问题 curl 对安全研究人员尤其有吸引力：简单的漏洞早已被挖尽，剩下的难以发现：古老的协议路径、状态复用、回调行为、凭据选择，以及容易被遗忘的代码路径。这就是为什么我们在 2025 年秋季使用 AISLE 的自主漏洞检测能力，发现了 [29 个有效发现和 5 个 CVE](https://aisle.com/blog/curl-adopts-aisle-after-its-ai-agents-discovered-5-cves)。 AISLE 最新发现的 6 个 CVE，涵盖了从经典的内存生命周期问题到逻辑漏洞（libcurl 如何判断连接、凭据或主机身份是否仍然有效）。其中包括 CVE-2026-8932，这是迄今为止报告的最古老的 curl 漏洞，存在超过 25 年。自 curl 7.7 版本起开始发布，首次发布于 2001 年 3 月 22 日。 ## AISLE 发现总结 值得注意的是，有几个问题只影响 libcurl 应用程序，而不影响 curl 命令行工具。这意味着它们影响的是嵌入在产品深处、用户不知道其存在的代码，这些代码可能通过应用程序行为成为攻击目标。 | 发现 | 区域 | 发生了什么 | |------|------|-------------| | CVE-2026-8926 ([链接](https://curl.se/docs/CVE-2026-8926.html)) | `.netrc` 凭据处理 | 当 URL 提供了用户名但未提供密码时，curl 可能选择同一主机下不同用户的密码（凭据混淆）。 | | CVE-2026-8925 ([链接](https://curl.se/docs/CVE-2026-8925.html)) | SASL 认证 | 在启用 SASL 的协议流程中，curl 可能对同一个 GSASL 上下文执行两次清理和释放（双重释放）。 | | CVE-2026-8932 ([链接](https://curl.se/docs/CVE-2026-8932.html)) | mTLS 连接复用 | 即使在客户端证书或私钥设置已更改的情况下，libcurl 仍可能复用现有连接（认证绕过）。 | | CVE-2026-9080 ([链接](https://curl.se/docs/CVE-2026-9080.html)) | 多 socket 回调生命周期 | 在 socket 回调中调用 `curl_easy_pause()` 可能导致 libcurl 通过已释放的内部指针进行写入（释放后使用）。 | | CVE-2026-9547 ([链接](https://curl.se/docs/CVE-2026-9547.html)) | SSH 主机验证 | 在使用 libssh 后端时，使用主机密钥回调的 SCP/SFTP 传输可能会接受本应被拒绝的服务器密钥类型（主机验证不当）。 | | CVE-2026-10536 ([链接](https://curl.se/docs/CVE-2026-10536.html)) | HTTP/2 流依赖 | 重置然后清理使用 HTTP/2 依赖选项的句柄，可能导致 libcurl 访问已释放的状态（释放后使用）。 | AISLE 还报告了其他几个 curl 漏洞，包括三个内存安全问题： - 在 HTTP/2 流依赖树中使用 `curl_easy_duphandle()` 时的释放后使用 ([链接](https://hackerone.com/reports/3751701)) - 在 urlapi 的 `redirect_url()` 中，通过 `CURLU_GUESS_SCHEME` + `CURLU_NO_GUESS_SCHEME` 流程导致的堆越界读取 ([链接](https://hackerone.com/reports/3751715)) - CURLOPT_HSTS_CTRL 在没有共享保护的情况下禁用共享 HSTS —— 释放后使用和双重释放 ([链接](https://hackerone.com/reports/3733934)) 并非每个漏洞都会成为 CVE，但这些报告属于同一类别。它们都是成熟基础设施代码中的细微边界情况，尤其是围绕内存安全、状态转换和晦涩的 API 路径。 ## 为模型无关安全系统增添论据 AISLE 在此次发布中获得了 18 个总发现中的 6 个，这一事实进一步支持了我们的前提：精心设计的模型无关系统在网络安全任务上可以与高性能前沿模型相媲美。 此外，AISLE 不仅仅是发现漏洞。其中三个 CVE 还通过我们平台生成的修复程序进行了修补。这表明[网络安全能力是参差不齐的](https://aisle.com/blog/ai-cybersecurity-after-mythos-the-jagged-frontier)：对于定义明确的安全任务，较小的模型可以超越更大、更昂贵的 LLM。值得注意的是，它们可以完全本地、完全本地化地运行，[无需进行 API 调用](https://aisle.com/blog/control-is-the-new-frontier-in-security-ai)。 挑战在于匹配模型能力与安全需求。换句话说，AI 原生网络安全主要不是一个计算问题，而是一个工程问题。 ## 使用 AISLE 为安全工程 AI AISLE 的端到端漏洞管理平台在您的部署约束内提供自主安全能力，从气隙网络到云环境。如果您想了解 AI 会在您的代码库中发现什么，[请联系我们](https://aisle.com/demo)。 *我们衷心感谢 curl 项目在披露过程中表现出的专业性。所有我们的 CVE 均由 AISLE 研究团队的 Joshua Rogers 报告和披露。*