curl 安全更新揭示 AI 漏洞研究成效

书籍：AI Agents Pocket Guide

我的其他作品：Thinking in Go（两本系列）——Go 编程完整指南 + Go 六边形架构

我的项目：Hermes IDE | GitHub——面向使用 Claude Code 和其他 AI 编程工具交付软件的开发者的 IDE

关于我：xgabriel.com | GitHub

今年 1 月，curl 关闭了漏洞赏金计划。此前一周收到的七份报告，没有一份描述了真正的漏洞。首席开发者 Daniel Stenberg 表示，此举是为了消除提交“垃圾报告和未经充分研究的报告”的激励，“无论是否由 AI 生成”。九个月后，10 月 14 日，curl 8.23.0 发布，包含 24 项安全修复。逐一查看这 24 份安全公告中的致谢信息，会发现其中 20 份来自 AI 辅助研究：18 份归功于 AI 安全公司 AISLE，另外 2 份归功于 Anthropic，其中包括唯一被评为 High 的漏洞。

这一次，AI 辅助提交的报告经受住了检验：curl 安全团队确认了这些漏洞，项目还缩短了发布周期，以便尽快交付修复。

curl 8.23.0 发布了哪些内容

Stenberg 的发布文章列出了 24 项安全修复、281 项 bug 修复和 476 次提交。距离 9 月 2 日发布 curl 8.22.0，过去了 42 天。升级前有两项变更需要留意：curl 和 libcurl 移除了 SMB(S) 支持，CURL_GLOBAL_WIN32 被弃用，改用 CURL_GLOBAL_WINSOCK（见发布文章）。

安全页面显示，24 份新增公告中，23 份评级为 Low，1 份评级为 High。大部分是与凭据和状态有关的逻辑 bug：向重定向后的源站发送 Negotiate 凭据、向 HTTP 代理泄露主机凭据、CURLINFO_EFFECTIVE_URL 中的密码泄露、响应擦除 HSTS 条目，以及 wolfSSL 公钥固定校验被绕过。有些 bug 已经存在很久。代理凭据泄露漏洞 CVE-2026-86414 影响从 7.10.8 到 8.22.0 的所有版本。

curl 在 10 月 14 日修复的大多数 bug，都是由机器辅助审计发现，再由 curl 安全团队确认的。

每份公告的致谢信息都列出了报告者。按来源归类如下：

AISLE 在自己的文章中列出了它发现的 18 个 CVE 编号，与这些公告一一对应。例如，CVE-2026-86414 致谢的是“Aisle Research”。Anthropic 发现的两个漏洞分别是评级为 High 的 CVE-2026-92392，以及使用 GnuTLS 通过 WebSockets 上传时发生信息泄露的 CVE-2026-107928。两份公告的致谢信息都写着“with Claude, Anthropic”。另外四份公告，例如 CVE-2026-107929，致谢的是个人报告者，没有提及使用了什么工具。

AISLE 之前就做过这样的工作。该公司表示，8.22.0 修复的 CVE 中有六个是它发现的。Stenberg 在介绍 AISLE 审计的文章中写道，过去大约一年，这项工作累计带来了“不少于 35 个已公开的 curl 漏洞和 CVE 编号”，并帮助项目“以前所未有的速度”修复漏洞。

唯一的 High 漏洞：HTTP/2 上传中的 use-after-free

CVE-2026-92392 影响 curl 8.12.0 到 8.22.0，命令行工具也在影响范围内。公告称，当服务器发来原因码为 HTTP_1_1_REQUIRED 或 REFUSED_STREAM 的 HTTP/2 RST_STREAM 时，curl“处理不当”，导致 struct Curl_easy 出现 use-after-free，即释放后使用。该漏洞于 9 月 15 日被报告。

Stenberg 在另一篇文章中称，这是“curl 很长一段时间以来最严重的漏洞之一”。公告表示，“已经证实有可能将其转化为远程代码执行”。综合公告和那篇文章，利用条件相当苛刻：受害者需要向一个证书仍能通过验证的恶意服务器上传大约 135KB 数据；攻击者需要“已知且兼容的 libc 分配器构建版本和堆布局”；可用的 payload 空间只有大约 23 字节。Stenberg 的判断是：“攻击尝试最可能造成的结果其实只是崩溃”，“攻击成功的概率很低”。curl 将其评为 High，而非 Critical。

他写道，这个 bug 是一名 Anthropic 研究人员“使用他们新的 OSS Scanner”发现的，并补充说：“推测其中使用了他们的 AI 模型。”团队在数小时内确认了漏洞，并将发布周期从八周缩短为六周，以便交付修复（见同一篇文章）。

Stenberg 也排除了重写的可能：“我们不会重写 curl。既不会换一种语言重写，也不会用 C 重写。”他在文章中这样写道。curl 采取的做法是：用传输标识符替代指向句柄的内部指针，并增加测试和分析器。

经人工审核的报告，以及未经审核的新渠道

两家公司都使用了模型，也都由人向 curl 提交报告。AISLE 表示，“AISLE 安全研究人员会在提交前审核完整报告”，随后由 curl 安全团队独立判断每项发现是否属实、严重程度如何，以及是否分配 CVE（见 AISLE 的文章）。Anthropic 的两份报告由一位具名的 Anthropic 研究人员提交，公告中的致谢注明了“with Claude”。

不同之处在于 Anthropic 于 10 月 8 日开放的公共服务。它的 OSS Scanner 采用了另一种方式：“这个自愿加入的漏洞扫描器，其输出将完全由模型生成，不经过人工审核或分诊。”Anthropic 表示，过去六个月的扫描产生了超过 29,000 个候选漏洞，其中约 6,000 个经过了人工审核和分诊。这项服务免费，需要主动加入，灵感来自 Google 的 OSS-Fuzz。维护者可以向 anthropics/oss-scanner 提交 pull request，为项目报名。据 The Hacker News 报道，配置会指向一个 Dockerfile，用于为离线 Agent 构建项目；对于未经审核的发现，Anthropic 不会强制执行 90 天的披露期限。

一方明确规定，在模型和维护者之间安排人工审核；Anthropic 这项自愿加入的服务则承诺直接提供原始输出。

如果你为项目报名，按照 Anthropic 的说法，服务发给你的就是“未经人工审核或分诊”的输出，区分真实 bug 和误报是你的工作。curl 在 1 月关闭漏洞赏金计划，已经展示了源源不断的未经验证的报告会给小团队带来多大成本（见 The Register 的报道）。

本周需要检查什么

安全公告的首要建议是升级到 8.23.0。如果你必须使用较旧的分支，公告还列出了已修复的补丁版本：8.20.2、8.16.2 和 8.14.3（见 CVE-2026-92392）。发行版软件包可能在保留旧版本号的同时回移植修复补丁，因此应查看供应商的安全公告，而不能只看版本号。

棘手的是 libcurl。公告指出，很多应用都会使用它，却不一定明确说明。因此，检查范围不能只有 PATH 中的 CLI：

curl --version | head -n 1

# libcurl your C builds compile against (runtime may differ)
curl-config --version

# libcurl inside PHP, and Python if you use pycurl
php -r 'echo curl_version()["version"], PHP_EOL;'
python3 -c 'import pycurl; print(pycurl.version)'

# inside a container image you ship
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 漏洞仍需要升级或使用打过补丁的构建版本。

你愿意让自己的项目加入这样的扫描服务吗：它会把未经人工检查的模型输出直接发给你。欢迎在评论区告诉我。

我是 Hermes IDE 的开发者，请在评估上述内容时考虑这一点。如果你让 Claude Code、Codex 或其他编程 Agent 在自己的仓库中寻找这类 bug，Hermes 会让每个 Agent 在独立的分支和 worktree 中运行；它的 Review Desk 则让你可以在合入前，逐轮查看每一次改动。它免费、源码可见，并托管在 GitHub 上。如果你自己开发 Agent，AI Agents Pocket Guide 介绍了构建这类 Agent 所需的循环、工具和护栏模式。

如需采取进一步行动，你可以考虑屏蔽此人和／或举报滥用行为。