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

本文将分享我们与Mozilla研究人员合作的具体细节：在这次合作中，Claude Opus 4.6在两周内发现了22个漏洞。其中，Mozilla确认了14个为高危漏洞——这占了2025年已修复的所有Firefox高危漏洞的近五分之一。换言之，AI正使得以极快速度检测严重安全漏洞成为可能。

作为此次合作的一部分，Mozilla处理了我们提交的大量报告，帮助我们理解哪些类型的发现值得提交漏洞报告，并向数亿用户在Firefox 148.0中推送了修复补丁。他们的合作，以及我们从中汲取的技术经验，为AI赋能的安全研究人员和维护者如何携手应对当下挑战提供了一个范例。

从模型评估到安全合作伙伴关系

2025年末，我们注意到Opus 4.5在CyberGym基准测试中接近解决所有任务，该基准旨在测试大语言模型能否复现已知安全漏洞。我们希望构建一个更具难度、更贴近现实的评估环境，其中包含更多技术复杂的漏洞，例如现代网络浏览器中存在的那些漏洞。为此，我们构建了一个包含过往Firefox通用漏洞披露的数据集，用以测试Claude能否复现这些漏洞。

我们选择Firefox，不仅因为其代码库复杂，更因为它是世界上测试最充分、最安全的开源项目之一。这比我们之前用来测试模型的开源软件，更能严苛地检验AI发现新型安全漏洞的能力。全球数亿用户日常依赖Firefox，而浏览器漏洞尤其危险，因为用户经常接触不受信任的内容，并依赖浏览器来保护他们的安全。

我们的第一步是使用Claude在旧版Firefox代码库中寻找之前已被识别的CVE漏洞。令我们惊讶的是，考虑到每一个历史CVE漏洞的发现都曾耗费大量人力，Opus 4.6能够复现其中很大一部分。但我们尚不确定应多大程度上采信此结果，因为至少有一部分历史CVE可能已存在于Claude的训练数据中。

因此，我们交给Claude的下一个任务是，在当前版本的Firefox中发现全新的漏洞——这些漏洞按定义来说此前不可能被报告过。我们首先聚焦于Firefox的JavaScript引擎，随后扩展到浏览器的其他部分。从JavaScript引擎入手是一个便利的开端：它是Firefox代码库中一个相对独立的模块，可以单独分析，并且鉴于其广泛的攻击面（当用户浏览网页时，它会处理不受信任的外部代码），确保其安全性尤为重要。

仅仅探索了二十分钟后，Claude Opus 4.6就报告在JavaScript引擎中发现了一个"释放后使用"漏洞（一种内存漏洞，可能允许攻击者用任意恶意内容覆写数据）。我们的一位研究人员在装有最新Firefox版本的独立虚拟机中验证了此漏洞，随后将其转发给Anthropic的另外两位研究人员，他们也成功复现了该漏洞。接着，我们在Mozilla的问题跟踪系统Bugzilla上提交了一份漏洞报告，附带了漏洞描述和一个（由Claude编写并由报告团队验证的）建议补丁，以帮助定位根本原因。

就在我们验证并向Firefox提交这第一个漏洞的过程中，Claude已经又发现了超过50个独特的导致崩溃的输入用例。在我们对这些崩溃进行排查分类时，一位Mozilla的研究人员联系了我们。在就我们各自的工作流程进行技术讨论，并分享了几个我们已手动验证的漏洞后，他们鼓励我们批量提交所有发现，无需逐一验证，即便我们不确定所有导致崩溃的测试用例是否都具有安全隐患。在这项工作结束时，我们扫描了近6000个C++文件，总共提交了112份独特的报告，其中包括上文提到的高危和中危漏洞。大部分问题已在Firefox 148中修复，其余将在后续版本中解决。

在外部软件中进行此类漏洞挖掘时，我们始终意识到，我们可能遗漏了代码库的某些关键信息，从而导致发现的所谓漏洞其实是误报。我们会尽力尽职尽责地自行验证漏洞，但总存在出错的可能。我们非常感谢Mozilla在处理这些报告时的透明态度，并帮助我们调整方法，确保我们只提交他们关心的测试用例（即使并非所有用例最终都与安全相关）。此后，Mozilla的研究人员也开始在内部尝试使用Claude进行安全研究。

从识别漏洞到编写基础漏洞利用代码

为了衡量Claude网络安全能力的上限，我们还开发了一项新的评估，以确定Claude能否利用我们发现的任何一个漏洞。换句话说，我们想知道Claude是否能开发出黑客会用来利用这些漏洞执行恶意代码的那类工具。

为此，我们向Claude提供了我们已提交给Mozilla的漏洞信息，并要求它针对每个漏洞创建一个漏洞利用代码。为了证明成功利用了漏洞，我们要求Claude演示一次真实的攻击。具体来说，我们要求它像攻击者那样，实现对目标系统上本地文件的读写。

我们以不同的起点运行了数百次这个测试，花费了大约4000美元的API点数。尽管如此，Opus 4.6最终仅在两种情况下能够成功将漏洞转化为可用的漏洞利用代码。这告诉我们两点：第一，Claude发现漏洞的能力远强于利用漏洞的能力；第二，识别漏洞的成本比为其创建漏洞利用代码要低一个数量级。然而，Claude能够自动开发出哪怕是粗糙的浏览器漏洞利用代码，即便只是少数案例，也足以引起关注。

这里"粗糙"是一个重要的限定词。Claude编写的漏洞利用代码仅在我们的测试环境中有效，我们有意移除了现代浏览器中的一些安全特性。这其中最重要的是沙箱，其目的正是为了降低此类漏洞的影响。因此，Firefox的"纵深防御"本可以有效抵御这些特定的漏洞利用。但能够逃逸沙箱的漏洞并非闻所未闻，而Claude实现的攻击是构成一个完整端到端漏洞利用的必要组成部分。您可以在我们的前沿红队博客上阅读更多关于Claude如何开发其中一个Firefox漏洞利用代码的细节。

AI赋能网络安全的未来展望

AI辅助漏洞利用开发的这些早期迹象，突显了防御方加速"发现与修复"过程的重要性。为此，我们希望在本次分析中分享一些技术层面和流程层面的最佳实践。

首先，在研究使用大语言模型来开发和验证补丁的"修补代理"时，我们开发了一些方法，希望能帮助维护者利用像Claude这样的LLM来更快地对安全报告进行分类和处理。¹

根据我们的经验，当Claude能够借助另一个工具来检查自身工作成果时，其表现最佳。我们将这类工具称为"任务验证器"：一种可靠的方法，用以确认AI代理的输出是否真正实现了目标。任务验证器能在代理探索代码库时提供实时反馈，使其能够深入迭代直至成功。

任务验证器帮助我们发现了上述Firefox漏洞，² 并且在另一项研究中，我们发现它们对修复漏洞同样有用。一个好的修补代理至少需要验证两件事：漏洞是否确实已被移除，以及程序的预期功能是否得以保留。在我们的工作中，我们构建了能够自动测试：在应用建议的补丁后，原始漏洞是否还能被触发；并分别运行测试套件以捕捉回归错误（即意外破坏其他功能的变更）。我们期望维护者最了解如何为他们自己的代码库构建这些验证器；关键在于，为代理提供一种可靠的方式来检查这两个属性，能极大地提升其输出质量。

我们无法保证所有通过这些测试的代理生成的补丁都完美到可以立即合并。但任务验证器让我们更有信心，相信生成的补丁能够修复特定漏洞，同时保留程序功能——从而达到了一个合理补丁的最低要求。当然，在审阅AI编写的补丁时，我们建议维护者采用与审阅任何外部作者创建的补丁时相同的严格标准。

将视角扩展到提交漏洞和补丁的整个流程：我们深知维护者疲于应对。因此，我们的方法是为维护者提供他们所需的信息，以便信任和验证报告。Firefox团队强调了我们提交报告中的三个关键组成部分，这些部分对于他们信任我们的结果至关重要：

• 附上最小化的测试用例
• 提供详细的概念验证
• 提交候选补丁

我们强烈建议使用基于大语言模型的漏洞研究工具的研究人员，在提交基于此类工具输出的报告时，包含类似的验证和可复现性证据。

我们还发布了自己的《协调漏洞披露操作原则》，其中描述了我们在与维护者合作时将遵循的程序。目前，我们的流程遵循行业标准规范，但随着模型能力的提升，我们可能需要调整流程以跟上能力发展的步伐。

当下的紧迫性

前沿语言模型如今已成为世界级的漏洞研究人员。除了在Firefox中发现的22个CVE之外，我们还利用Claude Opus 4.6在Linux内核等其他重要软件项目中发现了漏洞。在未来的几周和几个月里，我们将持续报告我们如何使用模型以及与开源社区合作来改善安全性的进展。

Opus 4.6目前修复和识别漏洞的能力远强于利用漏洞的能力。这使得防御方占据优势。随着近期Claude Code Security在有限的研究预览版中发布，我们正将漏洞发现（及修补）能力直接带给客户和开源维护者。

但纵观进步的速度，前沿模型在漏洞发现能力与漏洞利用能力之间的差距不太可能持续太久。如果未来的语言模型突破了这个漏洞利用的瓶颈，我们将需要考虑额外的防护措施或其他行动，以防止我们的模型被恶意行为者滥用。

我们敦促开发者利用这个窗口期，加倍努力，使其软件更加安全。就我们而言，我们计划大幅扩展我们的网络安全工作，包括与开发者合作搜寻漏洞（遵循上述CVD流程），开发工具帮助维护者对漏洞报告进行分类，并直接提出补丁方案。

针对Claude发现漏洞的协同披露政策

宗旨：Anthropic正致力于开发能够更快速、更低成本发现软件漏洞的AI工具，并努力构建处理已识别漏洞的清晰框架——既遵循行业现有最佳实践，也预判这些AI工具带来的规模化与高速化所引发的独特挑战。

适用范围：本操作原则适用于Anthropic在开源软件及已获适当授权进行安全研究的闭源软件中所发现的漏洞。不适用于外部研究人员向Anthropic提交的漏洞报告（此类报告由Anthropic《负责任的披露政策》管辖）。

通用原则：Anthropic拟遵循行业标准的90天披露期限，提供经人工审核的漏洞报告并尽可能附上修复建议，同时根据维护者的实际处理能力控制提交节奏。

漏洞披露目标时间线
我们力求尽快通知厂商和维护者；除非基于重大安全考量另行决定，否则我们拟在90天后或补丁发布后（以先到者为准）向防御方公开细节。可能偏离默认时间线的特殊情况包括：
● 若90天期限临近时厂商/维护者仍在积极修复中，可根据请求延长14天
● 针对已遭主动利用的严重漏洞，目标是在7天内提供补丁或缓解方案。若维护者正在加紧修复并要求更多时间，可再延长7天
● 当发现涉及生态系统的共性问题（影响多个项目）时，拟在公开前通知受影响方并为每个维护者提供所需信息与支持
● 若与维护者对漏洞严重性评级存在分歧，原则上尊重维护者判断。但存在例外情形，例如有可靠证据表明漏洞正被积极利用时，无论维护者如何分类，都将适用压缩版7天披露时限。若首次报告后30天内未获维护者回应，拟将漏洞上报至外部协调机构，并在适用期限到期后推进公开披露
● 在特殊情况下（如不可抗力事件或修复难度极高），我们保留调整时限的权利并将酌情说明调整理由

补丁详情
补丁发布后，我们通常等待45天再公开完整技术细节。此举旨在为下游用户留出部署补丁的时间，避免利用细节过早曝光。若细节已通过其他渠道公开，或提前披露能有效帮助防御方识别缓解持续攻击，可能缩短等待期。当补丁部署异常复杂或受影响范围过大时，可能延长等待期。

漏洞披露报告与协作机制
每份报告均经安全研究员人工审核确认。源自AI的发现将在报告中明确标注。若能访问源代码且工具生成潜在补丁方案，我们将标注来源并邀请维护者共同优化至生产级修复方案。不会未经沟通即向单个项目提交大量报告，而是协商制定维护者可承受的提交节奏。正在遭积极利用的漏洞不受此节奏限制，通常适用上述压缩版披露时限。