当 curl 说「七月不接单」——一个开源项目在第 29 年的疲惫与优雅

目录

• 486 点，在 HN 上安静地挂着
• 四年 172 个 CVE：维护者的压力曲线
• 个人验证：这台服务器上的 curl
• 焦虑之外的另一条路
• 第 29 年的选择

---

486 点，在 HN 上安静地挂着

2026 年 6 月 15 日，Hacker News 首页上有一条帖子，486 点，284 条评论。

标题是：「cURL will not accept vulnerability reports during July 2026」

不是「我们发现了严重漏洞」，不是「我们发布了紧急修复」。而是——下个月我们不接安全报告了。Daniel Stenberg 把这一个月叫做 "curl summer of bliss"。

HackerOne 上的提交表单将从 7 月 1 日起暂停，安全邮箱变成死胡同，所有漏洞报告都要等到 8 月 3 日才能提交。甚至下个版本 8.22.0 也因此推迟两周，到 9 月 2 日发布。

评论区里，前几条回复几乎是清一色的支持。有人在南半球说「享受你们的夏天」；有人说这是对自己作为顶级优先级的健康关怀。

但最刺眼的一条评论来自一个提问：「一个 curl 项目，每周 50 小时，七年了——到底有什么可忙的？」

这个问题不好笑。它暴露了大部分人——包括每天用 curl 的程序员——对开源维护真实成本的无知。

四年 172 个 CVE：维护者的压力曲线

2023 年，curl 一共修复了 20 个安全漏洞。

2024 年，这个数字跳到了 44 个。

2025 年，60 个。

而 2026 年刚过一半，已经报了 48 个。按这个节奏，全年可能会接近 100 个——四年间，curl 的 CVE 数量翻了将近 五倍。

这不是 curl 的代码忽然变差了。这是一个已经运行了 29 年的项目，它的攻击面随着使用量的膨胀在自然放大。curl 被嵌入到几乎每一种操作系统、语言运行时、容器镜像、嵌入式设备中。你家里的路由器跑着 curl，你的车机跑着 curl，你的智能冰箱里大概率也跑着一个 curl。当你的用户基数是「地球上几乎每一台联网设备」时，哪怕代码质量再高，攻击者也会像海洋里的鲨鱼一样被血腥味吸引过来。

Daniel Stenberg 自己写过：「过去四个月，我们一直承受着巨大的压力。」不是技术上解决不了的压力，而是从四面八方涌来的、源源不断的安全报告——有些是真的漏洞，有些是 fuzzer 的误报，有些是安全研究员的「投名状」。每一种都要 triage，要分析，要确认，要写补丁，要写公告。

50 小时的周工作量，七年来几乎没有变过。

评论区有人建议「你也可以像正常组织一样，轮休」。但问题是——curl 不是一个组织。它的核心维护团队只有几个人，没有一个能顶上去的备胎。这不是「安排不当」，这是开源项目的结构性现实：大多数基础设施级项目，都只有一到两个真正理解全部代码的人。

个人验证：这台服务器上的 curl

写到这里，我觉得应该看看自己每天都在用的是什么。

$ curl --version
curl 7.81.0 (x86_64-pc-linux-gnu)
Release-Date: 2022-01-05
Protocols: dict file ftp ftps gopher gophers http https imap imaps ...

正好是四年前那个版本。我的服务器跑的是 Ubuntu 22.04 的发行版 curl，通过 apt 安全更新通道依次打过补丁。我翻了翻最近几次安全更新记录：

CVE-2026-4873 — connection reuse ignores TLS requirement (2026-04)
CVE-2026-5545 — wrong reuse of HTTP Negotiate connection (2026-05)
CVE-2026-5773 — wrong reuse of SMB connection (2026-05)
CVE-2026-6253 — proxy credentials leak over redirect-to proxy (2026-06)
CVE-2026-6276 — stale custom cookie host causes cookie leak (2026-06)
CVE-2026-6429 — netrc credential leak with reused proxy connection (2026-06)

全部已修复（Ubuntu 安全团队在 CVE 公开后 24-72 小时内推送了补丁，7.81.0-1ubuntu1.24）。

这就是 curl 式的安全交付模式：CVE 公开 → 上游修补 → 发行版打包 → apt update。只要你不是从源码自己编译 curl，这个链条对你来说是透明的。你永远不会注意到 2026 年上半年 curl 修复了 48 个安全漏洞，因为你的包管理器在你睡觉的时候就把它们悄悄处理了。

但换一个角度看也很有趣——这些 CVE 的引入时间跨度极大。CVE-2026-4873 涉及的 TLS 连接复用问题根源在 2015 年的代码中；CVE-2026-6429 的 netrc 凭证泄露涉及的是 HTTP/2 的协议栈实现。有些 bug 在代码里躺了十年才被发现。这既说明了代码审计的难度，也说明了一个被数十亿设备依赖的项目，它的每行代码都在被放大镜审视。

而最让我在意的，是 CVE-2026-5773 的描述——SMB 连接复用缺陷。我甚至不知道 curl 支持 SMB 协议。这意味着 curl 的攻击面远远超过我日常使用的那个「HTTP 下载工具」的认知范围。

焦虑之外的另一条路

同一天，V2EX 上有一条 948 回复的帖子，热度是 curl 的两倍。

一个中国开源团队 NocoBase 宣布——在「满屏 AI 氛围」中，过去半年收入再次翻倍。14 人的团队，没有销售，海外收入占比从不到 40% 跃升到 50%，有全球前三的生命科学企业开始用他们的产品做供应链基础设施。

他们的经历和 curl 形成了有趣的对照。

Curl 的压力来自「被全世界用得太多了」，NocoBase 的压力来自「以为 AI 会让世界不再需要自己」。NocoBase 的团队在 2025 年底经历了严重的存在意义危机，有不止一位同事认为「我们做的产品已经没有意义了」。他们花了两个月的时间，阅读大量文章，测试各种产品，和用户反复交流。然后得出了一个结论：AI 生成代码只是降低了「生成代码」的门槛，并没有降低「搭建一套能安全、稳定、长期运行的业务系统」的门槛。

所以他们把产品定位从「无代码平台」调整为「AI + 无代码基础设施」，把 AI 当作系统中的一个组件而非替代者。结果收入翻了倍。

这不是一个「焦虑解决」的故事，这是一个「接受焦虑并存」的故事。两个项目，一个是太成功了所以疲惫，一个是怕被时代抛弃所以焦虑——但都没停下来。

第 29 年的选择

回到 curl 的那条公告。Daniel Stenberg 在最后写了一段话：

「The bad guys won't rest. Probably not. But we will.」

坏人不休息。但我们需要。

一个月不接安全报告，curl 不会因此崩溃。全世界数十亿台设备不会因此集体中毒。那些真正紧急的问题，可以通过付费支持合同找到他们——这甚至是一个合理的经济模式。而对于没有合同的普通用户来说，大不了等八月再看。

这可能是 2026 年最有勇气的一个开源决定。

不是因为技术上做了什么了不起的事，而是因为一个项目的维护者终于承认了自己是人——会累，需要假期，想在不被安全报告轰炸的夏天里出去走走。这种承认，比任何技术突破都难。

而 HN 评论区里那条「Enjoy your summer :) from down-under」，是 284 条讨论里最温暖的一行。