Anthropic红队为Firefox浏览器进行安全加固

AI 模型如今已经能够独立识别复杂软件中的高危漏洞。正如我们最近所披露的，Claude 在经过充分测试的开源软件中发现了 500 多个零日漏洞（软件维护者尚不知晓的安全缺陷）。

本文将分享我们与 Mozilla 研究人员合作的详细情况。在为期两周的合作中，Claude Opus 4.6 发现了 22 个漏洞。其中，Mozilla 将 14 个评定为高危漏洞——接近 2025 年 Firefox 修复的全部高危漏洞的五分之一。换句话说：AI 正在让我们以前所未有的速度发现严重安全漏洞。

在这次合作中，Mozilla 接收了我们提交的大量报告，帮助我们理解哪些类型的发现值得提交 bug 报告，并通过 Firefox 148.0 向数亿用户推送了修复。他们的合作，以及我们从中学到的技术经验，为 AI 赋能的安全研究人员与软件维护者如何携手应对这一关键时刻提供了范例。

从模型评估到安全合作

2025 年末，我们注意到 Opus 4.5 已经接近解决 CyberGym 中的所有任务。CyberGym 是一个用于测试 LLM 能否复现已知安全漏洞的 benchmark。我们希望构建一个难度更高、更加贴近现实的评估，其中包含更多技术复杂度较高的漏洞，例如现代 Web 浏览器中的漏洞。于是，我们基于 Firefox 过去的常见漏洞与披露（CVE）构建了一个数据集，用来检验 Claude 能否复现这些漏洞。

我们选择 Firefox，是因为它不仅拥有复杂的代码库，还是全球测试最充分、最安全的开源项目之一。与我们此前用来测试模型的开源软件相比，这使得 Firefox 更适合作为检验 AI 发现全新安全漏洞能力的高难度测试。每天都有数亿用户依赖 Firefox，而浏览器漏洞尤其危险，因为用户经常会接触不受信任的内容，并依靠浏览器保障自身安全。

第一步，我们让 Claude 在旧版本 Firefox 代码库中寻找此前已经确认的 CVE。Opus 4.6 能够复现相当高比例的历史 CVE，这令我们十分惊讶，因为其中每一个漏洞当初都需要投入大量人力才能发现。但我们仍不清楚应该在多大程度上相信这一结果，因为至少有一部分历史 CVE 可能已经存在于 Claude 的训练数据中。

因此，我们要求 Claude 在当前版本的 Firefox 中寻找全新的漏洞——按照定义，这些 bug 此前不可能被报告过。我们首先将重点放在 Firefox 的 JavaScript 引擎上，随后扩展到浏览器的其他部分。JavaScript 引擎是一个适合起步的目标：它是 Firefox 代码库中可以独立分析的部分；同时，由于攻击面广泛（用户浏览网页时，它会处理不受信任的外部代码），确保其安全也格外重要。

仅仅探索了 20 分钟后，Claude Opus 4.6 就报告称，它在 JavaScript 引擎中发现了一个 Use After Free（释放后使用）漏洞——这是一类内存漏洞，可能让攻击者使用任意恶意内容覆写数据。我们的一名研究人员在装有最新版 Firefox 的独立虚拟机中验证了这个 bug，随后将其转交给另外两名 Anthropic 研究人员，他们也确认了该漏洞。接着，我们在 Mozilla 的问题跟踪系统 Bugzilla 中提交了 bug 报告，并附上漏洞说明和建议的 patch（由 Claude 编写，经报告团队验证），以协助判断问题的根本原因。

就在我们验证并向 Firefox 提交第一个漏洞的这段时间里，Claude 已经又发现了 50 个不同的、能够导致程序崩溃的输入。在我们对这些崩溃进行分类处理时，一名 Mozilla 研究人员主动联系我们。我们围绕双方的工作流程进行了技术讨论，并分享了另外几个经过人工验证的漏洞。随后，他们鼓励我们批量提交所有发现，无须逐一验证，即使我们并不确定所有导致崩溃的测试用例都涉及安全问题。到这项工作结束时，我们已经扫描了近 6,000 个 C++ 文件，共提交了 112 份不同的报告，其中包括上文提到的高危和中危漏洞。大部分问题已在 Firefox 148 中修复，其余问题将在后续版本中修复。

在外部软件中开展这类 bug 挖掘时，我们始终清楚，自己可能遗漏了代码库中的某些关键信息，从而导致发现结果其实是假阳性。我们会尽职地自行验证这些 bug，但出错的可能性始终存在。我们非常感谢 Mozilla 如此透明地分享他们的分类处理流程，并帮助我们调整方法，确保只提交他们关注的测试用例——即便其中并非所有用例最终都与安全有关。此后，Mozilla 的研究人员也开始在内部尝试将 Claude 用于安全工作。

从识别漏洞到编写初级 exploit

为了衡量 Claude 网络安全能力的上限，我们还开发了一项新的评估，用来判断 Claude 能否利用我们发现的任何一个 bug。换句话说，我们想了解 Claude 是否也能开发出黑客用来利用这些 bug、执行恶意代码的工具。

为此，我们让 Claude 访问此前提交给 Mozilla 的漏洞，并要求它针对每个漏洞创建 exploit。为了证明自己成功利用了某个漏洞，我们要求 Claude 演示一次真实攻击。具体来说，它必须像攻击者一样，在目标系统中读取和写入本地文件。

我们从不同的起点出发，将这项测试运行了数百次，消耗了大约 4,000 美元的 API credits。即便如此，Opus 4.6 最终也只在两个案例中成功将漏洞转化为 exploit。这说明了两件事。第一，与利用这些 bug 相比，Claude 更擅长发现它们。第二，识别漏洞的成本比为漏洞创建 exploit 低一个数量级。然而，Claude 能够自动开发出粗糙的浏览器 exploit——哪怕只在少数案例中成功——仍然令人担忧。

这里必须强调一个重要的限定词：“粗糙”。Claude 编写的 exploit 只能在我们的测试环境中运行，而该环境有意移除了现代浏览器具备的一些安全功能。其中最重要的就是 sandbox，其目的正是减轻这类漏洞造成的影响。因此，Firefox 的“纵深防御”机制本可以有效缓解这些特定 exploit 的危害。不过，能够逃逸 sandbox 的漏洞并非闻所未闻，而 Claude 的攻击已经构成端到端 exploit 所必需的一个环节。你可以在我们的 Frontier Red Team 博客中进一步了解 Claude 是如何开发其中一个 Firefox exploit 的。

AI 赋能的网络安全下一步走向何方

AI 已经展现出的这些初步 exploit 开发能力，凸显了防守方加快漏洞发现与修复流程的重要性。为此，我们希望分享在本次分析过程中总结出的几项技术和流程最佳实践。

首先，在研究“patching agents”时，我们开发了几种方法，希望能帮助维护者使用 Claude 等 LLM，更快地分类处理安全报告并解决相关问题。所谓 patching agents，是指使用 LLM 开发并验证 bug 修复方案的 Agent。¹

根据我们的经验，当 Claude 能够借助另一种工具检查自己的工作时，表现最佳。我们将这类工具称为“task verifier”：它是一种可信的方法，用来确认 AI Agent 的输出是否真正达成了目标。task verifier 能够在 Agent 探索代码库时为其提供实时反馈，让它可以深入迭代，直至成功。

task verifier 帮助我们发现了上文所述的 Firefox 漏洞；²在另一项独立研究中，我们还发现，它们同样适用于修复 bug。优秀的 patching agent 至少需要验证两件事：漏洞是否真的已经被消除，以及程序的预期功能是否得到保留。在我们的工作中，我们构建了一些工具，用于自动测试应用建议的修复后是否仍能触发原始 bug；同时还单独运行测试套件，以捕获 regression（某项改动意外破坏了其他功能）。我们相信，维护者最清楚应该如何为自己的代码库构建这些 verifier；关键在于，为 Agent 提供一种可靠的方法来检查这两项属性，能够显著提升其输出质量。

我们无法保证所有通过这些测试的 Agent 生成 patch 都已经足够完善，可以立即 merge。但 task verifier 可以增强我们的信心：生成的 patch 能够在保留程序功能的同时修复特定漏洞，从而满足一份合理 patch 的最低要求。当然，在审核 AI 编写的 patch 时，我们建议维护者采用与审核任何外部作者提交的 patch 相同的严格标准。

再从更宏观的 bug 和 patch 提交流程来看：我们知道维护者早已不堪重负。因此，我们采取的方法是向维护者提供他们信任和验证报告所需的信息。Firefox 团队特别指出，我们提交的材料中有三个组成部分对于建立结果可信度至关重要：

• 随附的最小化测试用例

• 详细的概念验证

我们强烈建议使用 LLM 驱动的漏洞研究工具的研究人员，在根据此类工具的输出提交报告时，也提供类似的验证与可复现性证据。

我们还发布了 Coordinated Vulnerability Disclosure（协调漏洞披露，CVD）工作原则，介绍了与维护者合作时将采用的流程。目前，我们在这方面的流程遵循行业标准惯例，但随着模型不断进步，我们可能需要调整流程，以跟上模型能力的发展速度。

紧迫的当下

Frontier language model 如今已经成为世界一流的漏洞研究人员。除了在 Firefox 中识别出的 22 个 CVE，我们还使用 Claude Opus 4.6 在 Linux kernel 等其他重要软件项目中发现了漏洞。在接下来的数周和数月里，我们会继续分享自己如何运用这些模型，以及如何与开源社区合作提升安全性。

目前，Opus 4.6 在识别和修复漏洞方面的能力，远远强于利用漏洞的能力。这让防守方占据了优势。随着 Claude Code Security 最近以有限研究预览的形式发布，我们也开始将漏洞发现和 patching 能力直接提供给客户及开源软件维护者。

但从当前的发展速度来看，Frontier model 在漏洞发现能力与漏洞利用能力之间的差距不太可能长期存在。如果未来的 language model 突破了这道漏洞利用能力的门槛，我们就需要考虑采取额外的安全防护措施或其他行动，防止模型被恶意行为者滥用。

我们敦促开发者抓住这一窗口期，加倍努力提升软件的安全性。我们也计划大幅扩展网络安全方面的投入，包括与开发者合作搜索漏洞（遵循上文所述的 CVD 流程）、开发帮助维护者分类处理 bug 报告的工具，以及直接提出 patch。

如果你有兴趣支持我们的安全工作——编写新的 scaffold 以识别开源软件中的漏洞；对漏洞进行分类、修复和报告；以及为 AI 时代开发一套稳健的 CVD 流程——欢迎申请加入 Anthropic。

本文分享的所有建议都来自我们使用 Claude 的经验，但无论你偏好哪一种 LLM，这些建议都应该同样适用。

¹ Mozilla 独立完成了相应的 patch。

² 我们关于 open-weights model 的立场。

Cognizant 与 Anthropic 扩大合作，将 Claude 带给企业客户

Claude Opus 5 正式发布

Opus 5 为 Opus 系列带来了跨越式提升，在为长时间运行的 Agent 提供支持的同时，也增强了编码与专业工作能力。