研究称GLM 5.3自主完成Firefox漏洞利用链

安全补丁还没送到用户手里，公开代码却可能先告诉攻击者哪里出了问题。The Decoder 转述的一项 Epoch AI 研究显示，GLM 5.3 能利用这段时间差，自动构造针对 Firefox 的完整攻击链：用户只是打开网页，本地文件就可能被读取并外传。

这项研究值得程序员关注的，不只是模型会写漏洞利用代码，而是它把识别补丁、寻找漏洞、串联攻击几个环节接了起来。不过，「零人工输入」「每次约 1,000 美元」都有实验边界，不能直接理解成任何人随时都能复现。

补丁为什么会变成攻击提示

研究讨论的是补丁窗口（patch gap）：安全修复已经能从公开代码或软件产物中看见，但修复版本还没到用户手里。攻击者可以比较修改前后的差异，反推旧版本的问题。

修复越明确，留下的线索可能越具体。代码变安全了，仍在运行旧版本的用户却未必同步受益。

据报道，Firefox 会把部分安全修复伪装成普通改进，增加攻击者识别的难度。GLM 5.3 仍然找出了其中与安全有关的修改，并据此选择攻击目标。这里的关键能力不是凭空发现所有漏洞，而是从海量修改中判断哪些值得继续追查。

研究覆盖了 9 月 17 日至 10 月 26 日发布的 6 个 Firefox 版本。模型生成的网页可以在访问时读取用户计算机上的本地文件，并发送到攻击者服务器。报道以 Firefox 超过 2 亿活跃用户说明潜在影响，提到保存的密码、认证 Cookie 和私人文档可能面临风险；这不代表研究已经证明所有这些用户或数据都能被攻击。

补丁公开和用户完成更新，是两个不同的安全节点。

「零人工输入」发生在哪个阶段

研究者先搭好了实验环境：提供目标 Firefox 版本、基础工具和公开信息，并在离线环境中给出调查补丁窗口的基本指令。此后，模型自主识别即将发布的安全修复、挑选漏洞、构造多阶段攻击链。

因此，「零人工输入」指的是任务启动后的攻击构造过程。环境准备和任务定义仍由研究者完成。原文没有详细交代这些准备工作需要多少专业知识，也没有完整说明离线环境如何组织公开资料。

其中一次攻击中，模型通过一项即将到来的修复识别出内存安全漏洞，获得读取和修改浏览器内存的能力。文件访问被浏览器防护挡住后，它继续串联其他阶段，绕过剩余防线。最快的成功攻击用了 12 小时，单次任务允许的最长时间是 48 小时。

更关键的是，所有针对当时现行 Firefox 版本的成功攻击，都依赖同一个此前未知的漏洞。模型在每次尝试中独立重新发现它，用来绕过沙箱，直接读取计算机文件。沙箱可以理解为浏览器给网页划出的权限边界，突破内存防护并不自动等于能访问本地文件。

团队向 Mozilla 披露后，该漏洞在 2026 年 10 月 27 日发布的 Firefox 159.0 中修复。研究者没有确认同类攻击能否继续攻破新版，只推测难度至少会显著增加。

环境就绪后，每个成功攻击对应的 Firefox 版本，API 费用约为 1,000 美元。这不是完整项目成本，也不是对任意目标的报价。研究期间，Z.ai 和其他 API 提供商没有触发安全拦截或拒绝；研究者称，尽管任务被描述为安全演练，其操作与针对真实用户的攻击尝试难以区分。

Chrome 没被攻破，说明了什么

他们用相同环境和技术测试 Google Chrome，花费约 100,000 美元 API 费用，仍未得到同等级的漏洞利用结果。

这个对照很有价值：自动攻击能力不会均匀落在所有软件上。但它只支持「这套方法没有成功」，不能证明 Chrome 免疫。研究者也承认，更好的任务引导方法或更强模型可能改变结果。

报道还引用 Anthropic 的既有说法，称 GLM 5.3 编写漏洞利用的能力大致达到 Mythos 水平；有限基准数据提示 Kimi K3.1 Pro 可能更擅长进攻性网络任务，但团队没有亲自测试。它们都不能替代本次实验中的直接对照。

补丁窗口也不专属于开源浏览器。开源项目的代码公开，线索更容易取得；闭源软件仍可通过二进制差异和反编译暴露修复。报道提到，Anthropic 已展示 Mythos 在无法访问源码时利用 Windows 补丁窗口。

现实事件同样提示发布节奏的重要性：2026 年 9 月，Chrome 曾遭遇补丁窗口攻击；同月，一家供应商提前超过 6 小时发布修补后的 PHP 构建，早于两个严重漏洞的协调披露。研究者引用外部报道指出，这可能促成正式发布前数千次、发布后数百万次利用尝试。这里是可能关联，不能直接认定提前发布就是全部原因。

我的判断

我认同研究最有分量的判断：防守不能只看修复是否写完，还要看修复何时暴露、何时交付，以及用户何时真正用上。

不过，这份结果也有明显前提。6 个 Firefox 版本的成功攻击都借助了同一个未知漏洞，因此不能把它们理解为 6 套完全独立的突破。漏洞修复后的成功率、实验总尝试次数，以及普通攻击者搭建同等环境的难度，原文都没有说清。

研究者建议让安全修复在可交付前保持私密、缩短 beta 到正式版的时间，并避免把可串联利用的多个漏洞同时修补。这些建议有机制上的依据，但文章没有给出各方案的对照数据，应当视为研究团队的经验判断。尤其是协调修复，不能机械执行成拆开发版，仍需结合漏洞依赖关系安排。

Firefox 和 Chrome 已开始每周更新，但发布频率不能代表安装覆盖率。路由器固件、移动操作系统这类更新不频繁的软件，风险窗口可能更长。

2026 年 4 月，Claude Mythos Preview 带来网络能力跃升，前沿实验室随后通过限制访问，以及 Glasswing、Daybreak 等项目让防守方提前接触模型。这可以帮助提前找漏洞，却无法单独消除补丁公开后的时间差。开放权重模型能力扩散后，防守更需要依靠交付流程，而不只是模型访问门槛。

能拿来做什么

• 维护浏览器自动化或本地开发环境时，把浏览器更新纳入日常维护。不要仅凭「已有修复版本」判断当前环境已经安全。
• 维护 Node 服务或依赖包时，检查安全更新从构建、发布到生产部署的实际延迟。原文没有测试 Node，但补丁可见而线上仍运行旧代码的时间差值得排查。
• 负责安全修复发布时，把代码可见时间、安装包可用时间和漏洞说明发布时间放在一起安排，避免某个环节提前暴露可利用线索。
• 用 AI 辅助安全研究时，记录环境准备、尝试次数、API 成本和成功条件。评估「自主完成」的价值，需要把这些条件与最终演示一起看。