6 月 24 日，curl 发布了一次史无前例的安全更新：一次性修复了 18 个 CVE，是 curl 项目 28 年历史上单次最多的漏洞披露。安全公司 Aisle 一家就贡献了 6 个，其中包括一个从 curl 7.8（2001 年 7 月）就活到今天的最老 bug。

curl 不是什么小众项目。30 亿设备上跑着，每台服务器、每个容器、每个 CI 流水线都在用它传数据。一次 18 个 CVE，值得认真看看这波到底挖出了什么。

18 个漏洞全览

先把完整列表摆出来。每个开发者都应该对照自己的 libcurl 版本扫一眼：

CVE 严重度 影响范围 一句话描述
CVE-2026-12064 低 curl 工具 默认协议跳过 SSH 主机验证
CVE-2026-11856 中 libcurl Digest 认证跨源泄露，7.10.6 起受影响
CVE-2026-11586 低 通用 WebSocket 自动 PONG 导致内存耗尽
CVE-2026-11564 低 libcurl 原生 CA 信任持久化残留
CVE-2026-11352 低 通用 QUIC 零长度 UDP 报文忙等循环
CVE-2026-10536 低 libcurl HTTP/2 流依赖树重置后释放后使用
CVE-2026-9547 低 libcurl SSH 主机验证不完整
CVE-2026-9546 低 curl 工具 发送过期 Referer 头
CVE-2026-9545 低 通用 HTTP/3 过早数据被暴露
CVE-2026-9080 低 libcurl socket 回调中暂停后释放后使用
CVE-2026-9079 低 libcurl 代理密码残留泄露
CVE-2026-8932 低 libcurl mTLS 证书配置变更后仍复用旧连接，存活 25 年
CVE-2026-8927 低 通用 环境变量跨代理 Digest 认证泄露
CVE-2026-8926 低 libcurl netrc 和 URL 用户名组合时密码泄露
CVE-2026-8925 低 libcurl SASL 认证中 GSASL 上下文重复释放
CVE-2026-8924 低 通用 尾部点号域名导致超级 Cookie
CVE-2026-8458 低 libcurl 不同服务间错误复用连接
CVE-2026-8286 低 libcurl STARTTLS 连接错误复用

18 个里面唯一的中危是 CVE-2026-11856（Digest 跨源泄露），其余全是低危。但这不代表安全。低危在嵌入式设备、容器运行时、包管理器这类不可见路径上，往往比中高危更难发现和修复，因为开发者根本不知道自己在用哪个版本的 libcurl。

连接复用——贯穿 18 个 CVE 的主线

扫一眼这 18 个漏洞，一个词反复出现：连接复用（connection reuse）。18 个里至少 10 个跟它直接相关：

  • CVE-2026-8932：mTLS 证书变了，连接照用不误
  • CVE-2026-11856：Digest 认证跨源，连接池里的认证状态带到了错误的 host
  • CVE-2026-8458：不同服务共用连接
  • CVE-2026-8286：STARTTLS 握手后仍然复用未加密连接
  • CVE-2026-9079：代理连接上的密码残留
  • CVE-2026-8927、CVE-2026-8926：netrc 和 URL 里的凭证跨连接泄露

这不是巧合。curl 的连接池设计在 25 年里被反复修补，每次修一个边界条件，就在另一个边缘打开一个新缺口。连接复用的逻辑本质上是一组"什么条件下可以复用"的判断规则，这些规则在 HTTP/1.1、HTTP/2、HTTP/3、HTTPS、SMB、FTP、SSH 等十几个协议上的行为各不相同。25 年来，每个协议的支持代码都在独立演化，但连接池的判断逻辑只增不减，从未被系统性地重构过。

CVE-2026-8932：活了 25 年的 mTLS 检查遗漏

这个漏洞从 curl 7.8（2001 年 7 月）一直活到 8.20.0（2026 年 6 月），跨了整整 25 年。触发条件非常具体：应用在两次请求之间修改了 TLS 客户端证书相关的配置选项（尤其是私钥参数），但 libcurl 的连接复用检查没把这些选项纳入比对范围。结果就是新配置根本没生效，旧连接带着旧证书继续上。

说实话，这个 bug 能在 curl 的代码库里存活 25 年，不是因为藏得深，而是因为 mTLS 不是 curl 的主要使用场景。绝大多数 curl 调用是客户端单向验证服务端证书，用到客户端证书的场景少得多。但一旦用到，比如内部微服务间的 mTLS 通信，如果底层的 libcurl 版本没更新到这个补丁，证书变更可能完全无效。

这些漏洞都是怎么挖出来的

背景是这样的：5 月 11 日，curl 创始人 Daniel Stenberg 宣布 Anthropic 的 Mythos 模型在 curl 中发现了一个 CVE。这个消息在安全圈引发了一波针对 curl 的集中审计，最终催生了这 18 个 CVE。

Aisle 在这次"挖洞大赛"里表现最突出，18 个里占了 6 个。他们的做法跟传统的全量代码扫描不太一样：

  1. 模型无关：不绑定 OpenAI 或 Anthropic，针对不同的代码分析任务选择最合适的模型
  2. 定位"被遗忘的代码路径"：明确瞄准连接复用状态机、TLS 回退路径、认证凭据选择逻辑这些 curl 里被反复修补过的老代码区域，而不是扫全量
  3. 不光找，还修：6 个 CVE 里 3 个的修复补丁是 Aisle 平台自动生成的

这种"定向审计"的产出比远高于全量扫描。curl 这种经过 25 年打磨的基础设施项目，表层 bug 早就被人工和安全工具扫干净了。剩下的全在协议交互的边缘：状态机转换、资源生命周期交叉、多层抽象间的假设不一致。这些地方传统的静态分析几乎覆盖不到，但正是 AI 模型在理解代码语义后擅长发现的盲区。

你需要做什么

  • 立即更新 curl 到 8.20.1 或更高版本：所有 18 个 CVE 都在这个版本里修复了。如果你的项目静态链接了 libcurl，需要重新编译
  • 检查间接依赖：很多项目通过第三方 SDK 间接依赖 libcurl（AWS SDK、各种 HTTP 客户端库），你的 Dockerfile 里很可能有一个你不知道的 curl 版本
  • 重点关注 HTTP/2 和 SASL 的使用场景：CVE-2026-10536（HTTP/2 流依赖树 UAF）和 CVE-2026-8925（SASL 重复释放）虽然评为低危，但在特定条件下可能被利用
  • 如果使用 mTLS：立刻确认 libcurl 版本。CVE-2026-8932 这个漏洞说明一件事：你的证书变更可能在不知不觉中完全没生效

这次的 18 个 CVE 说明一件事：成熟的、经过长期审计的基础设施项目，不是"没漏洞了"，而是"容易找的漏洞已经被找完了"。AI 安全工具的真正价值在于让审计者能以合理的成本翻那些"大家都知道该看看、但 25 年来没人翻过"的代码角落，而不是替代人工。

⚠️ 网络安全免责声明

本文内容仅供技术研究与安全学习之用。文中描述的漏洞分析均基于 curl 项目公开发布的安全公告和 CVE 记录，旨在帮助开发者理解漏洞原理、提升安全意识和防御能力。

请勿将本文所述技术用于任何未经授权的安全测试、渗透攻击或非法用途。任何因滥用本文信息而造成的法律后果，由使用者自行承担，与本文作者无关。

如发现系统安全漏洞，请通过合法渠道向相关厂商或平台报告，共同维护网络安全生态。