如今，仅凭漏洞传闻就足以找到利用方法

我今天发布了 OCaml cohttp 6.3.0 的安全修复，解决了一个路径遍历漏洞。

补丁本身并不复杂。按通常的流程，我本应私下修复问题、通知受影响的用户，然后再公开发布安全公告。但这一次，我在提交修复该问题的 PR几分钟后，就在生产 Web 服务器的日志里发现了针对这一漏洞模式的探测请求。

更糟的是，我发现自己的 agents 只要大致知道漏洞是什么，就能找出利用方法——也就是说，攻击者很可能在公开补丁发布之前，就已经利用了这个漏洞！

既然仅仅是安全问题的传闻，似乎就足以为攻击者提供发现新漏洞利用方式所需的信息，那么我们必须改变开源项目处理安全响应的方式。

1 一个漏洞的传闻，就是全新代理式漏洞利用系统所需的全部信息

上周，这个漏洞报告经由 Jane Street 私下发送到一个 Slack 频道，而它本身也是通过 Claude Fable 发现的。整个时间线因此被大幅压缩……

1.1 一份现代安全报告的时间线

在详细查看补丁之前，我先让自己的 Claude 检查受影响的代码，看看其中是否还潜伏着其他问题（具体要求它调查路径规范化问题）。但由于我无法访问 Glasswing，Fable 的安全限制让它直接拒绝了请求；不过，DeepSeek V4 Pro 倒是帮了我，并独立发现了几个相关问题。我的 agent 还轻而易举地在不到一分钟内生成了一个 exploit，用来探测本地运行中的服务器。

在和漏洞报告者就可能的修复方案来回讨论后，我悄悄地将 cohttp#1145 公开到 让更多人关注。通常这需要几天时间，预计一两周内发布修复版本也算合理。但大约十分钟后（没错，就是十分钟！），这个网站就开始收到针对百分号编码路径遍历序列的探测请求，说明自动化监控程序一直在盯着公开代码仓库。

既然我在本地创建自己的 exploit 只花了一分钟，那么对于自动化攻击来说，十分钟才开始行动其实已经算很久了！只要攻击者持续监控软件包仓库，几秒钟内就可能发起利用。

1.2 安全禁披露期已经失效

传统的安全流程通常会对漏洞实施保密，认为隐藏细节就能保护用户。但如今，自动化代理只需要一个大致的搜索方向，就能自行展开研究。Fang 等人发现，在提供 CVE 描述后，他们的 GPT-4 agent 成功利用了 15 个漏洞基准中的 87%；而不提供描述时，这一比例只有 7%。

两年过去，平均漏洞利用时间已经是 -7 天。换句话说，如今漏洞利用甚至早于补丁发布！同一指标在 2018—2019 年大约还是 63 天，2024 年则跌破了零点。现在随便搜索一下，就能找到许多类似案例……marimo 的 CVE-2026-39987 从发布安全公告到首次利用尝试只用了 9 个小时，而且当时甚至没有公开的概念验证代码。Langflow 的 CVE-2026-33017 也只用了 20 个小时。看来，我们已经越过了自动生成 exploit 的临界点……

2 如今，bugonomics 是否正在对 OSS 维护者不利？

在我看来，我们的安全流程或许需要彻底调整方向：只要有一个人开始查找某类问题（可能是邮件列表中的一个提问、孤立分支里一条奇怪的提交，或者一次上下文泄露），就足以提醒另一个人的智能体，让它生成漏洞利用代码。这太离谱了。

2026 年 5 月的一篇论文提出了“bugonomics”这一术语，并指出瓶颈已经转移到了“防御方的修复吞吐能力”。LLM 正在轻松生成漏洞利用代码，但我们的防御能力未必同步提升——维护者验证、分类处理和发布修复版本的速度依然没有改善。作为一名 OSS 维护者，这种判断与我的实际感受不谋而合：

问题不在于 frontier models、开放权重模型或程序分析谁会“胜出”，而在于如何协调利用它们，让有限的验证、优先级排序和发布资源投入到持久性的修复上，而不是机械地搜索问题和起草报告。对防御方而言，一个重要机会在于修复技术债：构建以语义为基础、经过工具验证、由模型辅助的工作流，帮助维护者在安全缺陷演变成明日的可利用漏洞之前，及时发现、验证、排序并修复它们。 -- 《揭开 Mythos 的神秘面纱，还是打破 bugonomics？》，Pesoli 等，2026 年

那为什么维护者的能力一直没有提升？原因之一显然是他们无法使用 Mythos 这样的 frontier agent；但除此之外，要设计一个不会引入任何回归问题的安全补丁，本身就需要更多工程工作。

3 那我们到底能拿这事怎么办？

我们显然需要尽快调整应对方式。我不认为现有的人工分流流程应该消失，但自 Fable 发布以来，活动量已经激增到难以持续的程度。我们才刚开始弄清楚这股涌入的信息流中有多少是机器生成的，但显然占比很高。

Google 这类大型工程公司一直在软件中直接加入微更新机制，优先确保修复能够直接触达用户，而不是先在 Chrome 代码仓库中完成修复。Docker 或 OCaml 没有这种条件，因为我们无法控制软件运行的终端。除了 Docker Desktop 外，下游发行版完全有理由按照自己的节奏和规则重新打包 OSS。

对于 OCaml 这样的小型项目来说，仅仅获得前沿模型的使用权限都很困难。西方开发的模型都设有安全防护，因此我们无法使用市面上可以买到的那些模型。Project Glasswing 已经扩展到覆盖 15 个国家的 150 家机构，其中包括关键基础设施运营商、云服务商和金融服务商，以及 Linux Foundation，但普通的小型维护者仍然无权使用。今年 4 月时我还不确定这是否有害，但如今很明显，事情的发展结果相当糟糕。

3.1 超级机密的私下补丁开发

第一种补救办法，是在完全避开 AI 的私密环境中开发修复补丁。GitHub 的临时私有 Fork原则上可以做到这一点，但对我们来说效果并不理想。

首先，GitHub 对临时私有 fork 做了限制，理由是“为了确保漏洞信息安全，包括 CI 在内的集成服务无法访问临时私有 fork”。这会立刻切断维护者获取 CI 结果这一关键信息来源。其次，一个 fork 只能合并单个 PR，而漏洞往往涉及多个仓库，这种限制很不实用。评审者也必须由管理员逐一添加；但在开源项目中，评审通常取决于当时谁有空，很多人都是临时参与进来的——尤其是八月！

不过从更广泛的角度看，这解决的并不是最需要堵住的漏洞。相比确保问题描述只传达给准确的目标人群、不给攻击者留下任何线索，让补丁本身保持秘密其实没那么重要。

开源生态缺乏成熟的讨论基础设施：相关讨论分散在各种端到端加密平台上（我们使用 Matrix），也分散在 Discord、Slack 这类共享基础设施中，而后者的信息泄露风险很高。我们确实需要某种信任网络，以便在特定项目环境中区分可信参与者和恶意参与者。

3.2 不设禁运期，持续发布

另一种做法是公开快速修复问题，持续发布，并通过更完善的自动化改进发布流程。

Chrome 等大型项目已经证明这条路可行：每周发布安全更新，每周发布两个版本（没错，是两个！），还支持动态打补丁，无需重启就能用更新后的二进制文件替换后台进程。这并不是什么全新的技术；15 多年前，我就研究过将Linux 的 Ksplice 热补丁与 Xen 集成。Linux 内核也会尽快发布修复，通常最多延后七天，特殊情况下延后十四天。

不过，软件打包是我们面临的主要障碍。Chrome 只需发布一个二进制产物，相对容易；而 OSS 往往由一组库组成，这些库随后会被嵌入各种下游产品。因此，要实现这一点，我们需要：

• 更完善的跨生态包管理，用于发现不同库最终被嵌入到哪些地方。Ryan Gibb 将在下周的 ICFP 大会上介绍这一主题！
• 更好的扫描工具，帮助进行问题分流。过去几个月里，Andrew Nesbitt 一直在用 Scrutineer 做这件事。Thomas Gazagnaire 和我也在讨论，是否要把这套方法用于我们的 OCaml 代码，前提是能够使用一个足够强大、且没有安全限制的前沿模型。
• 更稳健的质量控制基础设施，能够覆盖所有受支持的平台，同时不产生误报。在 Linux 上运行 CI 相对容易，但在 OpenBSD、FreeBSD、macOS，以及 RISC-V 等架构上，情况就完全不同了。

3.3 在协议层主动防护

我还在认真思考，能否动态注入更激进的防护措施，保护使用我们库的各个端点。如果我们承认上游补丁总会落后于漏洞利用，那么必须采取更快的手段，抢在攻击者前面。

例如，今天修复的这个 cohttp 漏洞，就有一个很简单的缓解办法：统一规范化请求 URL 中经过百分号编码的路径分隔符。漏洞报告一到，这条规则就可以立即实现；在完整修复方案完成评审、测试和打包之前，也可以先行部署。如今，在云基础设施上进行虚拟补丁已经是常规做法；早在 2021 年，Cloudflare 就通过部署托管规则，及时堵住了 Log4shell。

但在商业 CDN 之外，开源生态缺少分发这类规则的机制。我们在互联网生态论文中提出的antibotty 网络，正是想通过在全球互联网中推动更丰富的软件多样性来填补这一空白。我们能否建立一种本地化、快速传播的防御机制：一旦得知漏洞，就能在几秒内对自身所在的基础设施采取行动？

4 后续研究方向

我认为，短期内可能需要把这三种方案结合起来：为 OSS 贡献者建立一个轻量级的信任网络（类似昔日的 Advogato），同时更加重视 OSS 打包，以及持续发布和问题分诊机制，避免压垮我们宝贵的人力资源。

我还为下个月即将入读 Cambridge、正在寻找研究项目的人发布了几个新的 MPhil 研究方向。

• “用于保护网络服务的 antibotty 防御测试平台”会在家庭网络前部署一个 MirageOS 网关，研究一组缓解规则是否足够可信，能够自动部署。我们还可以设计一个有趣的夺旗游戏：把同一条传闻分别提供给攻击代理和防御代理，看看哪一方能率先采取行动。
• “将 Lean 规约编译为 OxCaml 强制执行自动机”使用Dijkstra monads，定义一个库在文件系统、解析器和网络层面可以执行哪些操作，然后将这份 Lean 规约编译成 OxCaml 自动机，在运行时强制执行。这是我博士期间构建的statecall automata的现代版本。

如果 Project Glasswing 的哪位同仁看到了这段话，OCaml 团队现在就需要访问权限了 :-)

（cohttp 的修复并非一人之功。Sapphire Livingstone 发现并报告了这个问题，指导修复工作并参与制定补救方案；Michael Dales、Török Edwin 和 Patrick Ferris 审查了补丁；Hannes Mehnert 负责协调安全公告；Thomas Gazagnaire 则一直在思考更广泛的分诊问题。感谢大家！漏洞经济学或许对我们不利，但我们终会跨过这道坎。）