Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

引言 — 一个版本，18 个 CVE
先核对数字 — curl 2026 年上半年
是怎么走到这一步的 — 灌水时代与漏洞赏金之死
「高质量混乱」 — 涌来的不是灌水，而是真家伙
这 18 个 CVE 到底修了什么
没能变成 CVE 的 bug — 第一起 CNA 争议
功能方面 — MASQUE 代理、named glob，以及移除预告
实务层面会发生什么变化
结语
参考资料

引言 — 一个版本，18 个 CVE

2026 年 6 月 24 日，curl 8.21.0 发布了。Daniel Stenberg 每次发布都会附上的统计数字这次也照例出现，其中有一行格外扎眼。第 275 个版本，56 天周期，531 次提交，276 项 bug 修复，6 个新功能——外加 18 项安全修复。

一个版本 18 个 CVE，是 curl 项目历史上最多的一次。就 2026 年全年的发布量而言，也已经是新纪录。只看这个数字，会让人觉得「curl 是不是出什么事了」，但把这 18 个拆开看，故事就不一样了。Medium 4 个，Low 14 个。既没有 High，也没有 Critical。curl 上一次的 High 级别 CVE，仍然是 2023 年 10 月的 CVE-2023-38545(SOCKS5 堆溢出)。

所以这次发布真正的故事，并不是「curl 变危险了」。而是安全报告生态今年发生了结构性变化，curl 正站在这场变化的最前线。本文沿着一手资料追踪这一过程——灌水时代、漏洞赏金的废除、迁移 GitHub 的失败尝试，直到 Stenberg 称之为「高质量混乱」(High-Quality Chaos) 的当下——并梳理实务层面会发生哪些变化。

先核对数字 — curl 2026 年上半年

curl 把自己完整的漏洞历史，公开为机器可读数据(vuln.json)。我没有照抄博客里的说法，而是直接数了这份文件。按发布日期统计的各年 CVE 数量如下。

年份	发布的 CVE 数
2020	6
2021	13
2022	21
2023	18
2024	11
2025	9
2026 年(截至 6 月 24 日)	36

按 2026 年各版本拆分：1 月 7 日(8.18.0)6 个，3 月 11 日(8.19.0)4 个，4 月 29 日(8.20.0)8 个，6 月 24 日(8.21.0)18 个。合计 36 个，在上半年结束之前，就已经超过了此前记录最多的年份 2022 年(21 个)。以单次发布日期计算，这次的 18 个也是历来最多的一次，此前的记录是 2016 年 11 月 2 日的 11 个。博客里「创纪录」的说法，和数据完全吻合。

有一点要提醒。这张图表达的不是「curl 的代码突然变差了」，而是「发现的速度变了」。这个区分，就是本文通篇的主题。

是怎么走到这一步的 — 灌水时代与漏洞赏金之死

得先梳理时间线，才能读懂现在的局面。以下全部出自 Stenberg 本人的记录。

2019 年 4 月 — curl 在 HackerOne 上启动漏洞赏金计划。截至废除时，累计确认漏洞 87 个，向研究者支付的奖金总额超过 10 万美元。
2024 年 1 月 — "The I in LLM stands for intelligence"。LLM 编造的漏洞报告开始成为公开议题。
2025 年 7 月 — "Death by a thousand slops"。灌水报告激增。往年一直高于 15% 的报告确认率(提交数中真实漏洞所占比例)，进入 2025 年后跌到 5% 以下——二十份提交里连一份真的都不到。
2026 年 1 月 26 日 — 宣布终止漏洞赏金。自 1 月 31 日起全面废除奖金。给出的理由是「消除提交编造谎言的动机」，报告渠道也从 HackerOne 转移到 GitHub 的私有漏洞报告(Private Vulnerability Reporting)。
2026 年 2 月 25 日 — 仅一个月后就宣布重返 HackerOne。奖金依旧没有恢复，但平台从 3 月 1 日起又变回 HackerOne。

他还留下了 GitHub 迁移为什么失败的记录，这份清单对任何在琢磨漏洞接收系统的团队来说，都能直接当作检查清单来用。报告全文以纯文本形式随通知邮件发出，这一点关不掉(存在提前泄露的风险)；无法把被判定无效的报告切换为公开状态(curl 的原则是连判错的报告也一并公开)；curl 是自己的 CNA，CVE 编号自行发放，但 GitHub 表单里的 CVE 字段却不能编辑；也没有用来统计灌水比例的标签功能。Stenberg 的结论是：「想在没有赏金的情况下做好漏洞接收的开源项目，现有的工具整体上都很欠缺。」

「高质量混乱」 — 涌来的不是灌水，而是真家伙

废除了赏金，报告是不是就变少了?恰恰相反。数字都在 4 月的「High-Quality Chaos」和5 月的「The pressure」里。

灌水已经不再是问题。取而代之的是报告频率达到 2024 年的 4~5 倍——而 2025 年本身已经是前一年的两倍——平均下来每天超过 1 份。
确认率回到了 AI 出现之前的水平(15%~16% 左右)，甚至更高。虽然不算漏洞、但确实是真实 bug 的报告比例，也比以前高出不少。
而且几乎每一份报告都能看出 AI 使用的痕迹——从文风、从结构上都能看出来，据说还能从同时涌入、精巧到人类写不出来的重复报告上判断出来。

也就是说，如果 2025 年的问题是「AI 编造出来的假货」，那么 2026 年 3 月以后的问题就变成了武装了 AI 的研究者，以人力无法处理的速度找出真实的 bug。Stenberg 在 4 月时曾预测「照这个趋势，今年 CVE 数量可能接近 50 个」，而 6 月 24 日时已经有 36 个了，正朝着这个预测走。

重要的是，这并不只是 curl 一家的事。Stenberg 在 Mastodon 上做的一次非正式调查中，Apache httpd、BIND、Django、Firefox、git、glibc、GnuTLS、HAProxy、Linux 内核、OpenLDAP、Python、Ruby、urllib3、Wireshark、wolfSSL 这些项目都确认了同样的趋势。更稳妥的假设是：在你整棵依赖树里，CVE 的发布速度都在上升。

另一方面，5 月还有一个有意思的对照案例。Anthropic 曾表示，一款检测安全缺陷的能力「强到有点危险，因此暂时只做有选择性地公开」而引发热议的模型 Mythos，通过 Linux Foundation 扫描了 curl，结果只有 1 个确认漏洞(Low)——安全团队核实报告所声称的「确认 5 个」后，筛掉了 3 个误报和 1 个只是普通 bug 的问题。在同一篇文章里，Stenberg 透露 AISLE、Zeropath、OpenAI Codex Security 这类 AI 分析工具，在最近 8~10 个月里已经为 curl 带来了 200~300 项 bug 修复，以及十几个以上的 CVE。他的评价是两面的：把某个特定模型神秘化更接近营销手法，但 AI 代码分析器整体确实比传统静态分析器找得更好，这也是事实。还有一个核心观察——AI 并不会发明新种类的漏洞，只是把已知种类里的新实例找出更多而已。

这 18 个 CVE 到底修了什么

这个观察，在 8.21.0 的 CVE 列表里能直接得到印证。翻一遍 2026 年 36 个 CVE 的标题，会发现有一个词反复出现：reuse。按我的统计，36 个里有 10 个标题带有 "reuse"——wrong STARTTLS connection reuse、wrong reuse of SMB connection、connection reuse ignores TLS requirement、incomplete mTLS config matching in conn reuse，等等。

这不是巧合。libcurl 会把已经完成传输的连接留在连接池里，等配置匹配的后续传输来时再复用，而「配置是否匹配」这个判断，只有把所有影响信任的维度——主机、端口、协议、TLS 选项、客户端证书、代理、认证状态——逐一比对完整，才算安全。每漏掉一个维度，就会多出一个「错误地复用了处于不同安全语境的连接」的 bug。一旦有一个案例作为 CVE 公开，手握 AI 工具的研究者就会开始有组织地挖掘同一类的变种。2026 年这一波 CVE 集群，就是这种挖掘留下的痕迹。

从协议管线的角度，值得留意的几个具体案例如下(严重程度与受影响版本以 curl 自身的披露为准)。

CVE-2026-9545 — HTTP/3 early data 泄露(Low)。 在开启了 TLS 会话缓存和 CURLSSLOPT_EARLYDATA 的情况下重新连接同一主机时，请求字节可能会通过 0-RTT 先发出去，而证书验证失败的结论此时还没确定。自 8.11.0(2024 年 11 月)起就存在。这是一个教科书式的案例，说明 0-RTT 默认关闭的原因——除了重放攻击之外，还存在「验证顺序」这个陷阱。
CVE-2026-11352 — QUIC 零长度 UDP 数据报导致的 busy-loop(Low)。 接收辅助函数把零长度数据报直接丢弃，却没有计入每次调用的包预算，于是恶意服务器只要不停发送空数据报，客户端就会无限期卡住。这是 8.18.0(2026 年 1 月)引入的一个回归问题，在 6 月被抓到。QUIC 的接收路径在用户空间，所以这类预算逻辑里的每一处细节，本身就是一道可用性边界——这一点在QUIC 接收端的 CPU 成本一文中已经讲过。
CVE-2026-10536 — HTTP/2 流依赖树 UAF(Low)。 用 CURLOPT_STREAM_DEPENDS 建立依赖树，之后在 curl_easy_reset() 中清理时，又碰了一次已经释放的结构体。自 7.88.0(2023 年 2 月)起就存在。有意思的是应对方式——8.21.0 没有止步于修好这个 bug，而是把流依赖追踪功能整个移除了。RFC 7540 的优先级树，在后续标准里已经被标记为废弃机制，与其维持一个几乎没人用的风险面，不如直接拆掉。
CVE-2026-8924 — 结尾点号引发的 super cookie(Low)。 cookie 解析器的 Public Suffix List 检查可以被绕过，恶意服务器可以植入一个会被发送到无关第三方域名的 cookie。引入版本是 7.46.0——2015 年 12 月。这个潜伏了十年多、连模糊测试、静态分析、审计都没能揪出来的 bug，这次在这波浪潮里被抓住了。

Medium 级别的 4 个问题分别是：SASL 双重释放、代理/跨源 Digest 认证状态泄漏两个，以及一个存在已久的代理密码泄漏。这些都属于认证状态跨越连接或重定向边界这一类，对经过代理的部署来说有实际意义，值得自己去看一下完整列表。

引入版本的分布也值得注意。从 2015 年的老问题，到今年 1 月才出现的回归，混杂在一起。发现问题的工具一旦变好，陈年沉积物和新鲜的失误就会一起被打捞上来。

没能变成 CVE 的 bug — 第一起 CNA 争议

在 CVE 大量涌现这个故事的另一面，还有一件同一天公开的首次 CVE 争议。curl 从 2024 年 1 月起就是自己的 CNA，因此在自己的范围内是否发行 CVE 由自己决定，而这是这一决定第一次被一路升级到 MITRE 的案例。

这个 bug 本身是真实存在的。通配符证书匹配函数会把像 https://.example.com/ 这样以点号开头的主机名，错误地匹配到 *.example.com 通配符上，问题已在 2025 年 12 月 8 日修复。但由于以点号开头的名字在 DNS 里本身就不合法，如果没有 /etc/hosts 这类本地介入是根本无法触及的，攻击者还得同时握有对应的通配符证书——前提条件层层叠加，于是 curl 安全团队用他们内部的说法把它判定为「低于 Low」，没有发行 CVE。报告者不服，向 MITRE 提起了争议，MITRE 在 2 月、5 月、6 月三次重复同一个问题，最终在 6 月 24 日给出裁定——不发行 CVE，维持 CNA 的判断。

这个插曲重要的地方，不在于裁定结果本身，而在于背后的成本逻辑。按 Stenberg 的估算，libcurl 在全球被安装在数百亿台设备上(借用他自己的说法，介于 200 亿到 300 亿之间)，每发行一个 CVE，全球安全团队的扫描器就会响起，随之引发一连串补丁和更新工作。这份成本是由整个生态系统在承担，而不是 curl。所以，不为一个实际上根本无法触及的理论问题拉响警报，同样是 CNA 的责任所在。同一年里，既发行了 36 个 CVE，又为了不发行一个 CVE 争论了四个多月的项目——这两件事出自同一个原则：以真实风险为准，而不是以数字为准。

功能方面 — MASQUE 代理、named glob，以及移除预告

虽然被安全话题盖过了风头，但 8.21.0 的 6 项新功能里，从管线角度看也有分量不轻的东西。以下依据官方变更日志。

支持 HTTP/3 代理 — CONNECT 与 MASQUE CONNECT-UDP(仅限 ngtcp2 QUIC 构建)。此前 curl 的代理最多只能到 HTTP/1.1 或 HTTP/2，现在可以把代理这一段本身用 HTTP/3 打通，再在其上通过 CONNECT-UDP 承载 UDP(也就是端到端的 QUIC)。这相当于多了一件工具，能在 iCloud Private Relay 这类大型部署之外，去试验 MASQUE 系代理。
named glob — 给 URL glob 命名、并可在输出文件名里引用的 CLI 便利功能，也包括上传一侧的 glob 引用。
被移除的：HTTP/2 流依赖追踪(前面已说明)，以及为兼容 IE 6 而存在的 CURLAUTH_DIGEST_IE。

而发布说明末尾的移除预告清单，对实务人员来说可能才是最紧迫的部分。自带的 crypto 实现、NTLM、SMB、TLS-SRP 都被列为移除候选，如果你在用这些功能，说明里明确写着现在就该去 curl-library 邮件列表上发声。这股清理遗留认证方式和协议的浪潮，方向和 OpenSSH 10.4 的废弃列表完全一致。想想还有多少企业内网自动化依赖 NTLM 代理认证，这条预告不是可以悄悄略过的条目。

下一个版本因为夏季休整，把周期延长了两周，预告为 9 月 2 日。

实务层面会发生什么变化

不管你是直接链接 libcurl，还是它只是作为基础镜像里的发行版软件包存在，这股趋势触及你团队的地方大致如下。

扫描器噪音会增加。 curl 每年 9~11 个的 CVE 数量，今年跳到了 36 个以上，容器镜像扫描结果里 curl 相关条目会明显变多。好在 curl 的披露质量在业界属于顶级——每个案例的详情页都写明了从引入提交到修复版本的全部信息，vuln.json 又以兼容 OSV 的模式提供，所以可以搭一条流水线，自动判断「我们的版本是否真的落在受影响范围内」。

严重程度是需要重新评估之后再用的数值。 curl 的评级，是站在「不知道用户具体怎么用」这个前提下、从 curl 自己的视角给出的评级。比如你从来没开过 CURLSSLOPT_EARLYDATA，CVE-2026-9545 就与你无关；从没用过流依赖 API，CVE-2026-10536 也一样无关。反过来，如果你的环境里代理加认证的组合很多，那 4 个 Medium 就得比标注的等级更认真地对待。

没有理由恐慌。 近几年 curl 的漏洞全都是 Low/Medium，上一次 High 停留在 2023 年 10 月——这个事实，是一个几十年来接受着远超常规审视的代码库的实测数据。但反过来的教训也得一起带走——即便是被剖析到这个程度的代码，工具一变好，半年就冒出来 36 个。要是换成扫描历史浅得多的你公司内部的 C 代码，只会冒得更多。用 Stenberg 的说法，不跑 AI 分析器的项目，等于是白白给了攻击者用同样的工具先一步找到问题的时间。

维护者一侧的成本也该纳入视野。 每天验证、修复、披露一份以上安全报告的工作，目前是由少数几个人扛着的，Stenberg 在 5 月的文章里第一次公开提到了健康和工时方面的担忧，并呼吁商业用户签订支持合同。当这股趋势蔓延到整条依赖链时，每个项目自身的应对能力，就是你的供应链风险。这波浪潮会不会像模糊测试那样终有一天进入平台期，他自己也只说「得看下去才知道」。

结语

总结一下：curl 8.21.0 的这 18 个 CVE，不是代码变差的信号，而是自 2026 年 3 月起，安全研究生态用 AI 重新武装，发现速度出现结构性跃升的信号。灌水时代随着漏洞赏金一起结束了，现在涌来的是一场真实 bug 的洪水——大多是 Low 级别，新旧问题混杂(陈年沉积与新鲜回归并存)，并且集中在连接复用这类特定的 bug 类别上。

curl 正在以创纪录的透明度穿过这波浪潮——逐案的详细披露、机器可读的数据，甚至连拒发 CVE 时都保持着和发行 CVE 一样的认真态度。我们该做的事很朴素：搭建一条流水线，按实际影响范围对扫描结果里增多的 curl 条目做分诊；现在就去确认 NTLM、SMB 这类移除预告清单有没有碰到自己的工作负载；把补丁节奏调整成适应「整条依赖链的 CVE 发布速度都在上升」这个新时代的样子。还有——下次在某份发布说明里看到「18 项安全修复」时，先读严重程度和前提条件，再对数字感到吃惊的习惯——这就是这个新时代的基本功。