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

# 如今，仅仅一个漏洞的传言就足以被用来发现安全漏洞 来源：https://anil.recoil.org/notes/rumour-is-the-exploit 今天，我发布了 OCaml 的 cohttp 6.3.0 (https://discuss.ocaml.org/t/cohttp-6-3-0-released-osec-2026-16/18467) 的一个安全修复，解决了一个路径遍历问题 (https://osv.dev/vulnerability/OSEC-2026-16)。补丁本身很简单，在正常情况下，安全流程本应是私下修复、通知受影响的用户，然后发布公开的安全公告。但这一次，在我提交修复问题的 PR (https://github.com/mirage/ocaml-cohttp/pull/1145) 仅仅几分钟后，我注意到我的在线服务器日志中出现了具有完全相同漏洞模式的探测请求。 更糟糕的是，我发现我可以利用自己的智能体，仅*大致了解问题是什么*就能找到漏洞，甚至在公开补丁发布之前很久就能加以利用！鉴于仅仅一个安全问题的*传言*似乎就足以让攻击者获得足够的信息来发现新的漏洞，我们将需要改变在开源项目中处理安全响应的方式。 ## 1 (https://anil.recoil.org/notes/rumour-is-the-exploit#the-rumour-of-a-bug-is-all-new-agentic-exploit-systems-need) 漏洞的传言是所有新型智能体利用系统所需要的 这个特定的报告上周通过 Jane Street 的 Slack 频道私下转来，而它本身是通过 Claude Fable 发现的。这极大地压缩了所有时间线…… ### 1.1 (https://anil.recoil.org/notes/rumour-is-the-exploit#the-timeline-of-a-modern-security-report) 现代安全报告的时间线 在详细查看补丁之前，我让自己的 Claude 智能体检查了受影响的代码，看看是否还有其他问题（要求它调查路径规范化问题）。令人沮丧的是，Fable 由于其安全限制而断然拒绝了，因为我无法访问 Glasswing (https://www.anthropic.com/glasswing)，但 DeepSeek V4 Pro (https://anil.recoil.org/notes/language-integrated-llms) 满足了我的要求，并独立发现了几个相关问题。我的智能体还在一分钟内轻松创建了一个漏洞利用代码，来探测本地在线服务器。 在与报告者就可能的修复方案进行了一些交流后，我悄悄公开了 cohttp#1145 (https://github.com/mirage/ocaml-cohttp/pull/1145)，以获取更多关注 (https://anil.recoil.org/notes/2026w33)。这通常需要几天时间，一两周内发布新版本是合理的。但大约十分钟（！）内，这个网站就开始收到针对百分比编码的遍历序列的探测，表明自动监控工具正在监视公共代码库。 如果我自己创建本地利用代码只需要一分钟，那么十分钟作为自动化攻击窗口开始的时间似乎已经相当长了 (https://www.icir.org/vern/papers/cdc-usenix-sec02/)！一个决心攻击并监控软件包仓库的攻击者完全可能在几秒钟内就开始利用它们。 ### 1.2 (https://anil.recoil.org/notes/rumour-is-the-exploit#security-embargoes-are-no-longer-effective) 安全禁运不再有效 传统的安全流程涉及对漏洞进行禁运 (https://www.redhat.com/en/blog/Understanding-security-embargoes-at-Red-Hat)，并假设细节的保密性可以保护用户。然而，如今智能体只需要一个宽泛的搜索方向，就能自行展开研究。Fang 等人 (https://arxiv.org/abs/2404.08144) 发现，当给予一个 CVE 描述时，他们的 GPT-4 智能体在包含 15 个漏洞的基准测试中利用了 87% (https://surrealyz.github.io/classes/llmsec-fall24/slides/14-agents-exploit-vulnerabilities.pdf) 的漏洞，而没有描述时，仅能利用 7%。 两年后，平均漏洞利用时间 (https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026) 已经变成了 -7 天。换句话说，利用现在先于补丁出现！而同一指标在 2018-19 年约为 63 天，并在 2024 年跨越了零点。快速搜索会发现如今有很多类似的案例……marimo 的 CVE-2026-39987 (https://www.sysdig.com/blog/marimo-oss-python-notebook-rce-from-disclosure-to-exploitation-in-under-10-hours) 从公告到首次利用尝试只用了 9 小时，即使当时并没有公开的概念验证代码。Langflow 的 CVE-2026-33017 (https://www.sysdig.com/blog/cve-2026-33017-how-attackers-compromised-langflow-ai-pipelines-in-20-hours) 耗时 20 小时。我们似乎已经跨过了自动化漏洞利用生成的卢比孔河…… 2026年LLM漏洞利用状态 (来源: Vulncheck) https://www.vulncheck.com/blog/state-of-exploitation-1h-2026 ## 2 (https://anil.recoil.org/notes/rumour-is-the-exploit#are-the-bugonomics-against-oss-maintainers-now) 漏洞经济学现在是否对 OSS 维护者不利？ 在我看来，我们的安全流程需要做出一些反转，因为仅仅一个人搜索某个问题类别（这可能是一个邮件列表问题、一个孤立分支上的奇怪提交，或者一个上下文泄露）就足以警觉到其他人的智能体，并让它们获得漏洞利用代码。这太疯狂了。 2026年5月的一篇论文创造了“漏洞经济学 (https://arxiv.org/abs/2605.24632)”这一术语，并认为瓶颈已转移到“防御者修复吞吐量”上。LLM 正在愉快地生成漏洞利用代码，但我们的防御能力并未必然提高，因为维护者的验证、分类和发布速度保持停滞。这不幸地印证了我作为 OSS 维护者的看法： > 问题不在于前沿模型、开源权重模型或程序分析“哪个会赢”。问题在于如何协调它们，以便将稀缺的验证、优先级排序和发布能力用于持久的修复，而不是机械化的搜索和报告起草。一个核心的防御机会是技术债务清偿：基于语义、工具验证、模型辅助的工作流，帮助维护者在安全相关缺陷成为明天被利用的漏洞之前，找到、验证、优先级排序并修复它们。——《揭开神秘面纱还是颠覆漏洞经济学？》(https://arxiv.org/pdf/2605.24632)，Pesoli 等，2026 为什么维护者的能力停滞不前？一个明显的原因是无法访问像 Mythos 这样的前沿智能体，此外，编写一个不会引起任何回归的安全补丁本质上就是更繁重的工作。 ## 3 (https://anil.recoil.org/notes/rumour-is-the-exploit#so-what-the-hell-can-we-do-about-this) 那么，我们到底能做些什么？ 我们显然需要相当快速地适应。我不认为当前的人工分类流程应该消失，但自从 Fable 出现以来，我目睹了一种不可持续的活动激增。我们才刚刚开始了解有多少涌入的信息流是机器生成的，但显然数量巨大。 大型工程公司（如 Google）一直在将微更新直接集成到他们的软件中 (https://blog.google/security/chrome-stronger-with-every-update/)，以确保修复直接触达用户，作为优先事项（例如，在 Chrome 代码仓库中修复）。我们在 Docker 或 OCaml 领域并没有那种奢侈条件，因为我们无法控制软件使用的终端。除了 Docker Desktop (https://anil.recoil.org/papers/2026-decade-docker) 之外，下游发行版理所当然地会按照自己的时间表和条款重新打包 OSS。 对于像 OCaml 这样的小型项目，仅仅是获得前沿模型的访问权限就很困难。西方的模型设有安全防护，这意味着我们无法使用商业上可用的模型。Project Glasswing (https://www.anthropic.com/glasswing) 已扩展到 (https://www.helpnetsecurity.com/2026/06/03/anthropic-project-glasswing-expansion/) 15 个国家的 150 个组织，包括关键基础设施运营商、云和金融提供商、Linux 基金会，但“夫妻店”式的维护者仍然无法访问。四月份 (https://anil.recoil.org/notes/internet-immune-system) 我对此是否有害还持矛盾态度，但今天看来情况显然相当糟糕。 ### 3.1 (https://anil.recoil.org/notes/rumour-is-the-exploit#super-sekrit-private-patch-development) 超级私密的补丁开发 第一个补救措施是在 AI 无法触及的私密环境中开发修复。GitHub 的临时私有分支 (https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/collaborating-in-a-temporary-private-fork-to-resolve-a-repository-security-vulnerability) 名义上可以做到这一点，但对我们来说效果并不好。 首先，GitHub 限制它“为了保持漏洞信息的安全，包括 CI 在内的集成无法访问临时私有分支”，这立即使维护者与我们的 CI 结果命脉脱节。其次，只能有一个 PR 合并到该分支中，这对于通常涉及多个仓库的问题来说不太好用。审查者也必须由管理员逐一加入，而在开源领域，审查者往往是顺手为之，取决于谁有空（尤其是在八月！）。 不过，更广泛地说，这堵塞了错误的漏洞。补丁保密远不如确保问题描述准确送达相关人员，且不泄露给攻击者重要。 我们在 OSS 内部没有稳健的*讨论*基础设施，因为它分散在各种端到端加密服务中（我们使用 Matrix），但也包括像 Discord 或 Slack 这样极易泄露的共享基础设施。我们确实需要某种形式的信任网络 (https://blog.tangled.org/vouching/) 来在特定项目背景中区分好人和坏人。 ### 3.2 (https://anil.recoil.org/notes/rumour-is-the-exploit#no-embargoes-just-ship-continuously) 不搞禁运，只做持续发布 我们能做的另一件事是公开快速修复问题，持续发布，并通过更好的自动化改进发布路径。 像 Chrome 这样的大型项目通过每周安全更新 (https://blog.google/security/chrome-stronger-with-every-update/)（每周发布两次（！））和动态补丁 (https://arstechnica.com/ai/2026/07/chrome-may-get-faster-updates-with-no-restart-required/)（在后台用更新的二进制文件替换进程而无需重启）证明了这是可能的。这并非全新的技术；十五年前我就研究过将 Linux 的 live ksplice 补丁 (https://en.wikipedia.org/wiki/Ksplice) 与 Xen 集成。Linux 内核也尽快发布修复，最多延迟七天 (https://docs.kernel.org/process/security-bugs.html)，特殊情况最多十四天。 然而，软件打包是我们的主要障碍。Chrome 发布一个二进制工件相对容易，但 OSS 通常是一堆库，然后嵌入 (https://anil.recoil.org/papers/2025-docker-icfp) 到各种下游产品中。因此，要实现这一点，我们需要： - 更好的跨生态系统包管理 (https://anil.recoil.org/papers/2026-package-calculus)，以发现分散的库最终被嵌入到哪里。Ryan Gibb (https://ryan.freumh.org/) 将在下周的 ICFP 上讨论这个！ - 更好的扫描工具以辅助分类；Andrew Nesbitt 在过去几个月一直在通过 Scrutineer (https://nesbitt.io/2026/06/25/scrutineer.html) 做这件事。Thomas Gazagnaire (https://github.com/samoht) 和我一直在讨论尝试将其用于我们的 OCaml 代码，前提是我们能获得一个没有安全限制的合理前沿模型访问权限。 - 更稳健的、无误报的质量控制基础设施，能够跨支持的平台工作。虽然在 Linux 上运行 CI 相对容易，但在 OpenBSD (https://www.tunbury.org/2026/06/30/openbsd-copy-corruption/)、FreeBSD (https://www.tunbury.org/2026/06/24/leaking-jails/)、macOS (https://www.tunbury.org/2025/10/06/overlayfs-macFuse/) 以及一些架构如 RISC-V (https://www.tunbury.org/2026/06/03/emulated-riscv-workers/) 上就是另一回事了。 ### 3.3 (https://anil.recoil.org/notes/rumour-is-the-exploit#proactive-protection-at-the-protocol-layer) 协议层的主动保护 我还在更激进地思考，如何动态地为使用我们库的终端引入保护措施。如果我们承认上游补丁修复总是落后于漏洞利用，那么我们*必须*采取更快的措施来取得先机。 例如，今天修复的 cohttp 漏洞有一个简单的缓解方法：只需规范化请求 URL 中的百分比编码路径分隔符。这条规则在报告到达的那一刻就可以实现，并且可以在完整修复经过审查、测试和打包期间部署。虚拟补丁在当今云基础设施中已是常规操作；Cloudflare 在 2021 年就部署了托管规则 (https://blog.cloudflare.com/how-cloudflare-security-responded-to-log4j2-vulnerability) 来修补 Log4shell。 但开源缺乏在商业 CDN 之外分发此类规则的机制。这就是我们互联网生态论文 (https://anil.recoil.org/papers/2025-internet-ecology) 中提出的反机器人网络 (https://anil.recoil.org/notes/internet-immune-system) 思想试图通过围绕全球互联网增加更多软件多样性 (https://anil.recoil.org/notes/rewilding-the-web-report) 来填补的空白。我们如何拥有本地、快速传播的防御措施，能够在几秒钟内获知漏洞并对其直接基础设施采取行动？ https://anil.recoil.org/slides/2025-internet-ecology.html ## 4 (https://anil.recoil.org/notes/rumour-is-the-exploit#some-research-followups) 一些研究跟进 我认为短期内我们需要结合所有三种选择。为 OSS 贡献者建立一个轻量级的信任网络（就像值得尊敬的 Advogato 曾经那样 (https://anil.recoil.org/notes/opam-ai-disclosure-update)），以及更专注于 OSS 打包和持续发布、分类机制，避免压垮我们宝贵的人类贡献者。 我还发布了一些新的 MPhil 研究想法，给下个月即将入学剑桥并寻找项目的人。 - “一个用于保护网络服务的反机器人防御测试平台 (https://anil.recoil.org/ideas/antibotty-testbed)” 将一个 MirageOS 网关放在家庭网络前面，并研究一套缓解规则是否可以变得足够可信以实现自动部署。我们可以玩一个有趣的夺旗游戏，将同一个传言给攻击智能体和防御智能体，看看谁先得手。 - “将 Lean 规范编译为 OxCaml 执行自动机 (https://anil.recoil.org/ideas/lean-dijkstra-automata)” 使用 Dijkstra 单子 (https://anil.recoil.org/papers/2024-hope-bastion) 定义一个库在文件系统、解析器和网络层被允许做什么。这将把该 Lean 规范编译为一个 OxCaml 自动机，在运行时强制执行。这是我博士期间构建的 statecall 自动机 (https://anil.recoil.org/papers/2009-icfem-spl) 的现代演绎。 另外，如果 Project Glasswing 的人正在听，OCaml 团队现在可以需要访问权限了 :-) *（cohttp 的修复并非一人之力。Sapphire Livingstone 发现并报告了该问题，指导了修复并共同开发了补救措施；Michael Dales (https://mynameismwd.org/)、Török Edwin (https://github.com/edwintorok) 和 Patrick Ferris (https://patrick.sirref.org/) 审查了补丁；Hannes Mehnert (https://github.com/hannesm) 协调了安全公告；Thomas Gazagnaire (https://github.com/samoht) 一直在思考更广泛的分类问题。感谢你们所有人！漏洞经济学可能对我们不利，但我们将翻过这道坎。）*