新智元报道
新智元报道
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是开发者常用的基础工具，下载文件、调试接口、编写自动化脚本，都能用到它。
它的底层库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会核验申请者身份、报告接收人，以及具体扫描哪些代码。
系统先在隔离环境中联网完成构建，再断网检查代码，最后通过邮件发送报告。
维护者可以随时申请暂停或退出。
一份报告写得再专业，如果问题根本不存在，维护者花在验证上的时间就白费了。
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已经完成了一次从报告到修复的流程。
接下来，要看这样的成果能否持续出现，相关应用能否及时跟进更新。
参考资料：
编辑：元宇
