半年扫出超2.9万疑似漏洞！Claude揪出curl高危隐患，29天修复

　　新智元报道

　　AI 参与发现的高危漏洞，已经修好了。

　　10 月 14 日，网络传输工具 curl 发布了 8.23.0。

　　官方安全公告中致谢的报告者一栏，出现了 Claude 的名字：Luna with Claude, Anthropic。

　　随后，curl 开发者 Stefan Eissing 完成了修复。

　　如今，用户升级到 curl 已修复的版本，就能补上这个安全漏洞。

　　AI 参与找漏洞，开发者完成修复，团队发布更新，这套流程已经走通。

　　这样的 AI 安全检查，也正在向更多开源项目开放。

　　10 月 8 日，Anthropic 宣布推出 OSS Scanner，调用包括 Claude Mythos 在内的最强模型，为符合条件的关键开源项目免费定期扫描。

　　它交给维护者的，不只是一句「这里可能有问题」，还有漏洞解释、复现材料，以及可用时的候选补丁。

　　从找出问题，到帮助验证、提供修复建议，AI 正在承担更多安全工作。

　　但报告是否准确、补丁能不能用，仍要由维护者把关。

　　curl 修了什么问题？

　　curl 是开发者常用的基础工具，下载文件、调试接口、编写自动化脚本，都能用到它。

　　它的底层库 libcurl，也被大量软件用来传输数据。

　　据 curl 官方 2025 年的估算，全球约有 300 亿个安装实例在运行 curl。即使你从没敲过 curl 命令，也可能间接用到了它。

　　curl 官方估算：2025 年，全球约有 300 亿个 curl 安装实例。

　　支撑这一工具的，是一个长期协作的开源社区。

　　创始人 Daniel Stenberg 在 2026 年 10 月披露，已有 1545 人为 curl 提交过代码，通常每年有超过 150 人参与代码贡献。

　　使用如此广泛，curl 的安全问题也可能影响依赖它的软件。

　　这次修复的 CVE-2026-92392 就被评为高危，问题出在 HTTP/2 上传过程中。

　　简单来说，就是 curl 处理服务器发来的特定消息时出了错：一块内存已经释放，它却还在接着用。

　　这块内存可能已被分配给其他数据，curl 继续读写，就可能读错内容，甚至改坏别的数据。

　　这类问题叫作「释放后使用」。

　　curl 官方确认，恶意服务器在满足特定条件后，可以利用它实现远程代码执行，让运行 curl 的程序执行攻击者指定的代码。

　　当然，它的触发条件也不少。

　　攻击者得摸清 curl 的具体版本、运行环境和内存使用情况，还要卡准多个传输任务同时运行的时机。并不是随便连上一个网站就会中招。

　　从收到报告到发布更新，curl 团队用了 29 天。

　　Anthropic 的公告还引用了 curl 维护者 Daniel Stenberg 的评价：

　　OSS Scanner 帮助他们发现了多个需要处理的问题，其中包括近年来收到报告的最严重漏洞之一。

　　此次 curl 发布的安全公告，已经给出了一个实实在在的修复案例。

　　从收到报告，到确认问题、完成修复，再到发布更新，curl 已经在实际项目中完成了这一闭环。

　　免费查漏洞

　　还告诉你怎么验证、怎么修

　　OSS Scanner 交给维护者的，不只是一条漏洞警报。

　　据 Anthropic 介绍，每份报告包含漏洞解释和可独立运行的复现材料；条件允许时，还会追溯问题由哪次代码改动引入，并附上候选补丁。

　　补丁并不是每份都有，能不能用，也需要维护者检查。

　　其中，复现材料尤其重要。

　　如果只收到一长段分析，开发者还得自己搭环境、试条件，才能判断问题是否存在。有了可运行的复现程序，就能少走一些弯路。

　　Anthropic 公告收录了两位早期测试者的反馈。

　　OpenSSL Corporation 的 Anton Arapov 表示，报告附带能触发漏洞的程序，工程师就能直接验证问题。

　　PostgreSQL 的 Noah Misch 则称，部分补丁几乎可以直接使用；提前收到报告，也帮助团队赶在正式版发布前修复了问题。

　　更多开源项目也可以申请这样的免费扫描，但需要先满足条件：项目需要对基础设施和用户安全有重要影响。

　　核心维护者通过 GitHub 提交项目配置和构建文件后，Anthropic 会核验申请者身份、报告接收人，以及具体扫描哪些代码。

　　系统先在隔离环境中联网完成构建，再断网检查代码，最后通过邮件发送报告。

　　维护者可以随时申请暂停或退出。

　　AI 查漏洞

　　最怕「狼来了」

　　一份报告写得再专业，如果问题根本不存在，维护者花在验证上的时间就白费了。

　　Anthropic 公布的早期抽检结果，给出了一个积极信号。

　　公司邀请了平时为其协调漏洞披露流程审核报告的专业渗透测试人员，检查 48 个项目中的 97 项严重及高危发现，其中 85 项达到披露标准，11 项是真实但重复的问题，只有 1 项无效。

　　另一组反馈来自 wolfSSL。

　　据 Anthropic 公告，wolfSSL 收到 74 份报告，其中 72 份有效，5 项成为 CVE。附带的补丁，也进入了团队原有的验证与修复流程。

　　报告有效，还只是第一关。问题到底有多严重，更要判断准确。

　　Anthropic 承认，有些报告会高估问题的严重程度，或者没搞清项目原本的权限限制。

　　比如，一种操作本来只有管理员才能执行，就不能按普通用户也能利用的情况来评估风险。

　　维护者仍需确认：问题是否存在、是不是新发现、实际影响有多大。

　　少误报，能减少无效排查；评得准，才能优先修复最紧急的问题。

　　找得更快

　　谁来验证？

　　OSS Scanner 的报告由 AI 生成，发送前不经安全专家逐份审核。

　　系统会用智能体复查、分析原因、提出补丁，但维护者仍需确认漏洞、检查补丁、测试改动，才能发布修复。

　　为什么不先让人工审核一遍？

　　Anthropic 称，过去六个月发现超过 2.9 万个候选漏洞，人工只完成约 6000 项审查与分流。候选发现不等于真实漏洞，但缺口已经很明显：

　　AI 不断提交线索，人工验证跟不上了。

　　一些维护者主动要求：没验证的也发来，我们自己看。

　　Anthropic 已按要求发送近 5000 份报告，OSS Scanner 则将这种方式开放给更多项目。

　　缺少处理资源的项目，仍可通过原有协调披露流程，接收人工验证后的报告。

　　这些未经人工验证的自动报告，目前不设「90 天后公开漏洞」的期限，维护者可以根据风险和人手安排验证与修复。

　　如果报告后续通过人工验证、进入正式披露流程，则从通知维护者已验证时起，按相应政策计时。

　　curl 已经完成了一次从报告到修复的流程。

　　接下来，要看这样的成果能否持续出现，相关应用能否及时跟进更新。

　　参考资料：

　　https://www.anthropic.com/research/launching-opt-in-vuln-finding-service-for-open-source?utm_source=chatgpt.com

　　https://curl.se/docs/CVE-2026-92392.html?utm_source=chatgpt.com

　　https://github.com/anthropics/oss-scanner

　　编辑：元宇