curl 2026 年 7 月暂停漏洞报告：开源安全值班表写不下去了

curl 做了一个很少见、也很不含糊的决定：2026 年 7 月，它暂停接收和处理漏洞报告。

这不是停止维护。普通 GitHub issue 和 PR 仍然开放。真正关掉的是安全漏洞这条通道：HackerOne 表单暂停，安全邮箱也不处理。对依赖 curl 的安全团队来说，7 月不能再默认“上游随时响应”。

7 月暂停的到底是哪条通道

时间点写得很硬：2026 年 7 月 1 日 00:00 CEST 开始，8 月 3 日 09:00 CEST 恢复。

项目方给出的原因也很直接：过去约四个月，漏洞报告压力巨大，而且他们不预期这波压力会很快结束。

这张表能挡掉一个误读：curl 没有“停摆”，也没有宣布不修 bug。它暂停的是漏洞报告处理，不是整个项目运转。

另一个边界也要说清。材料没有显示 curl 已经遭遇重大攻击，也没有显示项目出现财务危机。把这件事写成“安全事故前兆”，证据不够。

真正受影响的，是两类人。

一类是企业安全团队。7 月如果要提交 curl 相关漏洞，公共通道不会按平时节奏处理。内部风险登记、供应商沟通、版本升级计划，都要把这个窗口期算进去。

另一类是把开源基础设施当免费安全兜底的人。以前可以含糊过去：反正上游会看。7 月不行。你要么有合同，要么自己承担等待成本。

关键变量不是休假，是谁来买确定性

安全响应不是普通 issue triage。

它要判断影响范围，要复现，要沟通披露节奏，要准备修复，还要过滤误报、重复报告和赏金激励带来的噪音。过去四个月的“巨大压力”，放在开源维护语境里，已经不是一句客气话。

我更在意的是，curl 这次没有把话说成公关稿。它没有说“优化流程”“提升体验”。它直接划线：公共漏洞通道暂停，付费支持照常。

这条线有点刺眼，但很诚实。

很多公司对开源的期待，本质上是用社区关系买企业级确定性。平时叫生态，出事叫供应链，真正要排班、响应、兜底时，又希望维护者继续靠热爱顶住。

“天下熙熙，皆为利来。”漏洞报告生态也一样。安全研究、赏金平台、企业合规、下游厂商，都有自己的激励。维护者常常站在最后一环：别人提交，别人催进度，最后由他们把碎片收拾成修复。

这不是道德问题，是激励设计问题。

如果一个组织真的需要确定响应，就该在 7 月前做几件很具体的事：

• 盘点哪些系统直接或间接依赖 curl，不要只看应用层依赖。
• 把 2026 年 7 月列为上游安全响应受限窗口，内部 SLA 不要写得比上游更乐观。
• 对强依赖 curl 的产品线，评估是否需要付费支持合同，或者准备自己的缓解和回滚方案。
• 安全团队如果计划在 7 月提交报告，最好调整节奏；不能假设 HackerOne 或安全邮箱有人接单。

这不是让所有人立刻买服务。很多团队不需要商业支持，也没必要为每个开源组件上保险。

但如果你的业务承诺里写着“快速安全响应”，又把关键组件的响应成本全部压给上游志愿维护者，那就是账没算完。

接下来只看两个信号

第一个信号，是 8 月 3 日恢复后，积压报告会不会迅速淹没维护者。

如果恢复后压力继续堆高，说明这不是一次暑期休整能解决的问题。curl 可能还要继续调整漏洞报告流程、披露节奏，甚至更明确地区分社区通道和商业通道。

第二个信号，是企业用户会不会把这件事写进自己的供应链安全流程。

真正成熟的做法，不是发一封邮件催上游，也不是在社交媒体上抱怨开源项目不负责。成熟做法是承认现实约束：关键依赖要有清单，响应窗口要有预案，付费服务要和业务风险匹配。

这里可以拿 OpenSSL 的 Heartbleed 做一个很短的对照。情况不完全一样，curl 这次也没有已知重大漏洞。但两件事暴露的是同一种结构：全球都在用的基础组件，背后不一定有足够的人手和预算。

十多年过去，行业学会了说“开源供应链安全”，但很多组织还没学会付钱、排班、分责。

坏人不会因为 7 月到了就休息。curl 当然知道这一点。它这次做的，不是把风险变没，而是把风险从维护者个人身上挪回使用链条里。

这才是最不舒服、也最有价值的地方。

开源基础设施不是公共设施的免费值班室。你可以免费使用，但不能默认有人永远替你守夜。curl 这块暂停牌，挂在 2026 年 7 月，也挂在整个开源安全生态的账本上。