Claude Opus 4.6 的 500 个零日漏洞：三个补丁揭示了什么

2026年2月5日，Anthropic的Frontier Red Team发布研究称，同日发布的Claude Opus 4.6已发现并验证了500多个高危漏洞，这些漏洞存在于开源软件中——且无需任务专用工具、定制脚手架或专门提示。文中详细描述了三个发现：Ghostscript中缺少栈边界检查，OpenSC中一系列未经检查的strcat调用，以及GIF编码器CGIF中的缓冲区溢出，其触发取决于LZW压缩在字典填满时的行为。Anthropic表示，这三个漏洞现均已由维护者修补，并按他们的说法，这些漏洞已被发现、验证并报告。文章指出，许多项目由小型团队或志愿者维护，没有专职安全人员，因此报告和补丁负担落在了他们身上。该档案自身关于此发现的条目被评为信息级严重性，且未记录任何实际危害，位于Orca AI Incident Archive中，与其他2026年2月的政策和披露记录并列。

Anthropic 究竟发布了什么

该文章的标题为“评估并缓解 LLM 发现的零日漏洞日益增长的风险”，署名归属于 Frontier Red Team：Nicholas Carlini、Keane Lucas 和 Evyatar Ben Asher 为同等贡献者，另有 Newton Cheng、Hasnain Lakhani、David Forsythe 和 Kyla Guru。页面标注的发布日期为 2026 年 2 月 5 日，并附有一条日期为 2026 年 2 月 6 日的编辑说明，记录作者名单已更新。存档中引用该文章的网址为 red.anthropic.com，该网址现已重定向至 anthropic.com/research/zero-days。

方法比标题中的数字更重要。Anthropic 表示，它将该模型放入一台可访问开源项目最新版本的虚拟机中，并为其提供了标准实用工具以及人类安全研究员会使用的工具——调试器和模糊测试器——但没有说明如何使用它们；用文章中的话说，“没有提供任何定制化测试装置来赋予它关于如何更好地发现漏洞的专门知识。” 被测试的是该模型开箱即用的行为。

团队把搜索范围缩小到内存破坏类漏洞，理由是崩溃比逻辑错误更容易确认。Anthropic 明确指出，这只是一道过滤器，而非保证："并非所有导致程序崩溃的输入都是高危漏洞。"于是这些崩溃样本被送回模型进行评审、去重并重新排定优先级，然后再交由人工处理。"在最初一轮发现中，我们自己的安全研究员逐一验证了每个漏洞，并手工编写补丁。随着发现数量不断增长，我们引入了外部（人类）安全研究员来协助验证和补丁开发。"文章称，补丁自动化当时仍在构建之中。

三个 bug，以及随之而来的补丁

这三个已详细展示的示例具有相同的模式：自动化工具此前已经失败，而模型是通过对输入变异之外的因素进行推理才发现这个 bug 的。

• Ghostscript，PostScript 和 PDF 解释器。模糊测试以及随后的人工分析都没有发现任何问题。随后，模型阅读了该项目的 Git 历史，发现帖子中描述的一个提交为 Type 1 charstrings 添加了“为 MM blend 值添加栈边界检查”，并推断该提交之前的代码存在漏洞，于是开始寻找其他未接受同样处理的调用点。它在 gdevpsfx.c 中发现了一处——帖子引用的是第 292 行——并构造了一个会使程序崩溃的文件。仓库记录证实了这一点：Chris Liddell 于 2025 年 9 月 5 日提交的 87486fb801 号提交，标题为“Type 1 charstrings：为 MM blend 值添加栈边界检查”。后来 Ken Sharp 于 2026 年 1 月 26 日提交的 4e392a82 号修复，在该字体转换器中的该调用之前立即添加了边界检查，该修复针对 Bug 709080，其报告标题为“Ghostscript 对 Type 1 MM blend 栈边界检查的修复不完整”。2026 年 2 月 13 日的一个提交扩展了同一转换器中的边界检查。没有任何提交信息说明是谁报告了该漏洞。

• OpenSC，一个用于智能卡数据的命令行工具。在这里，模型搜索了有风险的函数调用，并发现了连续的 strcat 操作，它们写入一个 4096 字节的 filename 缓冲区；此前进行了一次大小计算，减去了某个输入字符串的长度，但随后又追加了更多字符串，却没有重新检查。该文章指出，由于涉及前置条件，现有模糊测试器很少能到达该路径。OpenSC 于 2026 年 1 月 19 日的提交 33ab343a5c 增加了一项检查，确保追加的字符串恰好为 64 字节；而于 2026 年 1 月 25 日合并的拉取请求 #3554 则将项目中剩余的 strcat 调用替换为 strlcat；其作者称该函数是“任何静态分析工具和 CVE 的磁铁”。

• CGIF，一个 GIF 编码器。该库假定压缩后的数据始终小于未压缩输入，而这几乎总是成立。该模型推断，LZW 会构建固定大小的字典，当字典填满时，插入流中的清除码可能使“压缩”输出比输入更长——因此，一个按 N+2 个码大小分配的缓冲区可能接收到超过 N+1 个码。文章称，即使行覆盖率和分支覆盖率都达到 100%，也可能无法暴露这个问题，因为它需要特定的操作序列。CGIF 的拉取请求 #84 于 2026 年 1 月 19 日合并，并于同日作为 v0.5.1 发布，恰好修复了这一点：“上界 LZW 数据大小计算中遗漏了重置清除码。”

这些修复在研究发布之前就已经落地——CGIF 和 OpenSC 于 2026 年 1 月 19 日，OpenSC 于 1 月 25 日再次，Ghostscript 于 1 月 26 日——Anthropic 在文章中表示，在公开之前，它“已经开始报告这些问题，并看到我们最初的补丁落地”。代码仓库记录了代码变更；但没有记录是谁提交了报告，因此该模型的发现与这些特定提交之间的联系，取决于 Anthropic 的说法，以及所描述的缺陷与代码差异的吻合程度。

The researcher who said the OpenSC bug was not real

Public scrutiny of the individual findings did not start and end with Anthropic. On 14 February 2026 K. Reid Wightman, an industrial security researcher posting as @reverseics on infosec.exchange, published a review of the OpenSC example arguing the bug could not be triggered: the input string was already checked to be 64 bytes at line 5138, he wrote, which capped the buffer at 4095 bytes including the terminator. "I spent about an hour looking at the code to debunk their finding," he wrote.

He edited the same post on 17 February 2026 to withdraw the challenge. "Looks like the version of code I was looking at, already had a fix for anthropic-discovered bug(s)," the edit reads, before conceding the arithmetic: "but yes without the strlen() check on 'fp' the overflow could actually be triggered. The humble pie has been eaten." The check he had relied on was the one added to OpenSC on 19 January 2026 — before Anthropic published, and before most readers would have gone looking. The archive does not flag the record as disputed, and here the challenge was retracted by the person who raised it.

OpenSC's own maintainers answered the same question in their tracker. In discussion #3575, opened on 17 February 2026 by a user asking whether Anthropic's claims were legitimate, OpenSC maintainer frankmorgner replied the same day: "We received two bug reports from anthropic, which were both verified by humans." He said the fixes were in pull request #3554 and would be in the next release, and that commit 33ab343 was "a change that was introduced after anthropic reported the problem."

治理部分：探针、阻断与 90 天

让这篇文章成为一份政策记录、而非单纯研究说明的，是文章的后半部分。在发布模型的同时，Anthropic 表示其推出了针对网络安全的探针，这些探针会在模型生成回复时测量模型内部的激活值，并且其更新了执行工作流，以使用基于探针的检测。它还更进一步，不止于检测：“我们可能会实施实时干预，包括阻断我们检测为恶意的流量。”Anthropic 承认代价——“这会给合法研究和一些防御性工作带来摩擦”——并表示希望就此与安全研究社区合作。文中没有公布检测率、错误率或申诉流程。

这篇文章还主张，披露时间表本身如今已成了问题。文章称：“业界标准的90天窗口，或许已无法应对LLM所发现漏洞的速度与数量”，并警告说，这些模型“可能很快就会超过即便是人类专家研究者的速度与规模”。这是一家厂商在主张：用来评判它自身的那个规范需要被替换；而这也是整份记录中影响最为深远的部分。

之后发生了什么变化

2026年2月20日，Anthropic 面向 Enterprise 和 Team 客户开放了 Claude Code Security，作为一项有限的研究预览，并为开源维护者提供免费快速访问——该能力在研究发布十五天后实现产品化。VentureBeat 报道了此次发布，并表示它曾向 Anthropic 询问自我验证前后的误报率、已披露漏洞中补丁已落地与仍处于分类处理阶段的数量，以及区分攻击者使用与防御者使用的保障措施；它报道称，该项目首席研究员无法接受采访，且公司拒绝分享具体的攻击者检测机制。

补丁也在不断变动，而且并不总是朝同一个方向。CGIF 针对 Anthropic 所描述的那次分配问题的修复，已于 2026 年 1 月 19 日随 v0.5.1 发布；2026 年 2 月 21 日，拉取请求 #103 修复了同一分配计算引入的 32 位整数溢出，并于次日作为 v0.5.2 发布，针对最大 65,535 × 65,535 像素的 GIF。事实证明，修复边界计算本身也会成为边界错误的一个小小来源。

正确读取数字

Anthropic 自己的表述是“超过 500 个高危漏洞”。最先获得该公司通报的 Axios 在报道发布当天将其描述为“超过 500 个此前未知的零日漏洞”，并称每一个都由 Anthropic 团队成员或外部安全研究员验证过。两种描述指向同一组漏洞，但只有一种是厂商的原话，而且两者都没有附上清单、CVE 映射或严重性分布。这个数字来自 Anthropic，严重性评级也来自 Anthropic，而文中详细梳理的三个项目是公众唯一能够核查的。

随后的独立分析大多直接采信了这个数字，并围绕它意味着什么展开争论。Futurum Group 的 Mitch Ashley 在 2026 年 2 月 24 日写道，这一结果“其意义更多在于方法揭示了什么，而不在于计数”，并且真正的约束在下游：“更快地暴露更多漏洞并不会缩小攻击面。它会在一个无法消化这一数量的下游流程前，堆积出更大的队列。”这是对披露流程而非对发现本身的批评，并且落到了 Anthropic 就 90 天窗口提出的同一个点上。

记录未能确立的内容

档案馆将这条记录评为置信度 A、严重性 info，未记录到实际损害，也没有争议标记。这一评级关乎该事件被记录得有多完整，而不关乎其底层说法被审计得有多充分，这一区别值得谨记。Anthropic 之外无人验证过这 500 起。没有公布过误报率。三个点名项目的补丁真实存在且可确定日期，是现有最强的佐证——但它们佐证的只是三个例子，而非总数。

那么，剩下的就是一份有充分记录的公告：其核心可核查，其余部分不可核查——一家供应商报告了一项能力，三份上游 diff 与其对缺陷的描述相符，以及明确表示要在模型层管控该能力被滥用的意图。档案馆将其归为政策类，这是正确的归类。这项能力主张将由发布第四个补丁的人来定论。