Anthropic 评估并缓解 LLM 发现 0-day 漏洞的风险

Nicholas Carlini^*, Keane Lucas^*, Evyatar Ben Asher^*, Newton Cheng, Hasnain Lakhani, David Forsythe, and Kyla Guru
^*表示贡献均等

Claude Opus 4.6，今日发布，继续在 AI 模型的网络安全能力方面进行有意义的改进。去年秋天，我们写道，我们相信我们正处于 AI 对网络安全影响的拐点——进步可能会变得非常快，现在是加速 AI 防御性使用的时候。自那以来的证据只加强了这一观点。现在，AI 模型可以大规模地发现高严重性漏洞。我们的观点是，这是一个快速行动的时刻——在窗口期存在时，授权防御者并尽可能多地保护代码。

Opus 4.6 在发现高严重性漏洞方面明显优于之前的模型, 这也是事物发展迅速的标志。安全团队多年来一直在自动化漏洞发现, 大力投资模糊测试基础设施和定制工具来大规模地发现错误。但在早期测试中突出的是 Opus 4.6 无需特定任务工具、定制框架或专业提示就能快速发现漏洞。更有趣的是它是如何 做到的。模糊测试器通过向代码抛掷大量随机输入来查看什么会出问题。Opus 4.6 以人类研究员的方式阅读和推理代码——通过查看过去的修复记录来找到未解决的类似错误, 识别可能导致问题的模式, 或深入理解某段逻辑以知道确切会破坏它的输入。当我们把 Opus 4.6 对准一些经过最充分测试的代码库 (这些项目多年来一直运行模糊测试器, 积累了数百万小时的 CPU 时间) 时, Opus 4.6 发现了高严重性漏洞, 其中一些漏洞已经存在了数十年未被检测到。

使防御者占据优势的一部分意味着我们自己来做这项工作。我们现在使用 Claude 来发现和帮助修复开源软件中的漏洞。我们从开源开始, 因为它无处不在——从企业系统到关键基础设施——这些漏洞在整个互联网中产生涟漪。这些项目中的许多是由小型团队或志愿者维护的, 他们没有专门的安全资源, 因此发现经过人类验证的漏洞和贡献经过人类审查的补丁意义重大。

到目前为止, 我们已经发现并验证了 500 多个高严重性漏洞。我们已经开始报告它们, 并且看到我们的初始补丁被应用, 我们将继续与维护者合作来修复其他漏洞。在这篇文章中, 我们将介绍我们的方法, 分享一些 Claude 发现的漏洞的早期示例, 并讨论我们为管理这些能力持续改进时的滥用风险而采取的保障措施。这仅仅是我们工作的开始。随着这项工作的扩展, 我们将有更多内容要分享。

设置

在这项工作中，我们将 Claude 放入一个“虚拟机”（字面意思，一个模拟计算机）中，该虚拟机可以访问最新的开源项目版本。我们给了它标准工具（例如，标准核心工具或 Python）和漏洞分析工具（例如，调试器或模糊测试器），但我们没有提供任何关于如何使用这些工具的特殊说明，也没有提供任何定制的 harness，它将提供有关如何更好地发现漏洞的专业知识。这意味着我们直接测试了 Claude 的“开箱即用”功能，完全依赖于这样一个事实：现代大型语言模型通常是能够推理如何最好地使用可用工具的通用代理。

为了确保 Claude 没有产生幻觉错误（即，发明了不存在的问题，这是一个日益给开源开发者带来不当负担的问题），我们在报告之前对每个错误进行了广泛的验证。我们专注于搜索内存损坏漏洞，因为它们相对容易验证。与程序仍然可以正常工作的逻辑错误不同，内存损坏漏洞可以通过监控程序崩溃并运行地址清理器等工具来轻松识别非崩溃的内存错误。但是，因为不是所有导致程序崩溃的输入都是高严重性漏洞，所以我们随后让 Claude 评论、去重和重新排序剩余的崩溃。最后，在我们的初步发现中，我们自己的安全研究人员验证了每个漏洞并手动编写了补丁。随着发现数量的增加，我们引入了外部（人类）安全研究人员来帮助验证和补丁开发。我们在这里的意图是有效地帮助人类维护者处理我们的报告，因此该过程优化以减少误报。同时，我们正在加速我们的工作以自动化补丁开发，以便可靠地修复我们发现的错误。

漏洞

以下是 Claude 发现的三个漏洞（现已由维护人员修复），我们相信它们展示了 LLM 相对于其他工具的独特优势。

GhostScript 是一个处理 PostScript 和 PDF 文件的工具。Claude 在搜索漏洞时最初遇到了几个死胡同——尝试模糊测试代码，以及在此失败后尝试手动分析。这两种方法都没有产生任何重大发现。然而，最终，Claude 采取了不同的方法：阅读 Git 提交历史。Claude 快速发现了一个与安全相关的提交，并评论道：

从这里，Claude 查看了代码以了解发生了什么变化：

有了这个想法，Claude 然后寻找其他调用此函数的地方，以发现可能未修复的类似漏洞。

在做出这个观察后，Claude 快速构建了一个概念验证崩溃（一个可以传递给 GhostScript 并使其崩溃的文件），证明了它的预测。

OpenSC 是一个处理智能卡数据的命令行工具。同样，Claude 最初尝试通过模糊测试代码来发现漏洞，在此失败后通过手动分析。像之前一样，当这种方法不起作用时，Claude 采取了不同的方法：它开始搜索存储库中频繁易受攻击的函数调用。

Claude 快速识别到一个多处连续使用 strcat 操作的位置。这些函数在 C 语言中通常被视为不安全的，因为它们允许在不检查结果拼接字符串长度的情况下拼接字符串。因此，程序员必须验证输出缓冲区足够长，以包含拼接的输入。对于 OpenSC，关键问题在于以下代码：

Claude 确定这段代码容易受到缓冲区溢出的影响。当我们查看现有模糊测试器对这段代码进行模糊测试的频率统计时，我们发现由于需要满足许多前提条件，传统模糊测试器很少研究这段代码。相比之下，Claude 能够推理出哪些代码片段有趣，并集中精力在这些地方，而不是不加区分地同等努力地研究所有行。

CGIF 是一个处理 GIF 文件的库。在这种情况下，我们惊讶的不是 Claude 找到 了漏洞，而是它如何 验证 了漏洞并生成了一个概念验证，证明了漏洞是真实的。

简而言之，Claude 发现 这个库假设压缩数据始终小于其原始大小（这通常是一个安全的假设），并且这个假设可以被利用。它这样做的方式具有挑战性。GIF 文件格式使用 LZW 压缩算法压缩数据。与使用 (距离, 长度) 对编码匹配的传统 LZ77 支持的压缩器不同，LZW 建立一个频繁使用的标记对（无论是单个字符，还是标记对）的字典。然后，当压缩器遇到这个标记第二次时，它可以输出一个较短的位串表示“再次输出这个标记”。 （对于熟悉语言建模的人来说，LZW 在精神上与 BPE 标记化的过程非常相似。）

CGIF 暗示假设压缩字符串的压缩大小始终小于未压缩大小——这几乎是 总是正确的。然而，Claude 立刻认识到这里的漏洞：

也就是说，Claude 认识到 LZW 维护一个固定大小的符号表；如果有可能使符号表的大小达到最大，那么 LZW 在数据流中插入一个新的特殊“清除”标记。这会导致输出“压缩”大小超过未压缩大小——触发缓冲区溢出漏洞。

这个漏洞特别有趣，因为它需要触发它需要对 LZW 算法和它与 GIF 文件格式的关系有一个概念上的理解。传统模糊测试器（甚至包括覆盖引导模糊测试器）难以触发这种类型的漏洞，因为它们需要做出特定的分支选择。事实上，即使 CGIF 有 100% 的行和分支覆盖率，这个漏洞仍然可能未被检测到：它需要一个非常特定的操作序列。

安全防护措施

随着Claude Opus 4.6的发布，我们引入了新的检测层，以支持我们的Safeguards团队在识别和应对 Claude的网络滥用。这项工作的核心是探测器，它们在模型生成响应时测量激活情况，并允许我们在大规模上检测特定的危害。随着这次发布，我们创建了新的网络安全特定探测器，以更好地跟踪和理解Claude在网络安全领域的潜在滥用。

在执行方面，我们正在改进我们的管道，以跟上这种新的检测架构。这包括更新我们的网络安全执行工作流程，以利用基于探测器的检测，以及扩大我们采取的行动范围，以应对网络滥用。特别是，我们可能会实施实时干预，包括阻止我们检测到的恶意流量。这将给合法研究和一些防御性工作带来摩擦，我们希望与安全研究社区合作，找到解决这些问题的方法。 我们致力于通过努力使Claude保持网络安全领域的领先地位，使其既安全又有效。

这些变化共同代表了我们防止滥用的能力向前迈出的重要一步：不仅在于我们能检测到什么，还在于我们能多快、多有效地处理我们发现的。

结论

Claude Opus 4.6可以在经过充分测试的代码库中发现有意义的0天漏洞，即使没有专门的脚手架。我们的结果表明，语言模型可以在现有的发现工具之上增加真正的价值。我们上面描述的Safeguards工作对于管理这种双用风险至关重要。

展望未来，我们和更广泛的安全社区都将不得不面对一个令人不安的现实：语言模型已经能够识别新的漏洞，并且可能很快就会超过甚至专家级人类研究人员的速度和规模。

同时，现有的披露规范也需要进化。行业标准90天的窗口 可能无法应对LLM发现的漏洞的速度和数量，行业将需要能够跟上步伐的工作流程。

这是一项正在进行的工作，我们很快将分享更多信息——包括我们如何了解这些能力如何演变以及安全社区如何最好地利用它们。

编辑于2026年2月6日：

• 更新了作者列表