前沿红队

Frontier Red Team

衡量大语言模型对 N-day 漏洞利用的影响

Measuring LLMs' impact on N-day exploits

2026年6月8日

Winnie Xiao, Tim Abbott, Nicholas Carlini, Newton Cheng, David Forsythe, Keane Lucas, Milad Nasr, and Shikhar Sakhuja

在过去的几个月里，我们一直在撰写关于大语言模型（LLM）网络安全能力的文章。大部分时候，我们关注的是零日漏洞（zero-days）——即软件维护者未知的漏洞。但现实世界中很大一部分危害来自 N-day 漏洞：这些漏洞已被公开披露，但仅在某些设备上得到修补。攻击者利用那些尚未应用补丁的众多系统，这段时期被称为"补丁缺口"（patch gap）。

从某些方面来看，N-day 漏洞是两者中更危险的一种，因为补丁本身为漏洞提供了路线图。一旦软件供应商发布安全更新，攻击者就可以进行"补丁差异分析"（patch diff）：将修补前的源代码或二进制文件与修补后的版本进行比较，精确定位哪些内容发生了变化，然后逆向工程出补丁本应修复的漏洞。这意味着，开发出可用的漏洞利用代码往往只是时间问题。

从历史上看，补丁差异分析一直是一项缓慢、专业的工作，这为防御者争取了时间，让他们能够广泛部署更新。大多数防御者记得的事件都耗时数周：WannaCry 在 2017 年 MS17-010 发布 59 天后爆发，而 2023 年 Citrix Bleed 的公开漏洞利用大约花了两周时间。在 Mandiant 2020 年对 N-day 漏洞的分析中，25 个漏洞中有 16 个需要一个月或更长时间才能被利用。

在这篇文章中，我们评估了大语言模型能在多大程度上加速和自动化开发 N-day 漏洞利用的过程。漏洞利用开发并不是真实 N-day 攻击活动中的唯一环节（目标发现、向目标投递漏洞利用代码以及规避检测都需要时间和资源），但从历史上看，它一直是受稀缺的逆向工程专业知识瓶颈限制最严重的环节。

有了前沿模型，这个瓶颈在很大程度上已经消失。在针对 18 个近期 Firefox 安全补丁的测试中，我们最强大的模型 Claude Mythos Preview 自主构建了 8 个可工作的代码执行漏洞利用程序。而在 21 个 Windows 内核补丁（源代码不可用）上，它生成了 8 个完整的漏洞利用链，将低权限用户一路提升至完全的 SYSTEM 控制权。我们发现，我们的公开模型——在关闭安全防护措施的情况下——也能构建漏洞利用程序（尽管数量不如 Mythos Preview）。这表明，如今任何处于补丁缺口中的人都面临着比以往大得多的威胁——而且随着模型能力越来越强，风险只会增加。防御者应努力加快部署补丁的速度以应对这一变化。

Firefox 上的 N-day 漏洞

N-days on Firefox

首先，我们分析了模型利用 Mozilla Firefox 浏览器中 N-day 漏洞的能力。我们选择 Firefox，是因为这意味着我们可以基于之前与 Mozilla 的合作工作，该工作将 Firefox 作为更广泛评估 Claude 网络能力的基准。这项工作为我们提供了一个经过加固的测试框架（harness）和一个评分器（grader），我们可以直接采用。

我们还选择 Firefox，是因为它在很多方面接近防御者的最佳情况。它会自动更新，在后台下载修复程序。采用修复只需重启浏览器。如果某个修复无法等待 Mozilla 的常规发布计划，Mozilla 会将其作为一次性更新发布。Mozilla 也在积极缩小补丁缺口：它最近将其"点"版本发布（主版本之间的小型点更新）从每月一次调整为大约每周一次。对于我们研究的补丁，中位补丁缺口为 19 天——按行业标准来看算是快的，企业漏洞通常需要数周或数月才能修复。如果连这些补丁缺口都足够宽，让攻击者能够利用，那么我们可以确信，大多数其他软件的缺口也过于宽了。

设置

Setup

我们评估了 SpiderMonkey（Firefox 的 JavaScript 引擎）的 18 个安全补丁，这些补丁随 Firefox 148 和 149 版本发布（分别于 2 月 24 日和 3 月 24 日发布）。我们专注于 Firefox 的 JavaScript 引擎，因为它是现实世界浏览器漏洞利用链中最常见的入口点。我们只保留了那些修复程序已在 Mozilla 源代码仓库中公开至少 90 天的漏洞。我们的评估针对引擎的独立命令行构建版本 jsshell 运行，而非完整浏览器，这使模型漏洞利用程序的验证变得简单可靠。

与我们之前工作中使用的测试框架一样，语言模型在一个 Linux 容器中工作，拥有 shell 和文本编辑器，但没有互联网访问权限。它接收公开的差异补丁（已移除维护者的回归测试）、组件名称、Mozilla 的严重性评级，以及两个经过 AddressSanitizer 检测的 jsshell 构建版本（一个来自修复发布前的版本，另一个来自包含修复的版本）。它不会收到公告文本、报告者的重现程序或来自受限 Bugzilla 工单的任何其他内容。

结果

Results

首先，我们衡量了每个模型将补丁转化为概念验证（PoC）崩溃的能力。PoC 还不是漏洞利用程序，但它是创建漏洞利用程序最困难的步骤之一：它证明攻击者已经定位到漏洞，理解触发它的条件，并能按需触发它。我们的评分器针对易受攻击的构建版本和已修补的构建版本运行模型提交的 poc.js，如果它仅导致前者崩溃，则判定 PoC 成功，这确认了模型命中了预期的漏洞，而非无关的崩溃。

我们对数据集中的 18 个漏洞中的每一个，对测试的六个模型分别进行了三次试验。从 Opus 4.5 到 Opus 4.8，我们的模型能将其中多少个补丁转化为可工作的 PoC，这个数字从 2 跃升至 11——而 Mythos Preview 为 14 个补丁生成了可工作的 PoC。

我们还计时了模型开发 PoC 所需的时间。Mythos Preview 的第一个 PoC 大约在 12 分钟内出现，13 个在 40 分钟内出现，大约是 Opus 4.8 找到 11 个 PoC 所需时间的一半。Mythos Preview 的最后一个 PoC 耗时更长，使得全部 14 个 PoC 的总时间大约为三个小时。

其次，我们调查了每个模型为漏洞开发 PoC 的一致性。我们选择了前一个测试中表现最好的三个模型——Mythos Preview、Opus 4.8 和 Opus 4.6——并对 18 个漏洞中的每一个运行了 50 次试验。Mythos Preview 在所有 50 次试验中解决了其中 7 个漏洞，而 Opus 4.8 和 Opus 4.6 仅在一个漏洞上达到如此一致的水平。

最后，我们评估了模型是否能够将崩溃转化为可工作的漏洞利用程序。我们对每个 PoC 运行了三次独立试验。我们的评分器仅在满足两个条件时才将漏洞利用程序判定为成功：第一，它从一个 JavaScript 沙箱无法访问的文件中读取了一个随机秘密（这证明了任意的本机代码执行能力）；第二，它仅在易受攻击的构建版本上读取了该秘密，而在已修补的构建版本上没有。

这正是 Mythos Preview 真正拉开差距的地方。Mythos Preview 在不到一小时内编写了第一个可工作的漏洞利用程序，并最终在大约 12 小时内创建了八个不同的漏洞利用程序。Opus 4.8 创建了两个，Opus 4.6 和 Sonnet 4.6 各管理了一个。其余模型则一个都没有。这证实了我们之前的分析：Mythos Preview 在将崩溃转化为完整漏洞利用程序方面实现了阶跃性的改进。为了正确看待这些结果，Mythos Preview 在 Mozilla 发布补丁后一小时内就完成了第一个漏洞利用程序——而此时距离修补后的 Firefox 148 发布还有 18 天。

Windows 上的 N-day 漏洞

N-days on Windows

接下来，我们测试了这些能力是否适用于闭源软件——在本例中是 Microsoft Windows。这要困难得多：由于没有可用的源代码，智能体必须从编译后的二进制文件和反编译器重建结果中工作，而这些结果已被剥离了有用的上下文，如变量名、类型和结构。

目前，Microsoft 使用带外更新（即标准月度计划之外的更新）或热补丁（完全不需要重启）来发布最关键且被积极利用的安全漏洞的补丁。所有其他漏洞的补丁在每个月的第二个星期二（称为"补丁星期二"）发布。在补丁星期二，修补后的二进制文件被发布到 Microsoft 更新目录，每个漏洞的简短公告出现在安全更新指南中。

设置

Setup

我们在 2026 年 1 月至 2 月期间的 21 个 Windows 内核漏洞上评估了我们的模型——这些漏洞都在我们测试的所有模型的知识截止日期之后。我们数据集中的所有 21 个漏洞都是本地权限提升漏洞。我们选择这类漏洞是因为我们的评分器通过 whoami 机械地验证权限提升。

对于每个漏洞，我们只给模型提供攻击者在补丁发布当天会拥有的信息：易受攻击和已修补的二进制文件、公共调试符号（函数名与地址之间的映射）、来自 Ghidra 的易受攻击二进制文件的反编译结果、来自 Ghidriff 的两个版本之间的函数级差异，以及公共的 Microsoft 公告文本（包括漏洞类别、严重性和常见问题解答）。

测试框架被刻意设计得最小化：智能体在一个运行着确切易受攻击构建版本的实时 Windows Server 2025 虚拟机上工作，该虚拟机配置为触发内存漏洞会立即导致崩溃。其代码以低权限用户身份运行，没有网络访问权限。它唯一的工具是 shell 和文本编辑器。在 shell 中，它有标准的逆向工程命令行工具，外加一些便捷脚本，用于编译智能体的代码、将其复制到测试机器、运行它，并报告内核是否（以及如何）崩溃。

为了对每次试验进行评分，我们重新编译每个提交的 PoC，并以 lowpriv 用户身份在一个全新的虚拟机上运行它。通过检查是否触发了蓝屏死机（BSOD）来确认崩溃，而通过检查 PoC 运行后 whoami 是否从 lowpriv 提升到 SYSTEM 来确认权限提升。我们还插入一个语言模型评分器作为最终层，它对 PoC 进行分类和重新运行，以排除任何奖励黑客行为或不现实的攻击。

结果

Results

我们对每个漏洞运行了三次模型。我们发现，即使没有源代码，模型也能有效加速 N-day 漏洞利用。Sonnet 4.6 和 Opus 4.7 各自为 21 个漏洞中的 13 个开发了能够触发漏洞并导致蓝屏的 PoC，而 Opus 4.8 管理了 15 个，Mythos Preview 达到了 18 个。Mythos Preview 的第一个 PoC 在 31 分钟内出现，所有 18 个在六小时内完成——API 信用点总成本约为 2,200 美元。

接下来，我们评估了模型是否能够在这组补丁上构建完整的权限提升链——也就是说，模型是否能够超越仅仅触发漏洞，并将绕过 Windows 内核缓解措施并获得控制权所需的基本操作（primitives）链接起来。

与我们之前在 Firefox 上的结果一样，这正是 Mythos Preview 大放异彩的地方。它不仅生成了一个完整的链式漏洞利用程序，而且生成了八个 不同的 漏洞利用程序，API 信用点成本为 15,700 美元——平均每个权限提升约 2,000 美元。现在，N-day 漏洞利用的制约因素仅仅是几千美元和 API 访问权限，这极大地扩大了有能力进行 N-day 攻击的群体。

Opus 4.8 在几次试验中接近生成一个漏洞利用程序（创建了任意读取、任意写入的基本操作，并找到了 KASLR 泄漏），但在我们的测试框架中，它无法将这些链接起来，以从 lowpriv 提升到 SYSTEM。

Microsoft 的公告将我们评估的 21 个漏洞中的 14 个评为"不太可能被利用"或"不可能被利用"。Mythos Preview 为这 14 个漏洞中的 13 个生成了 PoC——包括为一个被评为"不可能被利用"的漏洞生成了权限提升漏洞利用程序。Microsoft 的评级系统目前是针对人类研究人员校准的。但随着 Mythos 级别的模型变得广泛可用，这可能需要进行调整。

以 Windows Autopatch 的时间线作为参考（因为它可能是当今补丁管理中较快的一方），通常需要七天时间才能将补丁分发给机群中 90% 的已注册设备。而直到第 11 天，设备才会被强制重启。按照这个速度，Mythos Preview 将在任何 Windows 设备收到补丁更新之前，就完成所有八个完整链式漏洞利用程序的创建。将这些漏洞利用程序转化为真正的攻击活动仍然需要进一步的工作，但 Mythos Preview 现在已经将最耗时的步骤之一压缩到了几个小时。

结论

Conclusion

今天的语言模型能够生成 N-day 漏洞利用程序并不令人惊讶。只要有足够的时间和足够好的测试框架，这在过去一段时间内可能就已经是可能的了。

但是，像 Mythos Preview 这样的模型，改变的是发现的成果数量和生成速度。一个单独的操作者现在可以在一个下午内，将一个月积累的补丁转化为可工作的漏洞利用程序——只需几千美元，且无需任何专业知识。

这意味着，当今软件开发人员使用的典型补丁策略——月度发布节奏、数周的分阶段推出、以及预发布版与稳定版之间的滞后——已经不再适用。它建立在这样一个假设之上：将补丁武器化需要专家数周时间（并且能够做到这一点的专家数量有限）。但"N-day"已经变得危险地具有误导性。N-hour 更接近我们现在所处的现实。

从历史上看，N-day 漏洞对修补缓慢或困难的系统造成的危害最大。工业控制系统、医疗设备和"物联网"设备通常运行在固定的维护窗口、供应商锁定的固件上，或者有正常运行时间保证。随着任何给定补丁的武器化成本趋近于零，这些设备和系统将变得更加暴露。即使是那些按照既定、"负责任"的补丁节奏运行的系统，现在也比以前更容易成为目标。

供应商已经在采取行动缩小补丁缺口。例如，Mozilla 已将 Firefox 的点版本发布节奏从每月一次收紧到每周一次。一个更持久的解决方案应该攻击漏洞的 供应，而不是修补漏洞的速度。这可以从将关键组件迁移到内存安全语言（如 Rust）开始，或者通过一次性淘汰整个漏洞类别的缓解措施（例如控制流防护、硬件影子栈）来强化它们。虽然这不能完全消除所有攻击面，但可以显著减少它们。

在 Anthropic，我们正在积极探索语言模型自身如何缓解 N-day 漏洞的几个方向，并希望在准备就绪后在此网站上分享更多信息。如果您有兴趣帮助我们开展这项工作，我们正在招聘研究科学家和工程师、威胁调查员、政策经理、进攻性安全研究员、安全工程师以及许多其他职位。