Mozilla用Mythos发现271个Firefox漏洞
Ars Technica AI··作者 Dan Goodin
关键信息
Mozilla 工程师表示，早期的 AI 漏洞扫描会产生大量幻觉式、不可用的报告，因此关键进展在于那个 harness：它为 Mythos 提供明确任务、工具和可确定的成功信号。对于 Firefox 的内存安全问题，成功条件很简单：如果 sanitizer 构建版本崩溃，就说明代理找到了值得调查的问题，随后还会用第二个 LLM 对结果做进一步评分验证。
资讯摘要
Mozilla 近期的 CTO 曾提出一个很激进的判断：AI 辅助漏洞检测意味着“zero-days 的日子不多了”，防守方终于有机会彻底赢一次。这个说法之所以引发怀疑，是因为很多 AI 安全演示通常只展示少数亮眼结果，却回避了误报和人工筛查成本这些细节。Mozilla 在周四给出了更完整的幕后说明，介绍他们如何使用 Anthropic 的 Mythos 模型，在两个月内找出了 271 个 Firefox 漏洞。Mozilla 工程师表示，这一结果主要来自两方面：模型本身的进步，以及他们为 Firefox 源码专门构建的 custom harness。公司说，早期的 AI 漏洞挖掘经常充满“unwanted slop”，也就是模型会批量生成看起来合理、实际上却是幻觉的漏洞报告。
Mozilla Distinguished Engineer Brian Grinstead 解释说，harness 本质上是驱动 LLM 朝目标前进的代码，它会给模型下达任务、提供读写文件等工具，并以循环方式持续运行直到任务完成。针对 Firefox，代理可以接触到 Mozilla 开发者使用的同一套测试流水线和特殊构建版本，包括用于触发内存安全问题的 sanitizer 构建。Mozilla 还把现有的 fuzzing 系统接入流程，让代理生成并运行测试用例，再把成功输出交给第二个 LLM 评分，以提高结果可信度。Mozilla 称，最终 Mythos 产生的漏洞发现几乎没有误报，这与此前大量噪声很高的 AI 漏洞报告形成了鲜明对比。
资讯正文
上个月，当 Mozilla 的 CTO 宣称，借助 AI 的漏洞检测意味着“零日漏洞的日子已经不多了”，而且“防御者终于有机会决定性地获胜”时，怀疑情绪可谓溢于言表。毕竟，这看起来不过是一个过于熟悉的套路：挑选少数由 AI 取得的亮眼成果，省略任何可能呈现更细致图景的附注，然后任由炒作列车继续疾驰。
考虑到这种质疑，Mozilla 周四公布了其使用 Anthropic Mythos——一款用于识别软件漏洞的 AI 模型——的幕后细节：他们在两个月内借此发现了 271 个 Firefox 安全漏洞。在一篇帖子中，Mozilla 工程师表示，他们最终实现这一可投入实际应用的突破，主要归功于两点：（1）模型本身的改进；以及（2）Mozilla 开发了一个定制的“harness”，在 Mythos 分析 Firefox 源代码时为其提供支持。
“几乎没有误报”
工程师们表示，他们早先尝试使用 AI 辅助漏洞检测时，往往充斥着“令人不快的废料”。通常，有人会提示模型分析一段代码。随后模型会生成看起来相当合理的漏洞报告，而且往往规模前所未有。然而，一旦人类开发者进一步调查，就会发现其中很大一部分细节都是幻觉。于是，人类仍然需要像过去那样投入大量工作，手动处理这些漏洞报告。
Mozilla Distinguished Engineer Brian Grinstead 在接受采访时表示，Mozilla 与 Mythos 的合作则不同。最大的区别因素是使用了一个 agent harness，也就是一种包裹在 LLM 外层、引导它完成一系列特定任务的代码。要让这样的 harness 真正发挥作用，就需要投入大量资源，将其定制到它所要应用的项目特定语义、工具和流程上。
Grinstead 将其团队构建的 harness 描述为“驱动 LLM 以完成某个目标的代码。它会给模型下达指令（例如，‘在这个文件里找一个 bug’），向它提供工具（例如，允许它读取/写入文件并评估测试用例），然后让它循环运行，直到完成为止。” 这个 harness 让 Mythos 能够使用与 Mozilla 人类开发者相同的工具和流水线，包括他们用于测试的特殊 Firefox 构建版本。
他进一步解释说：
有了这些 harness，只要你能定义一个确定性的、清晰的成功信号或任务验证信号，就可以不断让它继续工作。在我们的例子里，当我们寻找内存安全问题时，我们有 Firefox 的 sanitizer 构建版本，如果你让它崩溃了，那就算你赢了。我们把这个 agent 指向一个源文件，并说：“我们知道这个文件里有个问题，请去把它找出来。” 它会构造测试用例。我们已经有现成的 fuzzing 系统和工具来运行这些测试。它会说：“如果我把 HTML 精确地这样构造，我觉得这里有问题。” 它会把测试发给一个工具，工具会给出是或否。如果工具说是，那么就还会进行一些额外验证。
有了这些 harness，只要你能定义一个确定且清晰的成功信号或任务验证信号，就可以不断让它继续工作。在我们的场景里，当我们在寻找内存安全问题时，我们会使用 Firefox 的 sanitizer 构建版本；如果你能让它崩溃，你就赢了。我们把那个代理指向一个源文件，然后对它说：“我们知道这个文件里有问题，请去把它找出来。”它会自行构造测试用例。我们有现有的 fuzzing 系统和工具来运行这些测试。它会说：“如果我把 HTML 精确地这样构造，我认为这里有问题。”然后它把测试送到一个工具那里，工具会给出是或否。如果工具说是，那就还有进一步的验证。
额外的验证来自第二个 LLM，它会对第一个 LLM 的输出进行评分。高分会给开发者带来与他们查看通过更传统发现方法生成的报告时相同的信心。
“就最终冒出来的漏洞而言，几乎没有误报，”他说。
周四公开的幕后视角还包括：Mozilla 使用 Mythos，辅以 Claude Opus 4.6，发现的 271 个漏洞中，有 12 个的完整 Bugzilla 报告被取消隐藏。每个报告都提供了测试用例——也就是触发不安全内存条件的 HTML 或其他代码——并且满足 Mozilla 对 Firefox 中所有被视为安全漏洞的 bug 所要求的相同标准。至少有一位研究人员周四表示，粗略看了一下这些报告后，它们“相当令人印象深刻”。
与以往漏洞披露中那些含糊其辞的材料不同，Grinstead 说，由其 harness 引导的 Mythos 分析、经第二个 LLM पुष्टि、并最终纳入报告的细节，提供了他团队此前从未拥有过的信心层级。
“这正是让我们能够以如今这个规模运作的关键，”他说。“它给了工程师一个可以转动的把手，让他们能说：‘对，这里确实有这个问题，’然后你就可以在代码上反复迭代，清楚地知道自己什么时候已经修复了它，并最终把测试用例提交进树里，这样就不会再回归。”
如前所述，Mozilla 将 AI 辅助漏洞发现描述为一种改变游戏规则的能力，这一说法在许多圈子里都遭到了强烈而公开的质疑。起初，批评者嘲笑 Mozilla 没有为这 271 个漏洞中的任何一个获得 CVE 编号。然而，像许多开发者一样，Mozilla 也不会为内部发现的安全漏洞单独申请 CVE 条目。相反，它们会被合并进一个补丁中。通常，这些详细说明此类“rollup”的 Bugzilla 报告在修复后会隐藏数月，以保护那些打补丁较慢的人。如今 Mozilla 已经公开了其中十二个，批评者大概会说这些报告也是经过挑选的，并掩盖了不那么准确的结果。
在使用 Mythos 发现的 271 个漏洞中，有 180 个被标记为 sec-high，这是 Mozilla 对内部报告漏洞的最高分级。这类漏洞可以通过正常的用户行为被利用，例如访问某个网页。（更高一级的评级是 sec-critical，仅保留给零日漏洞。）另外 80 个被标记为 sec-moderate，11 个被标记为 sec-low。
批评者继续提出质疑是对的。炒作是进一步抬高本已虚高的 AI 公司估值的关键手段。鉴于 Mozilla 给予 Mythos 如此大量的赞扬，即便是再容易轻信的人也会忍不住想：他们得到了什么回报？周四补充的这些细节非但没有平息争议，反而很可能只会进一步加剧这场风波。
不过，正如 Grinstead 所说，这些细节清楚地证明了 AI 辅助发现的实用性，而 Mozilla 的动机也很简单。
他说：“人们对去年那些垃圾式提交有点厌倦了，所以我们觉得有必要展示一些我们的工作，公开一些漏洞，并更详细地谈谈这件事，希望能借此推动一些行动，或者继续这场讨论。这里面没有什么营销意图。我们团队完全认可这种方法。我们想传递的是关于这种技术本身的信息，而不是任何特定的模型提供商、公司之类的东西。”
来源与参考
收录于 2026-05-08