Just the rumour of a bug is enough to find an exploit these days
Just the rumour of a bug is enough to find an exploit these days
如今，仅仅是关于漏洞的传言就足以被用来寻找攻击利用
I released a security fix for OCaml’s cohttp 6.3.0 today, fixing a path traversal issue. The patch itself was straightforward and in normal times, the security procedure would have been to fix it privately, inform affected users, and then issue a public advisory. 今天，我为 OCaml 的 cohttp 6.3.0 发布了一个安全补丁，修复了一个路径遍历漏洞。补丁本身很简单，按照常规的安全流程，我们本应私下修复它，通知受影响的用户，然后再发布公开公告。
This time around though, I noticed probes in my live webserver logs with the exact bug pattern just minutes after opening the PR to fix the issue. What’s worse, I found I could use my own agents to find the exploit just by knowing roughly what it was about and so could have been exploiting it well before the public patch was available! 然而这一次，在提交修复 PR 后仅几分钟，我就在实时 Web 服务器日志中发现了针对该漏洞模式的探测行为。更糟糕的是，我发现只要大致了解漏洞内容，我就可以利用自己的 AI 代理找到攻击方法，这意味着在公开补丁发布之前，该漏洞就已经可以被利用了！
Given that just the rumour of a security issue seems enough to give attackers enough info to find new exploits, we’re going to need to change the way we deal with security responses in open source. 鉴于仅仅是关于安全问题的传言似乎就足以让攻击者获得足够的信息来寻找新的利用方式，我们需要改变开源社区处理安全响应的方式。
1 The rumour of a bug is all new agentic exploit systems need
1 漏洞传言正是新型代理式攻击系统所需要的全部
This particular report arrived privately on a Slack channel via Jane Street last week, and was itself found via Claude Fable. That compresses all timelines considerably… 这份报告上周通过 Jane Street 的 Slack 频道私下送达，而它本身就是通过 Claude Fable 发现的。这极大地压缩了所有的时间线……
1.1 The timeline of a modern security report
1.1 现代安全报告的时间线
Before examining the patch in detail, I pointed my own Claude at the affected code to see what else was lurking (asking it to investigate path normalisation issues). Fable frustratingly refused outright due to its security block since I don’t have access to Glasswing, but DeepSeek V4 Pro obliged me and independently turned up several related issues. My agent also trivially created an exploit to probe a local live server in under a minute. 在详细检查补丁之前，我让自己的 Claude 指向受影响的代码，看看还有什么隐患（要求它调查路径规范化问题）。令人沮丧的是，由于我没有 Glasswing 的访问权限，Fable 因安全拦截直接拒绝了，但 DeepSeek V4 Pro 满足了我的要求，并独立发现了几个相关问题。我的代理还在不到一分钟的时间内就轻松创建了一个用于探测本地实时服务器的攻击脚本。
After some back and forth with the bug reporter about possible fixes, I quietly opened cohttp#1145 publicly to get more eyes on it. This normally takes a few days and a release within a week or two is reasonable. Within about ten minutes (!) this website was fielding probes for percent-encoded traversal sequences, indicating that automated watchers are keeping an eye on public repositories. 在与漏洞报告者就可能的修复方案进行了一些沟通后，我悄悄公开了 cohttp#1145 以寻求更多关注。这通常需要几天时间，在一两周内发布版本是合理的。但在大约十分钟（！）内，该网站就开始收到针对百分号编码遍历序列的探测，这表明自动化监控程序正在密切关注公共代码仓库。
If it took me just a minute to create my own exploit locally, then ten minutes actually seems quite long for an automated attack window to start! A determined attacker who is monitoring package repositories could easily be exploiting them within seconds. 如果我只需一分钟就能在本地创建攻击脚本，那么十分钟对于自动化攻击窗口来说其实已经算很长了！一个有决心的攻击者如果正在监控软件包仓库，完全可以在几秒钟内发起攻击。
1.2 Security embargoes are no longer effective
1.2 安全禁令已不再有效
Conventional security process involves embargoing the bug, and assumes that secrecy of the details protects users. However, all an agent needs today is a broad direction to search in, and it can do its own research. 传统的安全流程涉及对漏洞进行禁令封锁，并假设细节的保密可以保护用户。然而，如今代理程序只需要一个大致的搜索方向，就能自行完成研究。
Fang et al. found that when given a CVE description, their GPT-4 agent exploited 87% of a 15-vulnerability benchmark, and without the description, just 7%. Two years on, the mean time to exploit is -7 days. In other words, exploitation now precedes the patch! That same metric looks to be around 63 days in 2018-19, and crossed zero in 2024. Fang 等人发现，在给定 CVE 描述的情况下，他们的 GPT-4 代理成功利用了 15 个漏洞基准测试中的 87%，而没有描述时仅为 7%。两年过去了，平均利用时间变成了 -7 天。换句话说，攻击利用现在发生在补丁之前！这一指标在 2018-19 年约为 63 天，并在 2024 年跨过了零点。
A quick search finds lots of other similar cases these days… marimo’s CVE-2026-39987 went from advisory to first exploitation attempt in 9 hours, even with no public proof-of-concept in existence. Langflow’s CVE-2026-33017 took 20 hours. We seem to have crossed the rubicon for automated exploit generation… 快速搜索一下，如今有很多类似的案例……marimo 的 CVE-2026-39987 从发布公告到首次被尝试利用仅用了 9 小时，尽管当时并没有公开的概念验证（PoC）。Langflow 的 CVE-2026-33017 用了 20 小时。我们似乎已经跨越了自动化漏洞利用生成的卢比孔河……
2 Are the bugonomics against OSS maintainers now?
2 “漏洞经济学”现在是否对开源维护者不利？
It looks to me like our security processes need to invert somewhat, since just one person searching for the issue class (this could be a mailing list question, an odd commit in an orphan branch, or a context leak) is sufficient to alert someone else’s agent and let them get exploit code. This is wild. 在我看来，我们的安全流程需要进行某种程度的倒置，因为仅仅是一个人搜索该类问题（这可能是一个邮件列表提问、孤立分支中的一个奇怪提交，或上下文泄露）就足以触发他人的代理程序并获取攻击代码。这太疯狂了。
A May 2026 paper coined the term “bugonomics” and argues that the bottleneck has moved to “defender remediation throughput”. LLMs are merrily generating exploits, but our ability to defend against them isn’t necessarily improving as maintainer validation, triage and release rates stay flat. 2026 年 5 月的一篇论文创造了“漏洞经济学”（bugonomics）一词，并指出瓶颈已经转移到了“防御者的修复吞吐量”上。大语言模型正在欢快地生成攻击利用，但由于维护者的验证、分类和发布速度保持不变，我们防御它们的能力并没有必然提高。
This unfortunately matches the view from my OSS maintainer’s chair: The question is not whether frontier models, open-weight models, or program analysis “win”. The question is how to orchestrate them so that scarce validation, prioritization, and release capacity goes toward durable fixes rather than mechanical search and report drafting. 不幸的是，这与我作为开源维护者的视角相吻合：问题不在于前沿模型、开放权重模型或程序分析谁会“赢”。问题在于如何协调它们，以便将稀缺的验证、优先级排序和发布能力用于持久的修复，而不是机械的搜索和报告撰写。
— Demystifying the Mythos or Disrupting Bugonomics?, Pesoli et al, 2026 ——《揭秘 Mythos 或颠覆漏洞经济学？》，Pesoli 等人，2026
And why are maintainer capabilities staying flat? Well, not having access to frontier agents like Mythos is an obvious one, but also that the engineering of a security patch that doesn’t cause any regressions is just fundamentally more work. 为什么维护者的能力停滞不前？嗯，无法访问像 Mythos 这样的前沿代理是一个显而易见的原因，但另一个原因是，编写一个不会导致任何回归问题的安全补丁，从根本上来说需要更多的工作量。
3 So what the hell can we do about this?
3 那么，我们到底该怎么办？
We clearly need to adapt fairly quickly. I don’t think the current manual triage process should disappear, but I have seen an unsustainable surge of activity since Fable came out. We are only just beginning to get a handle on how much of the incoming firehose is machine-generated, but it’s obviously a lot. 我们显然需要相当迅速地适应。我不认为目前的手动分类流程应该消失，但自从 Fable 发布以来，我看到了不可持续的活动激增。我们才刚刚开始了解涌入的信息流中有多少是机器生成的，但显然数量巨大。
The big engineering shops (like Google) have been building microupdates directly into their software to ensure that fixes directly reach users as a priority over (e.g.) being fixed in the Chrome code repository. We don’t really have that kind of luxury in Docker or OCaml, as we don’t control the endpoints our software is used in. 大型工程公司（如 Google）一直在将微更新直接构建到其软件中，以确保修复程序优先直接到达用户手中，而不是（例如）仅仅在 Chrome 代码仓库中修复。我们在 Docker 或 OCaml 中并没有这种奢侈，因为我们无法控制软件所使用的终端。
Aside from Docker Desktop, downstream distributions quite rightly repackage OSS on their own timescales and terms. For smaller projects like OCaml, just gaining access to the frontier models is a struggle. The Western models have security guards in place which mean that we can’t use the commercially available ones. Project Glasswing has expanded to 150 organisations across 15 countries including critical infrastructure operators, cloud and financial providers, the Linux Foundation, but ‘mom and pop’ maintainers still don’t have access. 除了 Docker Desktop 之外，下游发行版理所当然地按照自己的时间表和条款重新打包开源软件。对于像 OCaml 这样的小型项目，仅仅获得前沿模型的访问权限都是一种挣扎。西方模型设有安全护栏，这意味着我们无法使用商业可用的模型。Glasswing 项目已扩展到 15 个国家的 150 个组织，包括关键基础设施运营商、云和金融提供商、Linux 基金会，但“夫妻店”式的维护者仍然无法获得访问权限。