一个开源项目每天收到的漏洞报告，超过九成经评估都够不上高危。curl 的维护者决定不再把这些报告藏在私有队列里。
从 2026年10月26日 起，curl 项目调整了漏洞报告的接收路径：被评为 LOW 或 MEDIUM 的报告，直接进入项目的 GitHub 公开 issue 跟踪器；只有 HIGH 和 CRITICAL 级别的报告，继续留在 HackerOne 的私有队列中处理。
curl 是一个开源数据传输工具，libcurl 则是它内部供应用程序调用的库，用来通过网络协议收发数据。这次改动的分界线只有一条——严重程度评级。
九成报告够不上高危
做出这个决定的依据写在公告里。Daniel Stenberg 表示，过去几年里，超过 90% 的提交可以很快被评估为低于 HIGH 级别。这意味着私有队列长期承载着大量被项目判定为轻微的报告。
其中一部分原因在方法上：许多新提交的漏洞是由 AI 模型构造出来的，这些模型生成不寻常的调用序列或选项组合，触发一些意料之外的行为。Stenberg 对媒体表示，这类组合在真实应用中不太可能出现。
工作量的压力也体现在他的措辞里。所有核心维护者都感到紧张、超负荷，已经被逼到能力的边缘，项目明确表示必须采取行动才能维持下去。项目预计这波报告洪流在未来几个月内不会减少。今年早些时候，curl 已经关闭了自己的漏洞赏金计划，原因是 AI 生成的提交给安全团队堆上了大量工作。
公开处理换来更多人手
把报告放进公开跟踪器，等于让同一份报告被更多人看到。有人可以复现崩溃，有人可以就严重程度提出异议，有人可以起草公告文本，也有人能发现修复漏掉了相邻的情况——这些工作都能在版本发布前完成。
Stenberg 还提到，公开流程可以让各个发行版以及 curl 的其他使用者更早、更好地跟上安全修复。他指出了一种让共享变得有用的模式：每当一批新的 CVE 和修复公布，一群使用 AI 的研究者就会把它们丢给模型，去寻找修复中类似的错误或遗漏，把流程搬到公开环境，项目在这类审查上能得到更多帮助。
他对这项改动的边界说得很清楚：每份报告的工作量不变，项目使用的四个严重级别仍然是 LOW、MEDIUM、HIGH 和 CRITICAL。公开处理只是把队列开放给更多能看见它、帮忙消化它的人。
真正的 LOW 问题也不能不管。CVE 项目设有申诉流程，如果 curl 不为一个真实存在的漏洞发放 CVE，别人也会发。
攻击者多出的窗口
公开处理意味着一个缺陷会被所有读 GitHub 的人看见，其中也包括那些会在修复出现之前尝试利用它的人。
Stenberg 直接承认了这一点：这项政策以现有 curl 用户为代价，给了坏人稍微长一点的利用窗口，项目正是出于这个原因，把公开处理限定在低于 HIGH 的级别。
这笔取舍值得说清楚。libcurl 里一个 LOW 或 MEDIUM 的缺陷，对某个具体应用仍然可能要紧，而一个公开 issue 会在修复发布前把它展示给所有关注的人。AI 工具让漏洞报告的生产变得廉价，而判断每一份报告仍然要花和过去一样多的维护者精力——Stenberg 承认，公开处理并没有让这份工作变轻。开放队列，是把判断工作分摊给更多人。
团队该怎么读 curl 公告
先看 curl 从哪来。一个技术栈可能通过发行版软件包、基础镜像或语言运行时拿到 libcurl，这种情况下，真正要跟进的修复会以软件包更新的形式到达。
设想一个 SaaS 团队：它通过发行版锁定 libcurl 版本，每月拉取容器基础镜像。从 10 月 26 日起，可能触及它技术栈的 LOW 和 MEDIUM 报告，会在项目评估期间就出现在 curl 的 GitHub issue 里。关注项目仓库，能让这个团队提前知道哪些函数和选项组合正在引起注意——这正是 Stenberg 所说的、发行版和其他使用者能更早更好跟进修复的含义。
实际要做的事，是把每个公开的 curl issue 对应到承载 libcurl 的软件包或镜像上；这份依赖映射同时也能支撑安全审计和栈本身的加固。读公开 issue 获取暴露面的信号，然后按打包好的修复行动，把私有公告当作仍然需要快速、安静响应的情况。
热门跟贴