公开补丁如何成为 AI 漏洞利用的线索

公开的安全补丁，正在变成 AI 寻找漏洞的路线图。原文围绕 Epoch AI 对 GLM 5.3 的实验展开：模型利用尚未进入稳定版的 Firefox 修复，连续攻破六个版本。作者关心的结论是，安全修复从公开到交付用户之间的等待，已经成为可被自动化利用的攻击窗口。

对前端和全栈团队，这件事值得读的地方在于发布流程：补丁合进仓库、依赖更新提了 PR，都不等于风险已经解除。实验展示了攻击成本的变化，也留下了必须分清的能力边界。

公开补丁为什么会给攻击者指路

补丁窗口（patch gap）有两段：一段是修复已经出现在公开提交、beta 或 nightly 中，稳定版用户还没拿到；另一段是更新已经发布，用户仍在使用旧版本。Epoch 研究的是前一段。

补丁会暴露开发者改了哪里。攻击者把修复前后的代码放在一起比较，就可能反推出旧版本的缺陷。过去，这需要较强的漏洞分析能力和时间投入，成本限制了攻击规模。

GLM 5.3 把其中一部分工作自动化了。即使安全修复被包装成普通改进，没有附带漏洞说明，模型仍能阅读代码，识别哪些修改可能涉及安全问题。

安全提交一旦公开，就应该按已经披露来安排后续发布。

这不等于每次提交都会立刻产生攻击，而是团队不能继续把「没写漏洞详情」当作可靠缓冲。作者据此把浏览器安全问题转成发布工程问题：攻击者已经拿到线索，修复却还在等发布车次，这段等待由谁负责、能否缩短，变得非常具体。

六个版本都成功，究竟成功到了哪一步

Epoch AI 于 2026 年 10 月 29 日公布报告，测试对象是 Z.ai 在 8 月发布的开放权重模型 GLM 5.3。目标环境为采用默认安全设置的 Ubuntu 26.04，以及官方 Firefox 构建。

研究人员要求模型制作一个网页，让用户访问后无需继续操作，就能读取本地文件并发送给攻击者。模型获得目标版本、基本工具和经过时间限制的公开资料，但不能访问互联网。除最初要求检查尚未进入稳定版的修复外，研究人员没有继续提供人工指导，漏洞选择和利用链构建由模型完成。

9 月 17 日至 10 月 26 日间的六个版本全部成功：156.0、156.0.1、157.0、157.0.1、158.0、158.0.1。更早的版本没有经过系统测试。每个目标最多允许运行 48 小时，最快一次用了 12 小时。

费用也要拆开看。Firefox 研究的 API 总支出超过 100,000 美元，主要花在离线环境搭建和早期测试；准备完成后，每增加一个 Firefox 版本，边际 API 成本约为 1,000 美元。不能把后一个数字当成任何团队从零复现实验的全部预算，也不能把最快耗时当成平均耗时。

模型通过第一方和第三方 API 接入，任务被描述为安全演练。Epoch 报告称，没有提供商触发拒绝或防护。实际测试的是 API 环境，原文没有给出本地部署同样权重的复现结果。

成功范围尤其需要收紧理解。每次攻击都串联了两个漏洞：一个来自补丁窗口，使模型能在网页内容进程中执行代码；另一个是尚未公开的漏洞，用来逃离沙箱。模型在每次尝试中都重新发现了后者。一次实验中，它还经历了获取浏览器进程内存读写能力、撞上沙箱限制、诊断崩溃和放弃失败路径的过程。

沙箱逃逸漏洞随后被披露给 Mozilla，并在 10 月 27 日发布的 Firefox 159.0 中修复。Epoch 尚未确认类似攻击能否在 159.0 上成功，只预计难度会明显提高。

最终证明的是本地文件读取和外传。研究人员继续尝试在近期版本上实现任意代码执行，没有成功。用同一套实验框架测试 Chrome，花费约 100,000 美元 API 费用后，也没有得到同等利用结果。

这些失败不能证明 Chrome 安全。原文提到可能更擅长进攻任务的 Kimi K3.1 Pro，其 API 于 10 月 23 日开放，权重计划于 11 月初发布，但它没有参加这次实验。

团队需要同时压缩发布等待和安装等待

作者给交付软件的团队提出了几项建议：安全修复先私下协作，准备好后同步发布；缩短从修复到用户可用的时间；能够串联的漏洞要协调处理，避免只公开修好其中一环。

这也有工程成本。公共 GitHub 仓库可以通过 draft security advisory 创建临时私有 fork，但原文引用的文档指出，CI 和集成无法访问这些 fork，状态检查也不会运行。私下修复需要提前安排验证方式，不能等到合并前才发现原有测试流程不可用。

Firefox 和 Chrome 已开始每周发布更新。普通团队不必照搬频率，但可以记录「安全修复合入」到「用户能够获得更新」之间的小时数。月度发布之外，应当有能单独交付安全修复的通道。

使用软件的团队还要测另一段时间：上游发布安全更新后，生产环境、CI 镜像和开发机多久真正运行新版本。Dependabot、Renovate 能减少人工发现和提交更新的等待，可信的测试则决定这些更新能否及时合并。

防守方也在使用 AI。按原文作者对 Firefox 159 公告 MFSA 2026-118 的统计，共有 167 个 CVE 条目，其中 108 个高影响、52 个中等影响、7 个低影响；34 个署名报告者为 OpenAI Codex Security，另有 7 个署名 OpenAI 的 Amy Burnett。

这组数说明 AI 已参与漏洞发现，但不能直接用来判断漏洞是否突然增多。Mozilla 同时调整了公告方式，把内部发现的内存安全问题从合并记录改为逐个漏洞发布，统计口径发生了变化。

我的判断

我认同把补丁交付速度列为安全指标。代码已经修好、线上还没更新，是研发流程里容易被低估的一段责任空白。它不能只靠安全团队催，也涉及构建、测试、发布和终端管理。

但这仍是特定模型、特定浏览器版本和特定环境下的实验。它没有给出普通业务系统、Node 服务或 npm 包上的同等成功率，也没有比较不同团队采用私下修复、加快发布之后，风险下降了多少。作者提出的流程建议有清楚的机制支撑，具体收益仍属于经验判断。

私下修复也不是放弃公开协作，而是协调披露时间。与「先公开合并，按原定周期发布」相比，它减少了攻击者提前研究的机会；代价是验证和协作更复杂。只追求保密、交付仍然缓慢，同样解决不了用户暴露的问题。

另外，沙箱没有挡住整个攻击，却迫使模型寻找第二个漏洞。修复速度和分层防护需要一起保留。 加快更新不能替代隔离，隔离也不能替代及时更新。

能拿来做什么

• 给项目记录两个时间：自有安全修复公开到用户可用的间隔，以及上游安全更新发布到实际部署的间隔。前端构建环境、Node 运行时和 CI 基础镜像都应纳入盘点，先找出等待发生在哪里。
• 为安全更新建立独立处理通道。使用 Dependabot 或 Renovate 提交依赖升级，并明确由哪些现有测试支持合并，避免安全更新长期等到下一轮常规迭代。
• 如果维护公开仓库，提前约定私下修复、验证和同步发布的步骤。采用 GitHub 临时私有 fork 前，要先解决 CI 无法访问和状态检查不运行的问题。
• 把 AI 用在自有代码变更和依赖的安全检查上，同时保留人工判断与隔离措施。原文支持把它作为防守工具尝试，并没有证明模型扫描可以替代完整的安全审查。