评估与应对 LLM 发现零日漏洞的日益增长的风险¶
原文：Evaluating and mitigating the growing risk of LLM-discovered 0-days
作者：Nicholas Carlini*, Keane Lucas*, Evyatar Ben Asher*, Newton Cheng, Hasnain Lakhani, David Forsythe, and Kyla Guru（*表示同等贡献）
团队：Frontier Red Team, Anthropic
发布日期：2026年2月5日
引言¶
AI 模型已经能够大规模发现高严重性漏洞，防御者必须抢在攻击者之前行动。 今天发布的 Claude Opus 4.6 延续了 AI 模型网络安全能力持续显著提升的轨迹。去年秋天，我们曾指出我们正处于 AI 对网络安全产生影响的拐点——进展可能非常迅速，现在正是加速 AI 防御性应用的时刻。此后的种种证据只是进一步印证了这一判断。AI 模型现在已经能够大规模发现高严重性漏洞。我们认为，当前是一个需要快速行动的窗口期——赋能防御者，尽可能多地保护代码安全。
Opus 4.6 无需专用工具或定制框架，开箱即用就能发现高危漏洞，而且其发现方式更接近人类安全研究员的推理过程。 Opus 4.6 在发现高严重性漏洞方面明显优于此前的模型，体现了技术演进的速度之快。多年来，安全团队一直在投入大量资源建设模糊测试（fuzzing）基础设施和定制工具来自动化漏洞发现。但在早期测试中最令人瞩目的是：Opus 4.6 在没有任务专用工具、定制框架或专门提示词的情况下，开箱即用就能快速发现漏洞。更值得关注的是它如何找到这些漏洞。模糊测试器通过向代码投入海量随机输入来观察什么会出错；而 Opus 4.6 则像人类研究员一样阅读并推理代码——查看过去的修复以发现类似的未修复漏洞、识别容易引发问题的代码模式、或者深入理解一段逻辑从而精确知道什么输入会破坏它。当我们将 Opus 4.6 指向一些测试最充分的代码库（这些项目已经有模糊测试器运行多年，累计了数百万小时的 CPU 时间），Opus 4.6 仍然发现了高严重性漏洞，其中一些已经潜伏了数十年未被发现。
Anthropic 已开始主动用 Claude 发现并帮助修复开源软件中的漏洞，目前已验证超过 500 个高危漏洞。 倾斜天平向防御者一方意味着我们自己也要付诸行动。我们正在使用 Claude 发现并帮助修复开源软件中的漏洞。之所以从开源软件入手，是因为它无处不在——从企业系统到关键基础设施——开源中的漏洞会在互联网上产生连锁反应。这些项目中有很多由小团队或志愿者维护，缺乏专门的安全资源，因此发现经过人工验证的漏洞并贡献经过人工审查的补丁能产生巨大价值。
迄今为止，我们已经发现并验证了超过 500 个高严重性漏洞。我们已开始向维护者提交报告，部分初始补丁已经合入，同时我们正继续与维护者合作修复其余漏洞。在本文中，我们将介绍研究方法、分享 Claude 发现的一些早期漏洞案例，并讨论随着能力持续提升我们为防范滥用所采取的安全措施。这只是我们工作的开始，随着规模扩大，我们还会分享更多成果。
实验设置¶
Claude 被放入虚拟机中，仅配备标准工具和漏洞分析工具，没有任何专门指导，纯粹测试其开箱即用的能力。 在这项工作中，我们将 Claude 放入一台"虚拟机"（一台模拟计算机）中，使其能够访问开源项目的最新版本。我们提供了标准实用工具（如 coreutils 或 Python）和漏洞分析工具（如调试器或模糊测试器），但没有提供任何关于如何使用这些工具的特殊指导，也没有提供可以给予其关于如何更好发现漏洞的专业知识的定制工具。这意味着我们直接测试的是 Claude 的"开箱即用"能力，完全依赖于现代大语言模型作为通用智能体、已经能够推理如何最佳利用可用工具的事实。
为确保结果可靠，每个漏洞都经过严格的多阶段验证流程，由人类安全研究员最终把关。 为了确保 Claude 没有"幻觉"出不存在的漏洞（这个问题正日益给开源开发者带来不必要的负担），我们在报告之前对每个漏洞进行了充分验证。我们专注于搜索内存损坏漏洞，因为它们相对容易验证——与程序仍能正常运行的逻辑错误不同，内存损坏漏洞可以通过监控程序崩溃和运行地址消毒器（address sanitizer）等工具来轻松识别非崩溃类内存错误。但由于并非所有导致程序崩溃的输入都是高严重性漏洞，我们随后让 Claude 对剩余的崩溃进行批判性评审、去重和重新排序。最后，在初始轮次的发现中，我们的安全研究员逐一验证每个漏洞并手工编写补丁。随着发现量的增长，我们引入了外部（人类）安全研究员来协助验证和补丁开发。我们的目的是切实帮助维护者处理我们的报告，因此流程着力于减少误报。与此同时，我们正在加速推进补丁开发自动化，以便在发现漏洞时能够可靠地进行修复。
漏洞案例¶
以下三个已修复的漏洞案例展示了 LLM 相对于传统工具的独特优势。
GhostScript：通过阅读 Git 提交历史发现遗漏的安全修复¶
Claude 通过阅读 Git 提交历史，发现了一处安全修复未覆盖到的同类代码路径。 GhostScript 是一个处理 PostScript 和 PDF 文件的工具。Claude 最初在寻找漏洞时走了几条弯路——先是尝试模糊测试，失败后又尝试手动分析，两种方法都没有产生显著发现。然而最终，Claude 采取了不同的策略：阅读 Git 提交历史。Claude 很快找到了一个与安全相关的提交，并评论道：
有一个关于"Type 1 charstrings 中 MM blend 值的栈边界检查"的提交。这与字体处理相关。让我获取这个提交的更多细节。
随后，Claude 查看了代码以理解变更内容：
提交显示它添加了栈边界检查——这表明在添加此检查之前存在漏洞。……如果这个提交添加了边界检查，那么此修复之前的代码是有漏洞的……所以要触发该漏洞，我需要针对此修复之前的代码版本进行测试。
基于这一思路，Claude 进一步查找了该函数在其他位置的调用，以发现可能存在的类似但未修复的漏洞。
让我检查一下是否存在检查不完整或有其他代码路径的情况。让我看看 gdevpsfx.c 中的另一个调用者……太有意思了！在 gdevpsfx.c 中，第 292 行对 gs_type1_blend 的调用没有添加 gstype1.c 中新增的边界检查。
做出这一观察后，Claude 迅速构造了一个概念验证崩溃（一个传递给 GhostScript 即可导致其崩溃的文件），证实了它的推断。
OpenSC：识别传统模糊测试难以覆盖的缓冲区溢出¶
Claude 通过搜索常见危险函数调用模式，发现了一个因前置条件过多而难以被模糊测试覆盖到的缓冲区溢出漏洞。 OpenSC 是一个处理智能卡数据的命令行工具。同样地，Claude 最初尝试通过模糊测试寻找漏洞，失败后转为手动分析。当这也行不通时，Claude 换了一种思路：开始在代码库中搜索那些经常出现漏洞的函数调用。
让我看看 URL 在哪里被使用——特别是 strrchr 和 strcat 操作，它们可能存在路径遍历或缓冲区溢出问题。
Claude 很快定位到了一个连续使用多个 strcat 操作的位置。这些函数在 C 语言中通常被认为是不安全的，因为它们允许在不检查结果字符串长度的情况下拼接字符串。因此，程序员验证输出缓冲区是否足够大以容纳拼接后的输入至关重要。对于 OpenSC，关键问题在以下代码中：
char filename[PATH_MAX]; // this buffer is 4096 bytes
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：利用对 LZW 算法的概念性理解构造溢出¶
Claude 凭借对 LZW 压缩算法的深层理解，构造出一个利用"压缩后数据大于原始数据"这一罕见情况的概念验证漏洞。 CGIF 是一个处理 GIF 文件的库。在这个案例中，令我们惊讶的不是 Claude 如何发现了漏洞，而是它如何验证了漏洞并生成了证明漏洞真实存在的概念验证代码。
简而言之，Claude 发现这个库假设压缩数据总是小于原始数据大小（通常这是一个安全的假设），而这个假设可以被利用。实现这一点的方式很有挑战性。GIF 文件格式使用 LZW 压缩算法对数据进行压缩。与更传统的基于 LZ77 的压缩器使用（距离，长度）对编码匹配不同，LZW 构建一个经常使用的标记对（token pair）的字典（可以是单个字符，也可以是标记对）。当压缩器第二次遇到该标记时，它可以输出一个更短的位串表示"再次输出这个标记"。（对于熟悉语言模型的读者，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 就会在数据流中插入一个特殊的"清除"（clear）标记。这会导致"压缩"后的输出大小超过未压缩大小——从而触发缓冲区溢出漏洞。
这个漏洞特别有趣，因为触发它需要对 LZW 算法及其与 GIF 文件格式的关系有概念性的理解。传统模糊测试器（甚至覆盖引导的模糊测试器）难以触发这类漏洞，因为它们需要做出特定的分支选择。事实上，即使 CGIF 达到了 100% 的行覆盖率和分支覆盖率，这个漏洞仍可能未被发现：它需要一个非常特定的操作序列。
安全措施¶
伴随 Opus 4.6 的发布，Anthropic 引入了基于模型激活值探针（probe）的新检测层，用于识别和响应网络安全领域的潜在滥用。 在发布 Claude Opus 4.6 的同时，我们引入了新的检测层来支持安全保障团队识别和响应 Claude 的网络安全滥用行为。这项工作的核心是探针（probes），它们在模型生成响应时测量模型内部的激活值，使我们能够大规模检测特定有害行为。在本次发布中，我们创建了新的网络安全专用探针，以更好地追踪和理解 Claude 在网络安全领域的潜在滥用情况。
在执行层面，Anthropic 正在扩展响应手段，包括实时干预和阻断恶意流量，同时承诺与安全研究社区合作减少对合法研究的影响。 在执行层面，我们正在升级我们的处理流程以跟上这种新的检测架构。这包括更新网络安全执行工作流以利用基于探针的检测，以及扩展我们对网络安全滥用的响应措施范围。特别是，我们可能会实施实时干预，包括阻断我们检测到的恶意流量。这会给合法的安全研究和部分防御性工作带来阻力，我们希望与安全研究社区合作，在问题出现时找到解决方案。我们致力于通过努力使 Claude 既安全又高效，保持其在网络安全领域的前沿地位。
这些变化共同代表了我们在防止滥用能力上的重要进步：不仅体现在我们能检测到什么，还体现在我们能以多快、多有效的方式对发现做出响应。
结论¶
Claude Opus 4.6 已能在充分测试的代码库中发现有意义的零日漏洞，行业需要为 LLM 驱动的漏洞发现时代做好准备。 Claude Opus 4.6 即使没有专门的框架支撑，也能在经过充分测试的代码库中发现有意义的零日漏洞。我们的结果表明，语言模型可以在现有漏洞发现工具之上增添真正的价值。上述安全保障工作对于管理由此产生的双重用途风险至关重要。
展望未来，我们和更广泛的安全社区都需要面对一个不太舒适的现实：语言模型已经具备发现新型漏洞的能力，并且可能很快将在速度和规模上超越即使是最顶尖的人类研究人员。
与此同时，现有的漏洞披露规范也需要演进。行业标准的 90 天披露窗口可能无法应对 LLM 发现漏洞的速度和数量，行业需要能够跟上这一节奏的工作流程。
这是一项持续进行的工作，我们很快会分享更多内容——包括我们对这些能力如何演进的观察，以及安全社区如何最佳地加以利用。
编辑于 2026年2月6日：更新了作者列表
关键数据汇总¶
| 指标 | 数值 |
|---|---|
| 已发现并验证的高危漏洞数量 | 500+ |
| GhostScript 漏洞位置（gdevpsfx.c） | 第 292 行 |
| OpenSC PATH_MAX 缓冲区大小 | 4,096 字节 |
| CGIF LZW MAX_DICT_LEN | 4,096 条目 |
| 行业标准漏洞披露窗口 | 90 天 |
| OSS-Fuzz 累计 CPU 时间 | 数百万小时 |