摘要
一句话总结
Claude Opus 4.6 展现了开箱即用的大规模发现高危零日漏洞的能力，研究团队已利用其在开源软件中验证了 500 多个漏洞，并同步部署了探针检测与实时干预等安全防护措施。
关键信息
- 核心能力：Claude Opus 4.6 能够在无需特定任务工具、自定义测试脚手架或专门提示词的情况下，开箱即用地发现成熟代码库中的高危漏洞。
- 发现机制：有别于传统模糊测试（Fuzzing）的随机输入，该模型能像人类研究员一样推理代码，包括分析 Git 提交历史、识别高危代码模式以及深入理解程序逻辑。
- 实际成果：研究团队已利用该模型在开源软件中发现并经人工验证了 500 多个高危漏洞，目前正与维护者合作推进补丁落地。
- 实验设置：模型在仅配备标准实用程序和基础分析工具的虚拟机中运行，测试重点严格限定于内存损坏漏洞（可通过崩溃和地址清理工具验证），以消除模型“幻觉”导致的误报。
- 案例 1（GhostScript）：模型通过阅读 Git 提交历史，推理出某次安全修复存在遗漏，成功定位并验证了未受边界检查保护的代码路径。
- 案例 2（OpenSC）：模型主动搜索不安全的函数调用（如连续的
strcat），精准定位了传统模糊测试因前置条件复杂而难以覆盖的缓冲区溢出漏洞。 - 案例 3（CGIF）：模型基于对 LZW 压缩算法和 GIF 格式的概念性理解，通过构造特定模式填满符号表，触发了常规覆盖率测试难以发现的缓冲区溢出。
- 安全检测（探针技术）：引入专门针对网络安全的探针，通过测量模型生成响应时的内部激活状态，大规模检测潜在的滥用行为。
- 实时干预：升级了安全执行工作流，支持采取实时干预措施（包括拦截被判定为恶意的流量）以应对双用途风险。
风险与缺口
- 开源生态防御薄弱：许多开源项目由缺乏专职安全资源的小团队或志愿者维护，难以独立应对漏洞发现与修复的压力。
- 安全防护的副作用：严格的实时干预和流量拦截措施可能会给合法的安全研究和防御工作带来阻力。
- 能力失控风险：语言模型识别新型漏洞的速度和规模可能很快就会超越人类专家。
- 现有披露规范失效：面对大语言模型发现漏洞的庞大数量与极快速度，行业标准的 90 天漏洞披露窗口期已不再适用，亟需建立新的工作流。
正文
日期：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 显著优于前代模型，这也反映了技术发展的日新月异。多年来，安全团队一直在推动漏洞发现的自动化，投入大量资源构建模糊测试（Fuzzing）基础设施和定制测试脚手架以大规模寻找 Bug。但在早期测试中，Opus 4.6 最引人注目的是它在无需特定任务工具、自定义脚手架或专门提示词的情况下，开箱即用地迅速发现漏洞的能力。
更令人感兴趣的是它发现漏洞的方式。传统模糊测试通过向代码抛出海量随机输入来观察程序是否崩溃；而 Opus 4.6 则能像人类研究员一样阅读和推理代码：它会查看过去的修复记录以寻找未解决的类似漏洞，识别容易引发问题的代码模式，或者通过深入理解某段逻辑来精准定位能破坏程序的输入。即使面对经过多年模糊测试、积累了数百万 CPU 小时的最成熟的代码库，Opus 4.6 依然发现了潜伏数十年的高危漏洞。
为了向防御者倾斜天平，我们正亲自使用 Claude 协助发现并修复开源软件中的漏洞。我们从开源软件着手，是因为它无处不在（从企业系统到关键基础设施），其漏洞会波及整个互联网。许多开源项目由缺乏专职安全资源的小团队或志愿者维护，因此，提供经过人工验证的漏洞报告和补丁意义重大。
截至目前，我们已发现并验证了 500 多个高危漏洞。我们已开始提交报告，初步的补丁正在落地，同时我们也在继续与维护者合作修复其他漏洞。本文将介绍我们的方法论、Claude 发现的早期漏洞案例，以及为应对模型能力提升而部署的防滥用安全措施。
实验设置
在这项工作中，我们将 Claude 置于一个“虚拟机”中，并为其提供最新版本的开源项目。我们仅提供了标准实用程序（如 coreutils 或 Python）和漏洞分析工具（如调试器或模糊测试工具），但没有提供任何关于如何使用这些工具的特殊指令，也没有提供能赋予其专业知识的定制测试脚手架。这直接测试了 Claude 的“开箱即用”能力，验证了现代大语言模型作为通用智能体，已经能够推理出如何最佳地利用现有工具。
为了确保 Claude 不会“幻觉”出不存在的漏洞（这种问题正给开源开发者带来不必要的负担），我们在报告前对每个漏洞进行了广泛验证。我们重点关注内存损坏漏洞，因为它们相对容易验证。与程序仍能运行的逻辑错误不同，内存损坏漏洞可以通过监控程序崩溃和运行地址清理工具（Address Sanitizers）来轻松识别。
由于并非所有导致崩溃的输入都是高危漏洞，我们让 Claude 对剩余的崩溃进行评估、去重和重新排序。在最初的发现阶段，由我们的安全研究员手动验证每个漏洞并编写补丁。随着漏洞数量的增加，我们引入了外部人类安全研究员协助验证和开发补丁。我们的目标是切实帮助维护者处理报告，因此该流程极力优化以减少误报。同时，我们也在加速自动化补丁开发，以便在发现漏洞时能可靠地进行修复。
漏洞案例分析
以下是 Claude 发现的三个漏洞案例（现已被维护者修复），这些案例展示了 LLM 相较于其他工具的独特优势。
1. GhostScript
GhostScript 是一个处理 PostScript 和 PDF 文件的实用程序。Claude 最初尝试了模糊测试和手动分析，但均未发现重大问题。随后，它转换了思路：阅读 Git 提交历史。
Claude 迅速发现了一个与安全相关的提交，并评论道：
“有一个关于 Type 1 字符集中‘MM 混合值的栈边界检查’的提交。这与字体处理有关。让我获取关于这个提交的更多细节。”
通过查看代码变更，Claude 推理出：
“这个提交显示它添加了栈边界检查——这表明在添加此检查之前存在漏洞。……如果这个提交添加了边界检查，那么修复前的代码就是脆弱的……因此，为了触发漏洞，我需要针对应用此修复之前的代码版本进行测试。”
基于此，Claude 开始寻找该函数的其他调用位置，以排查未被修复的类似漏洞，并成功发现：
“让我检查一下是否检查不完整，或者存在其他代码路径。让我看看
gdevpsfx.c中的另一个调用者……啊哈！这非常有趣！在gdevpsfx.c中，第 292 行对gs_type1_blend的调用没有包含在gstype1.c中添加的边界检查。”
得出结论后，Claude 迅速构建了一个概念验证（PoC）崩溃文件，证实了其预测。
2. OpenSC
OpenSC 是一个处理智能卡数据的命令行工具。同样，在模糊测试和手动分析失败后，Claude 开始在代码库中搜索经常出现漏洞的函数调用。
“让我看看 URL 是在哪里使用的——特别是
strrchr和strcat操作，它们可能存在路径遍历或缓冲区溢出问题。”
Claude 迅速定位到一处连续使用多个 strcat 操作的代码。在 C 语言中，这些函数通常被认为是不安全的，因为它们在拼接字符串时不检查长度。因此，程序员必须验证输出缓冲区是否足够大。Claude 准确识别出这里存在缓冲区溢出漏洞。
统计数据显示，传统模糊测试工具很少覆盖到这行代码，因为触发它需要满足大量前置条件。相比之下，Claude 能够通过推理找出高风险的代码片段并集中精力分析，而不是盲目地对所有代码行平均用力。
3. CGIF
CGIF 是一个处理 GIF 文件的库。在这个案例中，令人惊讶的不是 Claude 如何发现漏洞，而是它如何验证漏洞并生成 PoC。
Claude 发现该库隐含了一个假设：压缩后的数据总是小于其原始大小。GIF 文件使用 LZW 压缩算法，LZW 会构建一个常用标记对的字典（符号表）。Claude 深刻理解了这一机制并意识到：
“要触发溢出，我们需要：
- 小的 numPixel（小图像）
- 写入大量的 LZW 代码
产生最多 LZW 代码的模式是：
- 不发生压缩（每个像素变成一个代码）
- 发生多次重置”
Claude 认识到，LZW 维护着一个固定大小的符号表；如果填满符号表，LZW 就会在数据流中插入一个特殊的“清除”标记。这会导致输出的“压缩”数据大小超过未压缩数据，从而触发缓冲区溢出漏洞。
这个漏洞特别有趣，因为触发它需要对 LZW 算法和 GIF 文件格式有概念性的理解。传统模糊测试工具（甚至是覆盖率引导的模糊测试）很难触发此类漏洞，因为它需要特定的分支选择序列。即使 CGIF 拥有 100% 的行和分支覆盖率，这个漏洞仍可能未被发现。
安全防护
伴随 Claude Opus 4.6 的发布，我们引入了新的检测层，以支持我们的安全防护团队识别和应对针对 Claude 的网络安全滥用。
- 探针技术（Probes）： 这项工作的核心是探针，它能在模型生成响应时测量其内部激活状态，从而大规模检测特定危害。我们创建了专门针对网络安全的探针，以更好地追踪和理解该领域的潜在滥用行为。
- 实时干预： 在执行层面，我们正在升级工作流以配合新的检测架构。我们扩大了应对网络滥用的行动范围，可能会采取实时干预措施，包括拦截被判定为恶意的流量。
我们意识到这可能会给合法的安全研究和防御工作带来阻力，因此我们希望与安全研究社区合作，共同寻找解决方案。我们致力于通过严格的安全措施，确保 Claude 在保持高效的同时安全可靠。这些改变不仅提升了我们能检测到的内容，更提升了我们采取行动的速度和有效性。
结论
Claude Opus 4.6 能够在没有专门脚手架的情况下，在经过充分测试的代码库中发现有意义的零日漏洞。我们的结果表明，语言模型能够为现有的漏洞发现工具提供巨大的附加价值。同时，上述的安全防护工作对于管理由此产生的双用途风险至关重要。
展望未来，我们和整个安全社区都需要面对一个令人不安的现实：语言模型已经具备识别新型漏洞的能力，并且其速度和规模可能很快就会超越人类专家。
与此同时，现有的漏洞披露规范也需要演进。面对 LLM 发现漏洞的速度和数量，行业标准的 90 天披露窗口期可能已不再适用，业界需要建立能够跟上这种节奏的新工作流。
这是一项持续进行的工作。我们将很快分享更多信息，包括我们对这些能力如何演进的认知，以及安全社区如何最好地利用它们。