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 常见漏洞与暴露（CVE）的数据集，以检验 Claude 能否复现这些漏洞。
我们选择 Firefox，是因为它既是一个复杂的代码库，也是全球测试最严格、安全性最高的开源项目之一。这使得它比我们此前用于测试模型的那些开源软件，更能检验 AI 发现新型安全漏洞的能力。数亿用户每天依赖它，而浏览器漏洞尤其危险，因为用户日常会接触不可信内容，并依赖浏览器来保障安全。
我们的第一步是使用 Claude 在旧版 Firefox 代码库中寻找此前已识别的 CVE。我们惊讶地发现，Opus 4.6 能够复现这些历史 CVE 中的很大一部分，而每一个 CVE 当初都耗费了大量人力才被发现。但我们仍不确定这个结果的可信度有多高，因为至少有一部分历史 CVE 可能已经存在于 Claude 的训练数据中。
因此，我们让 Claude 在当前版本的 Firefox 中寻找新型漏洞——这些漏洞按定义来说，此前不可能被报告过。我们首先聚焦于 Firefox 的 JavaScript 引擎，随后扩展到浏览器的其他区域。JavaScript 引擎是一个方便的起点：它是 Firefox 代码库中一个可独立分析的独立模块，并且由于其攻击面广泛（用户在浏览网页时会处理不可信的外部代码），确保其安全性尤为重要。
仅经过二十分钟的探索，Claude Opus 4.6 报告称，它在 JavaScript 引擎中发现了一个 Use After Free（一种内存漏洞，攻击者可借此用任意恶意内容覆盖数据）。我们的一位研究人员在搭载最新版 Firefox 的独立虚拟机中验证了该漏洞，随后将其转发给另外两位 Anthropic 研究人员，他们也验证了该漏洞。接着，我们在 Mozilla 的问题追踪系统 Bugzilla 中提交了一份漏洞报告，其中包含漏洞描述和一份建议的补丁（由 Claude 编写并经报告团队验证），以帮助排查根本原因。
在我们验证并向 Firefox 提交第一个漏洞的这段时间里，Claude 已经发现了另外 50 个独特的崩溃输入。在我们对这些崩溃进行分类处理时，Mozilla 的一位研究人员主动联系了我们。经过关于各自流程的技术讨论，并分享了几个我们手动验证过的漏洞后，他们鼓励我们将所有发现批量提交，无需逐一验证，即使我们不确定所有导致崩溃的测试用例是否都具有安全影响。在这项工作结束时，我们扫描了近 6000 个 C++ 文件，并总共提交了 112 份独特的报告，其中包括上述高严重性和中等严重性的漏洞。大多数问题已在 Firefox 148 中修复，其余问题将在后续版本中修复。
在进行这种外部软件的漏洞挖掘时，我们始终意识到，我们可能遗漏了代码库中某些关键信息，从而导致发现的是误报。我们尽力尽职尽责地自行验证漏洞，但总会有出错的可能。我们非常感谢 Mozilla 对其分类处理流程如此透明，并帮助我们调整方法，确保我们只提交他们关心的测试用例（即使并非所有用例最终都与安全相关）。此后，Mozilla 的研究人员已开始在内部将 Claude 用于安全目的。
从识别漏洞到编写原始漏洞利用程序
为了衡量 Claude 网络安全能力的上限，我们还开发了一项新的评估，以确定 Claude 是否能够利用我们发现的任何漏洞。换句话说，我们想了解 Claude 是否也能开发出黑客用来利用这些漏洞执行恶意代码的那类工具。
为此，我们向 Claude 提供了已提交给 Mozilla 的漏洞信息，并要求 Claude 针对每个漏洞分别编写利用代码。为了证明它成功利用了某个漏洞，我们要求 Claude 演示一次真实的攻击。具体来说，我们要求它像攻击者那样，在目标系统中读取并写入一个本地文件。
我们以不同的初始条件重复进行了数百次测试，花费了大约 4000 美元的 API 额度。尽管如此，Opus 4.6 仅在两个案例中成功将漏洞转化为了可利用的代码。这告诉我们两件事：第一，Claude 发现这些漏洞的能力远强于利用它们的能力；第二，识别漏洞的成本比为其编写利用代码要低一个数量级。然而，Claude 能够自动开发出粗糙的浏览器漏洞利用代码——即便只是少数案例——这一事实仍然令人担忧。
“粗糙”是一个重要的限定条件。Claude 编写的利用代码仅在我们的测试环境中有效，而该环境有意移除了现代浏览器中的部分安全特性。其中最重要的是沙箱，其目的是减轻这类漏洞的影响。因此，Firefox 的“纵深防御”体系本可以有效缓解这些特定的利用代码。但能够逃逸沙箱的漏洞并非闻所未闻，而 Claude 的攻击手段正是构成端到端漏洞利用链条的必要一环。您可以在我们的前沿红队博客中，阅读更多关于 Claude 如何开发出其中一个 Firefox 漏洞利用代码的细节。
AI 赋能网络安全的下一步
这些 AI 赋能漏洞利用开发的早期迹象，凸显了加速防御方“发现并修复”流程的重要性。为此，我们想分享在执行本次分析过程中发现的一些技术和流程上的最佳实践。
首先，在研究利用大语言模型来开发和验证漏洞修复的“补丁智能体”时，我们开发了几种方法，希望能帮助维护者利用 Claude 等大语言模型更快地分类和处理安全报告。¹
根据我们的经验，当 Claude 能够借助另一个工具来检查自身工作时，它的表现最佳。我们将这类工具称为“任务验证器”：一种可信的方法，用于确认 AI 智能体的输出是否真正实现了其目标。任务验证器能在智能体探索代码库时提供实时反馈，使其能够深入迭代，直至成功。
任务验证器帮助我们发现了上述 Firefox 漏洞，² 并且在另一项研究中，我们发现它们对于修复漏洞也很有用。一个好的补丁智能体至少需要验证两件事：漏洞是否确实已被移除，以及程序的预期功能是否得以保留。在我们的工作中，我们构建了能够自动测试在应用建议的修复后，原始漏洞是否仍能被触发的工具，并分别运行测试套件来捕捉回归问题（即意外破坏其他功能的变更）。我们预计，代码库的维护者最清楚如何为自己的代码库构建这些验证器；关键在于，为智能体提供一种可靠的方式来检查这两个属性，能显著提升其输出质量。
我们无法保证所有通过了这些测试的智能体生成的补丁都足够好，可以立即合并。但任务验证器让我们更有信心，相信生成的补丁能够修复特定漏洞，同时保留程序功能——从而满足一个合格补丁的最低要求。当然，在审查 AI 编写的补丁时，我们建议维护者采用与审查任何其他外部作者创建的补丁相同的严格标准。
将视角放大到提交漏洞和补丁的整个流程：我们知道维护者已经不堪重负。因此，我们的方法是向维护者提供他们所需的信息，以便他们信任并验证报告。Firefox 团队强调了我们的提交材料中，对于他们信任我们结果至关重要的三个组成部分：
- 附带最小测试用例
- 详细的概念验证
- 候选补丁
我们强烈建议使用大语言模型驱动的漏洞研究工具的研究人员，在基于此类工具的输出提交报告时，纳入类似的验证与可复现性证据。
我们还发布了《协调漏洞披露运作原则》，其中描述了在与维护者合作时将遵循的流程。目前，我们的流程遵循行业标准规范，但随着模型能力的提升，我们可能需要调整流程以跟上能力发展的步伐。
当下的紧迫性
前沿语言模型如今已是世界级的漏洞研究者。除了在 Firefox 中发现的 22 个 CVE 漏洞外，我们还使用 Claude Opus 4.6 在 Linux 内核等其他重要软件项目中发现了漏洞。未来数周乃至数月，我们将持续报告如何利用我们的模型并与开源社区合作以提升安全性。
目前，Opus 4.6 在识别和修复漏洞方面的能力远强于利用漏洞。这为防御方带来了优势。随着近期 Claude Code Security 以有限研究预览形式发布，我们正将漏洞发现（及修补）能力直接带给客户和开源维护者。
但从进展速度来看，前沿模型在漏洞发现与利用能力之间的差距不太可能持续太久。如果未来语言模型突破了这一利用能力的瓶颈，我们将需要考虑额外的安全防护措施或其他行动，以防止模型被恶意行为者滥用。
我们敦促开发者利用这一窗口期，加倍努力提升软件安全性。就我们自身而言，我们计划大幅扩展网络安全工作，包括与开发者合作搜索漏洞（遵循上述 CVD 流程）、开发帮助维护者对漏洞报告进行分类的工具，以及直接提出补丁方案。
如果您有兴趣支持我们的安全工作——编写新的脚手架来识别开源软件中的漏洞；对漏洞进行分类、修补和报告；以及为人工智能时代开发稳健的CVD流程——请在此处申请加入Anthropic。
脚注
- 这里分享的所有建议都基于我们对Claude的使用，但应该适用于您偏好的任何大语言模型。
- Mozilla已独立修补了该漏洞。
推出Claude教师版
Anthropic承诺向加拿大人工智能研究投入1000万美元
AI models can now independently identify high-severity vulnerabilities in complex software. As we recently documented, Claude found more than 500 zero-day vulnerabilities (security flaws that are unknown to the software’s maintainers) in well-tested open-source software.
In this post, we share details of a collaboration with researchers at Mozilla in which Claude Opus 4.6 discovered 22 vulnerabilities over the course of two weeks. Of these, Mozilla assigned 14 as high-severity vulnerabilities—almost a fifthof allhigh-severity Firefox vulnerabilities that were remediated in 2025. In other words: AI is making it possible to detect severe security vulnerabilities at highly accelerated speeds.
As part of this collaboration, Mozilla fielded a large number of reports from us, helped us understand what types of findings warranted submitting a bug report, and shipped fixes to hundreds of millions of users in Firefox 148.0. Their partnership, and the technical lessons we learned, provides a model for how AI-enabled security researchers and maintainers can work together to meet this moment.
From model evaluations to a security partnership
In late 2025, we noticed that Opus 4.5 was close to solving all tasks in CyberGym, a benchmark that tests whether LLMs can reproduce known security vulnerabilities. We wanted to construct a harder and more realistic evaluation that contained a higher concentration of technically complex vulnerabilities, like those present in modern web browsers. So we built a dataset of prior Firefox common vulnerabilities and exposures (CVEs) to see if Claude could reproduce those.
We chose Firefox because it’s both a complex codebase and one of the most well-tested and secure open-source projects in the world. This makes it a harder test of AI’s ability to find novel security vulnerabilities than the open-source software we previously used to test our models. Hundreds of millions of users rely on it daily, and browser vulnerabilities are particularly dangerous because users routinely encounter untrusted content and depend on the browser to keep them safe.
Our first step was to use Claude to find previously identified CVEs in older versions of the Firefox codebase. We were surprised that Opus 4.6 could reproduce a high percentage of these historical CVEs, given that each of them took significant human effort to uncover. But it was still unclear how much we should trust this result because it was possible that at least some of those historical CVEs were already in Claude’s training data.
So we tasked Claude with finding novel vulnerabilities in the current version of Firefox—bugs that by definition can’t have been reported before. We focused first on Firefox’s JavaScript engine but then expanded to other areas of the browser. The JavaScript engine was a convenient first step: it’s an independent slice of Firefox’s codebase that can be analyzed in isolation, and it’s particularly important to secure, given its wide attack surface (it processes untrusted external code when users browse the web).
After just twenty minutes of exploration, Claude Opus 4.6 reported that it had identified a Use After Free (a type of memory vulnerability that could allow attackers to overwrite data with arbitrary malicious content) in the JavaScript engine. One of our researchers validated this bug in an independent virtual machine with the latest Firefox release, then forwarded it to two other Anthropic researchers, who also validated the bug. We then filed a bug report in Bugzilla, Mozilla’s issue tracker, along with a description of the vulnerability and a proposed patch (written by Claude and validated by the reporting team) to help triage the root cause.
In the time it took us to validate and submit this first vulnerability to Firefox, Claude had already discovered fifty more unique crashing inputs. While we were triaging these crashes, a researcher from Mozilla reached out to us. After a technical discussion about our respective processes and sharing a few more vulnerabilities we had manually validated, they encouraged us to submit all of our findings in bulk without validating each one, even if we weren’t confident that all of the crashing test cases had security implications. By the end of this effort, we had scanned nearly 6,000 C++ files and submitted a total of 112 unique reports, including the high- and moderate-severity vulnerabilities mentioned above. Most issues have been fixed in Firefox 148, with the remainder to be fixed in upcoming releases.
When doing this kind of bug hunting in external software, we’re always conscious of the fact that we may have missed something critical about the codebase that would make the discovery a false positive. We try to do the due diligence of validating the bugs ourselves, but there’s always room for error. We are extremely appreciative of Mozilla for being so transparent about their triage process, and for helping us adjust our approach to ensure we only submitted test cases they cared about (even if not all of them ended up being relevant to security). Mozilla researchers have since started experimenting with Claude for security purposes internally.
From identifying vulnerabilities to writing primitive exploits
To measure the upper limits of Claude’s cybersecurity abilities, we also developed a new evaluation to determine whether Claude was able to exploit any of the bugs we discovered. In other words, we wanted to understand whether Claude could also develop the sorts of tools that a hacker would use to take advantage of these bugs to execute malicious code.
To do this, we gave Claude access to the vulnerabilities we’d submitted to Mozilla and asked Claude to create an exploit focusing on each one. To prove it had successfully exploited a vulnerability, we asked Claude to demonstrate a real attack. Specifically, we required it to read and write a local file in a target system, as an attacker would.
We ran this test several hundred times with different starting points, spending approximately $4,000 in API credits. Despite this, Opus 4.6 was only able to actually turn the vulnerability into an exploit in two cases. This tells us two things. One, Claude is much better at finding these bugs than it is at exploiting them. Two, the cost of identifying vulnerabilities is an order of magnitude cheaper than creating an exploit for them. However, the fact that Claude could succeed at automatically developing a crude browser exploit, even if only in a few cases, is concerning.
“Crude” is an important caveat here. The exploits Claude wrote only worked on our testing environment, which intentionally removed some of the security features found in modern browsers. This includes, most importantly, the sandbox, the purpose of which is to reduce the impact of these types of vulnerabilities. Thus, Firefox’s “defense in depth” would have been effective at mitigating these particular exploits. But vulnerabilities that escape the sandbox are not unheard of, and Claude’s attack is one necessary component of an end-to-end exploit. You can read more about how Claude developed one of these Firefox exploits on our Frontier Red Team blog.
What's next for AI-enabled cybersecurity
These early signs of AI-enabled exploit development underscore the importance of accelerating the find-and-fix process for defenders. Towards that end, we want to share a few technical and procedural best practices we’ve found while performing this analysis.
First, when researching “patching agents,” which use LLMs to develop and validate bug fixes, we have developed a few methods we hope will help maintainers use LLMs like Claude to triage and address security reports faster.1
In our experience, Claude works best when it's able to check its own work with another tool. We refer to this class of tool as a “task verifier”: a trusted method of confirming whether an AI agent’s output actually achieves its goal. Task verifiers give the agent real-time feedback as it explores a codebase, allowing it to iterate deeply until it succeeds.
Task verifiers helped us discover the Firefox vulnerabilities described above,2 and in separate research, we’ve found that they’re also useful for fixing bugs. A good patching agent needs to verify at least two things: that the vulnerability has actually been removed, and that the program’s intended functionality has been preserved. In our work, we built tools that automatically tested whether the original bug could still be triggered after a proposed fix, and separately ran test suites to catch regressions (a change that accidentally breaks something else). We expect maintainers will know best how to build these verifiers for their own codebases; the key point is that giving the agent a reliable way to check both of these properties dramatically improves the quality of its output.
We can’t guarantee that all agent-generated patches that pass these tests are good enough to merge immediately. But task verifiers give us increased confidence that the produced patch will fix the specific vulnerability while preserving program functionality—and therefore achieve what’s considered to be the minimum requirement for a plausible patch. Of course, when reviewing AI-authored patches, we recommend that maintainers apply the same scrutiny they’d apply to any other patch created by an external author.
Zooming out to the process of submitting bugs and patches: we know that maintainers are underwater. Therefore, our approach is to give maintainers the information they need to trust and verify reports. The Firefox team highlighted three components of our submissions that were key for trusting our results:
- Accompanying minimal test cases
- Detailed proofs-of-concept
- Candidate patches
We strongly encourage researchers who use LLM-powered vulnerability research tools to include similar evidence of verification and reproducibility when submitting reports based on the output of such tooling.
We’ve also published our Coordinated Vulnerability Disclosure operating principles, where we describe the procedures we will use when working with maintainers. Our processes here follow standard industry norms for the time being, but as models improve we may need to adjust our processes to keep pace with capabilities.
The urgency of the moment
Frontier language models are now world-class vulnerability researchers. On top of the 22 CVEs we identified in Firefox, we’ve used Claude Opus 4.6 to discover vulnerabilities in other important software projects like the Linux kernel. Over the coming weeks and months, we will continue to report on how we’re using our models and working with the open-source community to improve security.
Opus 4.6 is currently far better at identifying and fixing vulnerabilities than at exploiting them. This gives defenders the advantage. And with the recent release of Claude Code Security in limited research preview, we’re bringing vulnerability-discovery (and patching) capabilities directly to customers and open-source maintainers.
But looking at the rate of progress, it is unlikely that the gap between frontier models’ vulnerability discovery and exploitation abilities will last very long. If and when future language models break through this exploitation barrier, we will need to consider additional safeguards or other actions to prevent our models from being misused by malicious actors.
We urge developers to take advantage of this window to redouble their efforts to make their software more secure. For our part, we plan to significantly expand our cybersecurity efforts, including by working with developers to search for vulnerabilities (following the CVD process outlined above), developing tools to help maintainers triage bug reports, and directly proposing patches.
If you’re interested in supporting our security efforts—writing new scaffolds to identify vulnerabilities in open-source software; triaging, patching, and reporting vulnerabilities; and developing a robust CVD process for the AI era—apply to work at Anthropic here.
Footnotes
- All the advice shared here is based on our use of Claude, but it should apply to whichever LLM you prefer.
- Which Mozilla patched independently.