Just a rumour of a bug is enough to find a security exploit these days
Raw 生命周期：本地全文已降级为可恢复索引；精确引用时从 canonical URL 回到原文核验。
Anil Madhavapeddy 的个人实证与方案讨论（2026-08-22）。文章围绕 OCaml cohttp 6.3.0 的路径遍历修复展开：作者在公开 PR 后约十分钟观察到对应探测请求，并用 Agent 在不到一分钟内构造了本地 exploit。文中同时引用 GPT-4 漏洞利用基准、M-Trends 的 mean time to exploit，以及 marimo、Langflow 的披露案例；这些外部数字均应回到原文链接和各自研究核验。
编译摘要
1. 浓缩
- 核心结论1：安全问题的粗粒度传言，可能已经足以启动自动化 exploit 搜索。
- 关键证据：作者在公开 cohttp 修复 PR 后约十分钟看到 percent-encoded traversal 探测；他让 Agent 只按“path normalisation”这一大致方向检查代码，并在不到一分钟内生成了可探测本地服务的 exploit。文章还引用一项 15 个漏洞的基准：给出 CVE 描述时 GPT-4 Agent 利用 87%，不给描述时为 7%。
- 核心结论2：攻防瓶颈正在从“能不能找到 exploit”转向“防守方能多快验证、修复、打包和发布”。
- 关键证据：文章借用 2026 年提出的 “bugonomics” 说法，指出模型生成 exploit 的速度在上升，而维护者的验证、分诊、无回归修复和下游发布能力没有同步增长；开源库还要面对多生态嵌入和多平台质量控制。
- 核心结论3：安全响应需要把重点从延长保密期，转向降低修复与缓解到达端点的延迟。
- 关键证据：文章提出三类并行方向：更私密且可信的漏洞讨论基础设施、连续快速发布完整修复、以及先在协议/端点层分发可验证的 virtual patch，再等待完整修复通过 review、测试和 packaging。
2. 质疑
- 关于“传言足够”的质疑：公开 PR 后出现探测与作者的本地 Agent 演示，说明风险机制可行，但不能单独证明探测请求一定由 Agent 触发，也不能推出所有漏洞只靠模糊线索就能利用。
- 关于利用率与时间指标的质疑：87% 对 7% 的基准只有 15 个漏洞，且来自较早模型与特定任务设置；mean time to exploit 为负的行业指标与 marimo、Langflow 个案也不能直接当作所有 OSS 的统一基线。
- 关于“无 embargo、持续发布”的质疑：快速公开修复可能扩大短期暴露面；连续发布只有在回归测试、跨平台 CI、依赖追踪和下游分发足够可靠时才成立，否则会把攻击窗口换成错误修复窗口。
- 关于可访问性的质疑：文章指出小型 OSS 项目缺少 frontier Agent 访问权限，但开放更强的漏洞搜索能力也会提高滥用风险；谁能获得模型、谁负责审计和谁承担误报成本，仍是制度约束而非单纯工具问题。
3. 对标
- 与 Cybersecurity-Proof-of-Work 对标：此前的成本模型关注攻防双方为发现漏洞投入多少 token；本文补上时间维度：攻击搜索成本下降后，防守侧的稀缺资源变成验证、修复、打包、发布吞吐。综合判断是：
攻击搜索成本下降 ≠ 防守修复成本下降，所以安全预算不能只买更多扫描。 - 与 Agent-Verification 对标：本文的“完整修复”不是生成一个 patch，而是经历行为验证、回归测试、跨平台质量控制和下游传播；Agent 能生成 exploit 后，验证循环就成为安全响应的核心生产能力。
- 跨域旁逸：开源分发像免疫系统：漏洞线索像病原体信号，临时规则、完整 patch 和端点分发分别对应快速免疫、长期修复和群体传播。这个类比的结构性价值在于：防守效果取决于信号可信度、反应速度和覆盖范围的乘积，而不只是某个维护者是否“知道有 bug”。
4. 约束
- 硬约束（世界）：漏洞代码可被读取、依赖关系复杂、下游会重新打包、不同平台的行为存在差异；因此 patch 质量不能用单一 Linux CI 结果替代。
- 软约束（规则）：漏洞 embargo、临时私有 fork、审阅者邀请和发行节奏都是现行安全制度；它们保护的是信息或流程，但未必能覆盖 Agent 的自动搜索速度。
- 自设约束（设计）：文章把“快速到达端点”作为优先目标，并设想 web-of-trust 与协议层规则网络；这些方案能否在低误报、可撤销和跨生态信任上成立，仍需实验验证。
问答骨架（ljg-qa）
Q1：为什么一个传言就够了？
结论：当 Agent 能直接读代码并运行实验时，漏洞类别本身就可能成为 exploit 的搜索入口。
形式化：粗线索 + 可读代码 + Agent 搜索 → exploit 候选
怎么想到的：
- 作者先让 Agent 按 path normalisation 方向检查受影响代码。
- Agent 在不到一分钟内构造了可探测本地服务的 exploit。
- 因此攻击者不必等待完整 CVE 或 PoC 才开始行动。
边界：需要代码可访问、缺陷有可观测的行为模式且 Agent 能执行足够多的试探；不可达代码或需要复杂环境状态的漏洞不一定如此。
Q2：保密为什么守不住窗口？
结论：只要自动化发现速度快过维护者完成修复，保密期就不再等于安全窗口。
形式化：保密窗口 < 自动发现时间 → embargo 保护力下降
怎么想到的：
- 私下报告先在小范围流转，公开 PR 后立即出现对应探测。
- 同一篇文章里，Agent 的本地搜索耗时只有一分钟量级。
- 公开仓库、提交、讨论和上下文泄漏都可能成为搜索方向提示。
边界：这是对当前 Agent 能力与具体漏洞类型的判断，不意味着所有 embargo 都无效；高质量隔离仍可能阻断尚未暴露的细节。
Q3：攻防瓶颈换到哪一侧？
结论：攻击侧的机械搜索变便宜后，防守侧的验证、无回归修复和发布吞吐成为主要瓶颈。
形式化：攻击搜索成本 ↓ + 修复成本 ≈ 不变 → 瓶颈转向防守吞吐
怎么想到的：
- 文章把漏洞发现、报告撰写与 exploit 生成视为可被模型扩张的工作。
- 维护者仍须理解语义、验证补丁、覆盖平台并协调下游发行。
- 因此增加扫描器数量不能自动增加可部署修复数量。
边界：如果漏洞修复本身非常机械，或平台能自动安全地热更新，防守吞吐的压力会较小；复杂语义修复仍不属于此类。
Q4：维护者该先修什么？
结论：先部署低风险、可验证的临时缓解，再推进完整 patch，通常比等待一次性完美修复更能缩短暴露时间。
形式化：临时缓解 → 端点保护 → 完整修复 → 下游发布
怎么想到的：
- cohttp 案例中的路径分隔符规范化可在报告抵达时实施。
- 完整修复仍要经过 review、测试和 packaging。
- Cloudflare 的 managed rules 说明协议层 virtual patch 已有成熟先例。
边界：临时规则必须可撤销、误报可控并且不会绕过真正的修复；状态改变复杂或缺乏可观察性的系统不适合盲目自动部署。
Q5：持续发布为何仍不够？
结论：发布速度只有在依赖追踪、跨平台验证和下游传播同时提速时才会转化为安全收益。
形式化：安全收益 = 修复速度 × 验证覆盖 × 分发可达性
怎么想到的：
- Chrome 可控制单一二进制，因此能高频发布与动态更新。
- OSS 库常被嵌入不同产品，维护者不知道修复最终落在哪里。
- OpenBSD、FreeBSD、macOS 与 RISC-V 等平台会放大回归验证成本。
边界：单一发行物或集中式端点更容易实现连续发布；多生态库若没有 package graph 与可靠 CI，速度可能制造新的回归风险。
Q6：开源端点如何抢回秒级防守？
结论：OSS 需要把可信漏洞信号快速转成可审计的本地防御规则，而不只依赖上游完整版本发布。
形式化：可信信号 → 本地规则 → 端点缓解；完整 patch → 长期收敛
怎么想到的：
- 文章认为真正要保护的是漏洞描述的传播边界，而不是单独隐藏 patch。
- web-of-trust 可帮助区分可信贡献者与攻击者。
- antibotty 设想把同一传言交给攻击 Agent 与防守 Agent，比较谁先到达端点。
边界：规则分发网络必须解决身份、误报、撤销和责任归属；没有独立验证时，自动传播的防御规则也可能成为新的攻击面。