curl 8.23.0 修复 24 个 CVE，AI 辅助研究贡献 20 个

curl 8.23.0 一次修复了 24 个安全漏洞，其中 20 个来自 AI 辅助研究——这个数字本身就值得细看。

从关闭漏洞赏金到单次修复 24 个 CVE

时间线的对比很有戏剧性。今年 1 月，curl 关闭了漏洞赏金计划——此前一周收到七份报告，没有一份描述了真实漏洞。主开发者 Daniel Stenberg 当时表示，目的是消除"垃圾和未经充分研究的报告"的激励，无论是否由 AI 生成。

九个月后，10 月 14 日发布的 curl 8.23.0 带来了 24 个安全修复。查看这些安全公告的致谢名单，其中 20 个指向 AI 辅助研究：18 个来自 AI 安全公司 AISLE，2 个来自 Anthropic，包括唯一一个被评级为 High 的漏洞。

这一次，AI 辅助的报告站住了脚：curl 安全团队确认了它们，项目为此缩短了发布周期来交付修复。这不是"AI 生成垃圾报告"的故事，而是"AI 辅助审计开始产出可验证结果"的转折点。

CVE（Common Vulnerabilities and Exposures，通用漏洞与暴露）是由 MITRE 公司维护的一套公开漏洞编号体系，每条 CVE 对应一个经确认的安全缺陷，格式为 CVE-年份-编号，例如文中出现的 CVE-2026-92392。它本身不提供修复方案或严重性评级，只是给漏洞一个全球唯一的"身份证号"，方便厂商公告、软件物料清单和安全工具之间相互引用。与之配套的 CVSS（通用漏洞评分系统）才负责量化严重程度，curl 项目使用的 Low / Medium / High / Critical 分级即是内部简化后的评级。一个漏洞被分配 CVE 编号，通常意味着有维护者或 CNA（CVE 编号授权机构）确认了该缺陷真实存在，因此"某次发布修了多少个 CVE"常被用作衡量安全审计产出规模的事实指标。

curl 8.23.0 里到底修了什么

Stenberg 的发布帖子列出了 24 个安全修复、281 个 bugfix 和 476 个提交，距离 9 月 2 日的 curl 8.22.0 仅 42 天。升级前有两项变更值得注意：curl 和 libcurl 移除了 SMB(S) 支持，CURL_GLOBAL_WIN32 被弃用，改用 CURL_GLOBAL_WINSOCK。

在安全页面上，24 个新公告里 23 个评级为 Low，一个为 High。清单主要是围绕凭证和状态的逻辑漏洞：Negotiate 凭证被发送到重定向后的源、主机凭证泄露给 HTTP 代理、CURLINFO_EFFECTIVE_URL 中的密码泄露、响应抹除 HSTS 条目、wolfSSL 公钥固定绕过。其中一些是陈年老 bug——代理凭证泄露 CVE-2026-86414 影响从 7.10.8 到 8.22.0 的所有版本。

谁发现了什么

每个公告的致谢行都点名了报告者，按来源分组后格局很清晰：

报告者	8.23.0 中的 CVE 数	严重性
AISLE Research	18	全部 Low
Anthropic（致谢标注"with Claude"）	2	1 High、1 Low
个人研究者	4	全部 Low

AISLE 在自己的文章里列出了那 18 个 CVE ID，与公告完全吻合。Anthropic 的两个是 CVE-2026-92392（High）和 CVE-2026-107928（通过 GnuTLS 在 WebSocket 上传时的信息泄露），致谢行都写着"with Claude, Anthropic"。另外四个公告只感谢个人报告者，未提及工具。

AISLE 此前已有先例——它称自己在 8.22.0 中发现了六个 CVE。Stenberg 关于这次 AISLE 审计的帖子把过去约一年的总数描述为"不少于 35 个已发布的 curl 漏洞和 CVE ID"，并表示这项工作帮助项目以"比以往任何时候都更高的速度"修复漏洞。

struct Curl_easy 是 libcurl 中代表一次"简单传输"的核心内部结构体，每个 CURL* 句柄背后都对应一个这样的对象，它保存了该次传输的连接、状态机、选项和缓冲区信息。RST_STREAM 则是 HTTP/2 协议里的帧类型（类型码 0x03），用于单方面中止某条流——服务器在拒绝该流时会携带错误码，如文中出现的 REFUSED_STREAM 和 HTTP_1_1_REQUIRED（后者表示服务器要求客户端改用 HTTP/1.1）。正常情况下收到 RST_STREAM 后 curl 应妥善结束该流并清理状态，而漏洞版本在此路径上错误地释放了传输对象，稍后又再次访问它，从而形成 UAF。这也解释了修复为何是"改用传输标识符代替内部句柄指针"：用间接索引代替裸指针，即使对象已释放，旧引用也无法直接解引用到已回收内存。

那个 High 漏洞：HTTP/2 上传中的 use-after-free

CVE-2026-92392 影响 curl 8.12.0 到 8.22.0，命令行工具也在内。公告称 curl"错误处理了服务器发来的 HTTP/2 RST_STREAM"，原因为 HTTP_1_1_REQUIRED 或 REFUSED_STREAM 时，会导致 struct Curl_easy 的 use-after-free。该漏洞于 9 月 15 日报告。

Stenberg 在另一篇分析中称其为"curl 很长时间以来最严重的漏洞之一"。公告表示"已被证明可以转换为远程代码执行"。但条件极为苛刻：受害者向一个证书仍能通过验证的恶意服务器上传约 135KB 数据，攻击者需要"已知且兼容的 libc 分配器构建和堆布局"，可用载荷区域仅约 23 字节。Stenberg 的估计是："攻击尝试最可能的结果只是崩溃"，"成功攻击的几率很小"。curl 将其评为 High 而非 Critical。

他写道，这个 bug 由一位 Anthropic 研究员"使用他们新的 OSS Scanner"发现，并补充"推测这涉及他们的 AI 模型"。团队在数小时内确认，并将发布周期从八周缩短到六周来交付修复。

Stenberg 同时排除了重写方案："我们不会重写 curl，不是换成另一种语言，也不是换成 C。"取而代之的是，curl 改用传输标识符代替内部句柄指针，并增加测试和分析器。

use-after-free（释放后使用，简称 UAF）是一类内存安全漏洞：程序释放了一块堆内存后，仍持有指向该地址的指针并继续读写。由于分配器很快会把这块内存重新分配给别的对象，攻击者若能影响这块内存的内容和布局，就可能劫持程序的控制流。在 C 语言项目里 UAF 是最常见的可利用漏洞类型之一，也是比较容易被转化为远程代码执行（RCE）的缺陷。利用 UAF 的难点在于稳定控制"释放—重用"的时序与堆布局，通常需要搭配堆风水（heap grooming）技术反复分配释放来塑造内存排列；文中提到攻击者需"已知且兼容的 libc 分配器构建和堆布局"，以及可用载荷仅约 23 字节，正说明这类利用对环境的严苛依赖。curl 将其评为 High 而非 Critical，也是基于这一现实可行性判断。

经过人工审查的报告，和一个不审查的新渠道

两家厂商都用了模型，且都由真人提交了 curl 报告。AISLE 表示"AISLE 安全研究员在提交前审查完整报告"，随后 curl 安全团队自行判断每个发现是否真实、严重程度如何、是否分配 CVE。Anthropic 的两个来自具名研究员，公告致谢标注"with Claude"。

真正的分歧在于 Anthropic 在 10 月 8 日开放的公共服务。其 OSS Scanner 反向运作："该可选漏洞扫描器的输出将完全由模型生成，没有人工审查或分诊。"Anthropic 称过去六个月的扫描产生了超过 29,000 个候选漏洞，其中约 6,000 个经过人工审查和分诊。该服务免费、可选，灵感来自 Google 的 OSS-Fuzz，维护者通过向 anthropics/oss-scanner 提交 pull request 来注册。据 The Hacker News 报道，其配置指向一个构建离线 agent 的 Dockerfile，且 Anthropic 不会对未审查的发现施加 90 天披露期限。

如果你注册该项目，服务发送给你的——用 Anthropic 的话说——是"没有人工审查或分诊"的输出，分辨真实 bug 和误报是你的工作。curl 今年 1 月关闭赏金计划的决定，正说明了未经核实的报告洪流对一个小团队意味着什么。

OSS-Fuzz 是 Google 于 2016 年推出的开源模糊测试服务，它持续对数百个关键开源项目做自动化 fuzzing，发现崩溃后自动生成可复现用例，并直接向维护者提交 bug。它的关键在于把噪声挡在维护者之外：经过去重、可复现性验证和最小化处理后才产出报告，因此被广泛视为自动化漏洞发现负责任流程的标杆。Anthropic 的 OSS Scanner 在灵感上对标 OSS-Fuzz，但流程相反——不经人工分诊、不设披露期限，直接输出模型生成的候选结果。对维护者而言，两者的差别不只是报告数量的量级，而是"免费获得已过滤的高质量信号"与"自行承担全部筛选成本"之间的根本差异，这也解释了为何 curl 关闭赏金与 Anthropic 开放扫描服务被放在一起讨论。

这周该检查什么

公告的首要建议是升级到 8.23.0。如果你固定在旧分支上，它也列出了修复版本：8.20.2、8.16.2 和 8.14.3。发行版软件包可能在旧版本号下携带了反向移植补丁，所以要看厂商的公告而不是只看版本号。

棘手的是 libcurl——公告指出它被许多应用使用，而这些应用并不总是公开声明。除了 PATH 上的 CLI，还要检查这些位置：

curl --version | head -n 1

# C 构建所链接的 libcurl（运行时可能不同）
curl-config --version

# PHP 内的 libcurl，以及使用 pycurl 时的 Python
php -r 'echo curl_version()["version"], PHP_EOL;'
python3 -c 'import pycurl; print(pycurl.version)'

# 你发布的容器镜像内
docker run --rm --entrypoint curl your-image:tag --version

如果无法立即升级，公告的第三个选项是"不使用 HTTP/2"。命令行上加 --http1.1；libcurl 中设置 CURLOPT_HTTP_VERSION：

curl_easy_setopt(h, CURLOPT_HTTP_VERSION,
                 (long)CURL_HTTP_VERSION_1_1);

但这只覆盖了那个 High 漏洞。其余 23 个 Low 修复仍需要升级或打补丁的构建。

一个值得关注的问题

curl 的案例展示了一种可能成为常态的协作模式：模型负责大面积扫描和候选挖掘，人类研究员筛选和验证，项目安全团队最终裁定。AISLE 的流程保留了人工审查环节，Anthropic 的选择性报告同样如此。

但 Anthropic 新开放的 OSS Scanner 把人工审查这一步去掉了，把分诊负担转嫁给维护者。考虑到 curl 半年前刚因垃圾报告关闭赏金，这个方向值得开源维护者们认真权衡。