Just a rumour of a bug is enough to find a security exploit these days
- ID: c7ae024c
- 原文链接: https://anil.recoil.org/notes/rumour-is-the-exploit
- 作者: Anil Madhavapeddy
- 日期: 2026-08-22
- 分类: infra
- 来源类型: article
- 标签: security, open-source, agentic-exploits, vulnerability-disclosure
- 质量评分: 4/5
- 抓取时间: 2026-08-29T23:47:00+08:00
中文导读
Cambridge 教授、OCaml cohttp 维护者 Anil Madhavapeddy 披露：为修复路径遍历漏洞（OSEC-2026-16）公开 PR 后约 10 分钟，自己的服务器日志就出现针对该漏洞模式的探测。只需"漏洞的粗略传闻"就够借 Agent 找到可用 exploit：他复现时 Claude Fable 因安全策略拒接，DeepSeek V4 Pro 一分钟内独立找到相关并造出本地探测用 exploit；报告本身也是 Jane Street 用 Claude Fable 发现的，整条时间线被压缩。rclone 维护者 Nick Craig-Wood 在 HN 评论区补充：rclone 头十年约 20 份安全披露、过去一个月就来了 40 多份（他用 AI triage，75% 有效），CVE 分配从 2-3 天拖到 3-4 周，只能先发带 CVE-PENDING 的 changelog。判断：开源"私下修复→同步披露"流程被 agent 速度撞穿，披露窗口需要重新设计，否则下一个挨打的是核心依赖
原文摘录（节选）
摘录来源：opencli web read 全文抓取
# Just a rumour of a bug is enough to find a security exploit these days
> 作者: Anil Madhavapeddy
> 发布时间: 2026-08-22
> 原文链接: https://anil.recoil.org/notes/rumour-is-the-exploit
---
I released a security fix for OCaml's [cohttp 6.3.0](https://discuss.ocaml.org/t/cohttp-6-3-0-released-osec-2026-16/18467) today, fixing a [path traversal issue](https://osv.dev/vulnerability/OSEC-2026-16). 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. 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](https://github.com/mirage/ocaml-cohttp/pull/1145).
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! 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) The rumour of a bug is all new agentic exploit systems need
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...
### [1.1](#the-timeline-of-a-modern-security-report) The timeline of a modern security report
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](https://www.anthropic.com/glasswing), but [DeepSeek V4 Pro](https://anil.recoil.org/notes/language-integrated-llms)1 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.
1. [Language integrated LLMs as an OCaml function](https://anil.recoil.org/notes/language-integrated-llms) · 2026 · 3212w
After some back and forth with the bug reporter about possible fixes, I quietly opened [cohttp#1145](https://github.com/mirage/ocaml-cohttp/pull/1145) publicly to [get more eyes](https://anil.recoil.org/notes/2026w33)2 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.
2. [.plan-26-33: Zarro rides out and evidence papers pour in](https://anil.recoil.org/notes/2026w33) · 2026 · 2209w
If it took me just a minute to create my own exploit locally, then [ten minutes actually seems quite long](https://www.icir.org/vern/papers/cdc-usenix-sec02/) 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) Security embargoes are no longer effective
Conventional security process involves [embargoing](https://www.redhat.com/en/blog/Understanding-security-embargoes-at-Red-Hat) 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.](https://arxiv.org/abs/2404.08144) found that when given a CVE description, their GPT-4 agent [exploited 87%](https://surrealyz.github.io/classes/llmsec-fall24/slides/14-agents-exploit-vulnerabilities.pdf) of a 15-vulnerability benchmark, and without the description, just 7%.
Two years on, the [mean time to exploit](https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026) 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. A quick search finds lots of other similar cases these days... marimo's [CVE-2026-39987](https://www.sysdig.com/blog/marimo-oss-python-notebook-rce-from-disclosure-to-exploitation-in-under-10-hours) went from advisory to first exploitation attempt in 9 hours, even with no public proof-of-concept in existence. Langflow's [CVE-2026-33017](https://www.sysdig.com/blog/cve-2026-33017-how-attackers-compromised-langflow-ai-pipelines-in-20-hours) took 20 hours. We seem to have crossed the rubicon for automated exploit generation...
[](https://www.vulncheck.com/blog/state-of-exploitation-1h-2026)
[")
The state of LLM exploitation in 2026 (source: Vulncheck)
](https://www.vulncheck.com/blog/state-of-exploitation-1h-2026)
[](https://www.vulncheck.com/blog/state-of-exploitation-1h-2026)
## [2](#are-the-bugonomics-against-oss-maintainers-now) Are the bugonomics against OSS maintainers now?
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](https://arxiv.org/abs/2605.24632)" 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. 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本文由 daily-intake-evening 流水线于 2026-08-29 归档；摘录为原文节选，全文见原文链接。