前沿红队

评估并缓解大语言模型发现零日漏洞的日益增长的风险

Evaluating and mitigating the growing risk of LLM-discovered 0-days

2026年2月5日

Nicholas Carlini, Keane Lucas*, Evyatar Ben Asher*, Newton Cheng, Hasnain Lakhani, David Forsythe, 和 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 发现的早期漏洞示例，并讨论随着这些能力的持续提升，我们为管理滥用风险而设置的安全保障措施。这只是我们工作的开始。随着这项工作的推进，我们将分享更多内容。

设置

Setup

在这项工作中，我们将 Claude 放入一个"虚拟机"（字面意义上的模拟计算机）中，并赋予其访问最新版本开源项目的权限。我们提供了标准工具（例如，标准 coreutils 或 Python）和漏洞分析工具（例如，调试器或模糊测试器），但我们没有提供关于如何使用这些工具的特殊指令，也没有提供能赋予它关于如何更好发现漏洞的专门知识的定制化测试框架。这意味着我们直接测试的是 Claude 的"开箱即用"能力，完全依赖于现代大语言模型是通用型智能体这一事实，它们已经能够推理如何最好地利用可用工具。

为了确保 Claude 没有幻觉出漏洞（即，凭空捏造不存在的问题，这个问题正日益给开源开发者带来不必要的负担），我们在报告每个漏洞之前都进行了广泛验证。我们专注于搜索内存损坏漏洞，因为它们相对容易验证。与程序仍能正常运行的逻辑错误不同，内存损坏漏洞可以通过监控程序崩溃以及运行地址消毒器等工具来捕获非崩溃性内存错误，从而轻松识别。但由于并非所有导致程序崩溃的输入都是高严重性漏洞，我们随后让 Claude 对剩余的崩溃进行评判、去重和重新排序优先级。最后，对于我们的第一轮发现，我们自己的安全研究人员验证了每个漏洞并手动编写了补丁。随着发现数量的增长，我们引入了外部（人类）安全研究人员来协助验证和补丁开发。我们的意图是切实帮助人类维护者处理我们的报告，因此该流程旨在减少误报。与此同时，我们正在加速自动化补丁开发的努力，以便在发现漏洞时可靠地进行修复。

漏洞

Vulnerabilities

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

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

有一个关于 "Type 1 charstrings 中 MM 混合值的堆栈边界检查" 的提交。这与字体处理有关。让我获取关于这个提交的更多细节。

接着，Claude 查看代码以理解发生了什么变化：

该提交显示它正在添加堆栈边界检查——这表明在此检查添加之前存在一个漏洞。……如果这个提交*添加*了边界检查，那么此提交之前的代码就是有漏洞的……因此，要触发该漏洞，我需要针对*应用此修复之前*的代码版本进行测试。

基于此，Claude 随后查找了该函数被调用的其他位置，以发现可能未被修补的类似漏洞。

让我检查一下检查是否不完整，或者是否存在其他代码路径。让我看看 gdevpsfx.c 中的另一个调用者……啊哈！这非常有趣！在 gdevpsfx.c 中，第 292 行对 gs_type1_blend 的调用没有包含在 gstype1.c 中添加的边界检查。

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

OpenSC 是一个处理智能卡数据的命令行工具。同样，Claude 最初尝试通过模糊测试代码来发现漏洞，失败后又尝试手动分析。和之前一样，当这些方法不奏效时，Claude 采取了不同的方法：它开始在仓库中搜索经常存在漏洞的函数调用。

让我看看 URL 在哪里被使用——特别是 strrchr 和 strcat 操作，它们可能存在路径遍历或缓冲区溢出问题。

Claude 迅速识别出一个连续使用多个 strcat 操作的位置。在 C 语言中，这些函数通常被认为是不安全的，因为它们允许连接字符串而不检查结果连接字符串的长度。因此，程序员验证输出缓冲区是否足够长以容纳连接后的输入至关重要。对于 OpenSC，关键问题在于以下代码：

char filename[PATH_MAX]; // 这个缓冲区是 4096 字节 r = sc_get_cache_dir(card->ctx, filename, sizeof(filename) - strlen(fp) - 2); if (r != SC_SUCCESS) goto err; strcat(filename,"/"); strcat(filename,fp);

Claude 识别出这容易受到缓冲区溢出的攻击。当我们查看现有模糊测试器测试这行代码的频率统计数据时，我们发现由于需要满足许多前置条件，传统模糊测试器很少研究这行代码。相比之下，Claude 能够推理哪些代码片段值得关注并集中精力，而不是不加区分地以同等精力研究所有代码行。

CGIF 是一个用于处理 GIF 文件的库。在这个案例中，令我们惊讶的不是 Claude 如何发现这个漏洞，而是它如何验证这个漏洞并生成概念验证，证明该漏洞是真实存在的。

简而言之，Claude 发现这个库假设压缩数据总是小于其原始大小（这通常是一个安全的假设），并且这个假设可以被利用。它做到这一点的方式颇具挑战性。GIF 文件格式使用 LZW 压缩算法压缩数据。与更传统的基于 LZ77 的压缩器（使用（距离，长度）对来编码匹配）不同，LZW 构建一个常用令牌对（可以是单个字符或令牌对）的字典。然后，当压缩器再次遇到这个令牌时，它可以输出一个更短的比特串，表示"再次输出此令牌"。（对于熟悉语言建模的人来说，LZW 在精神上与 BPE 分词过程非常相似。）

CGIF 隐含地假设压缩字符串的压缩大小总是小于未压缩大小——这几乎总是成立的。然而，Claude 立即识别出了这里的漏洞：

`要触发溢出，我们需要：

• 小的 numPixel（小图像） • 写入许多 LZW 代码

生成最多 LZW 代码的模式是：

• 没有压缩发生（每个像素变成一个代码） • 发生多次重置

使用 4 种颜色的调色板（索引 0-3）：

• initDictLen = 4 • 字典在 MAX_DICT_LEN (4096) 个条目后填满 • 当字典达到 4096 时发生重置

要用小图像触发溢出：

• numPixel = N • 缓冲区大小 = (N + 2) 个代码 • 我们需要生成 > N + 1 个代码

每个像素可以生成 1 个代码 + 重置。

但可能导致更多代码的模式是当我们有长度为 1 的序列时。`

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

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

安全保障措施

Safeguards

随着 Claude Opus 4.6 的发布，我们引入了一层新的检测机制，以支持我们的安全保障团队识别和应对 Claude 的网络滥用行为。这项工作的核心是探针，它们测量模型在生成响应时的内部激活状态，使我们能够大规模检测特定危害。在此次发布中，我们创建了新的网络特定探针，以更好地追踪和理解 Claude 在网络安全领域可能被滥用的方式。

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

总的来说，这些变化代表着我们在防止滥用能力方面迈出了有意义的一步：不仅在于我们能检测到什么，还在于我们能多快、多有效地对我们发现的问题采取行动。

结论

Conclusion

Claude Opus 4.6 能够在经过充分测试的代码库中发现有意义的零日漏洞，即使没有专门的脚手架。我们的结果表明，语言模型可以在现有发现工具的基础上增加真正的价值。我们上面描述的安全保障工作对于管理由此产生的双重用途风险至关重要。

展望未来，我们和更广泛的安全社区都需要面对一个令人不安的现实：语言模型已经能够识别新颖的漏洞，并且可能很快在速度和规模上超越甚至最专业的人类研究员。

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

这是一项持续的工作，我们很快将分享更多内容——包括我们关于这些能力如何演变以及安全社区如何最好地利用它们的经验教训。

编辑于 2026 年 2 月 6 日：

更新了作者列表