六天、四万美元、一条完整 Chrome 漏洞链：XBOW 证明攻击成本正在坍缩

一条能在 Windows 上从普通网页一路打穿 Chrome 两层沙盒、弹出计算器的完整漏洞链，过去是一个四人精英团队六到九个月的工作量。2026 年 8 月 2 日到 7 日，AI 安全公司 XBOW 用公开可用的 GPT-5.6 Sol 驱动 agent 群，只花了六天和大约四万美元的 API 费用，就把它造了出来。Google 确认复现、修复了全部三个漏洞，并按 2026 年 4 月生效的新版漏洞奖励规则，支付了 25 万美元的 Chrome 完整链奖金——这是新规则下的第一笔。

10 月 13 日，XBOW Labs 发布了万字技术长文，把整条链的根因、利用手法和工程细节全部公开。这不是一篇"AI 发现漏洞"的营销稿，而是一份冷静的工程复盘：agent 做了绝大多数的搜索和编码工作，但人类的战略判断决定了它能走多远。而它真正要回答的问题只有一个——当顶级攻击能力的成本从"国家级团队半年"坍缩到"六天加四万美元"，防守侧的每一项旧假设还成立吗？

先看事实：六天里到底发生了什么

时间线是理解这件事的骨架。2026 年 1 月，XBOW 在马耳他的全员会上立下目标：做出一条浏览器完整链，赶在 Black Hat 之前。他们的第一条 Chrome 完整链花了约两个月完成并提交。获奖的这条，是在 8 月 2 日（周日）到 8 月 7 日（周五）之间、Black Hat 与 DEF CON 举办的那一周，在拉斯维加斯冲刺六天做出来的。

分工上，XBOW 没有让一个 agent 从头到尾写 exploit，而是把工作拆成五个目标更窄的并行战役：广域漏洞搜索、V8 内存破坏、V8 沙盒逃逸、渲染器沙盒逃逸，以及集成。运行 OpenAI 公开模型 gpt-5.6-sol 的 agent 负责读源码、验证假设、写 PoC、搭 exploit 的各个阶段；人类研究员负责选目标、给上下文、挑战 agent 的结论、把各段拼起来，并为每一段准备备份路线，每段之间留出干净的接口，以便替换其中一段而不必重写整条链。从归档的 Codex 日志重建，这六天的战役大约烧掉了四万美元的 API 费用。

结果是三段式完整链：V8 Maglev 编译器 bug → 动画 WebP 解码器 bug → Crashpad 崩溃处理组件 bug。起点是一个普通 Chrome 标签页里的 JavaScript，终点是沙盒之外的原生代码执行——演示里弹出了计算器。Google 的漏洞奖励评审在 8 月 31 日批准了这笔 25 万美元的奖金，三个漏洞分别在 Chrome 152.0.7977.65（8 月 25 日）和 152.0.7977.82（9 月 3 日）中被修复。XBOW 估计，这类缺陷在修复前横亘在全球约十亿 Windows 版 Chrome 用户面前；同时确认，这些漏洞从未被用于攻击真实用户。

拆开这条链：三个"不可变"的假设，三次被打破

Chrome 把网页代码关在两层笼子里：V8 先把 JavaScript 引擎的内存破坏限制在进程内的"指针压缩笼"里（大多数 JS 堆对象挤在 4GiB 的保留区域），外面再套一层操作系统级的渲染器进程沙盒。这条链恰好用三个漏洞逐层越狱，而 XBOW 的研究员 Brendan Dolan-Gavitt 在复盘里点出了一个漂亮的巧合：三个漏洞本质上都是"篡改了某个被认为不可变的东西"。

第一段：V8 Maglev，反优化时复用了可变的数字盒子。Maglev 是 V8 的中层优化编译器。当优化代码的假设在运行时失效，V8 要"反优化"，把只存在于编译器想象中的虚拟对象物化成真正的 JS 对象。漏洞在于，Maglev 为虚拟的 double 字段创建 HeapNumber 时，把一个可变的老生代 HeapNumber 对象塞进了反优化字面量数组；而通用物化器在重建对象时，拷贝的是这个对象的身份而非数值。于是嵌套调用可以造出多个 JS 对象，它们的 double 字段共享同一个可变的 HeapNumber——这直接违反了编译器内部"HeapNumberRef 只用于不可变的 HeapNumber"的不变式。exploit 拿它去攻击 Array.prototype.at()：一次编译观察看到安全的索引、另一次观察用名义上同一个常量提供实际加载偏移，改一个对象的 double 字段就能改优化代码的访存偏移而不触发边界检查失效。三段优化过的加载函数足以泄露附近的 V8 指针、伪造数组，最终把一个真正的 Uint8Array 的元数据改写，让普通索引访问横跨整个 4GiB 笼子。这一段的公开根因报告是 Chromium issue 547819997。

第二段：动画 WebP，缓存的几何形状遇上了被篡改的字节。这是 V8 沙盒逃逸，但 XBOW 刻意没有去"攻击沙盒本身"，而是去找沙盒威胁模型里"允许但可疑"的东西：V8 沙盒并不承诺让 transfer 出去的 ArrayBuffer 对笼内攻击者语义不可变，而 Blink 却默认它可以信任。exploit 先用第一段的笼内写能力，把一个存活的 Uint8Array 视图从其 JSArrayBuffer 的 detach 通知链上摘掉；当 ImageDecoder transfer 走这块缓冲时，V8 只 detach 了它还知道的视图，被摘掉的视图依然可写。Blink 以为自己独占了这块字节，攻击者却还能改。接下来是教科书级的 TOCTOU：PoC 在同一块 backing store 里放了两个等长但各自合法的动画 WebP，A 描述 64×64 画布、首帧 48 像素宽起于 x=16，解码器缓存了 A 的帧矩形和载荷位置；随后存活视图把字节换成 WebP B，其当前载荷解码出完整的 64×64 帧。解码器用 A 的几何形状去描述输出缓冲，却喂进了 B 的像素数据，写越过了原生 SkBitmap 分配。生产版 exploit 把几何形状调到正好适配 PartitionAlloc，用一次越界写把两个事先摆好的 WebPDecBuffer 描述符塞进解码器字段，借真正的 WebPCopyDecBufferPixels() 之手完成"一次选定的 64 位原生写"——这就是本段与下一段之间唯一的接口。公开报告是 Chromium issue 548509153。

中段衔接：岛屿跳跃。一次写还不够执行任意代码，还不能碰受保护的代码指针。exploit 改写了 WASM Code Pointer 表的 writable 基址，塞进一个类型正确的替换表项，借用了 XBOW Native Team 早年的"岛屿跳跃"技术：在 Liftoff 生成的 WASM 代码里藏 13 个 64 位立即数作为指令"岛屿"，岛与岛之间用短跳转连接，拼出约 70 字节的 loader，分配可写内存、拷贝 Crashpad 载荷、改成可执行并调用。

第三段：Crashpad，"被冻结"的渲染器其实没冻住。Chrome 的 Crashpad 崩溃处理器运行在渲染器沙盒之外：收到快照请求时先挂起渲染器，再从它的地址空间读数据。问题出在 ProcessMemoryWin::ReadUpTo() 的 ERROR_PARTIAL_COPY 恢复路径——第一次读失败后，它按"请求跨过了可读/不可读页边界"去重试读到页末。这段代码的推理建立在一个时间假设上：被挂起的进程地址空间不会变。但 Windows 允许带 THREAD_CREATE_FLAGS_BYPASS_PROCESS_FREEZE 标志创建的线程跨过 NtSuspendProcess() 继续运行（exploit 用的标志是 0x42）。于是在 Crashpad 把渲染器当作已冻结时，一条免冻线程反复把攻击者控制的源页面在 PAGE_NOACCESS 和 PAGE_READWRITE 之间翻转：第一次小读因整页不可访问而失败，Crashpad 误判为"跨页"；线程把页翻成可读，重试一路读到页末，拷贝的数据超过了调用者要的长度，直接冲掉了堆上相邻的 SnapshotMinidumpMemoryWriter。exploit 精心安排分配顺序，让被改写的 writer 恰好是一个"活"的 writer，随后 Crashpad 走它的虚表进入 WriteObject()，再经 CopyingOutputStreamAdaptor 把受控字节拷到 chrome.exe 的可写地址，最终调用 FallbackCrashHandlerLauncher::LaunchAndWaitForHandler()，执行了 cmd /k calc.exe。Windows 的 ASLR 是按启动而非按进程随机化模块地址，帮 exploit 从渲染器进程推导出了处理器进程的地址。这一段的公开报告是 Chromium issue 545820931。

最惊险的一幕：撞洞之后，数小时换掉整段链

这条链差点死在提交前。第一版的中段用的是一个 Gin 组件的漏洞，提交后发现 Google 早就知道这个 bug（Chromium issue 542670566），整段作废。救场的是开工时就定下的工程纪律：每段独立、接口干净、每段都有备份。团队在"极度煎熬的几小时"里把 Gin 方案整体拔掉，换上了动画 WebP 这一段，链又通了，Google 确认弹出了计算器。

这段插曲值得单独拎出来，因为它揭示了 LLM 时代挖洞的一个新常态：撞洞正在变成主要风险。现在"人人都在把 LLM 对准 Chrome 这样的代码库"，Google 自己也在用大模型扫 Chrome。Dolan-Gavitt 在结论里写得非常直白：作为赏金猎人，如果你拿出的东西不超出 base LLM 的能力，几乎注定撞洞；他自己的第一条完整链就是死在"终段撞上了 Google 几个月前内部发现的 bug"。换句话说，模型拉平了"找到已知模式 bug"的能力，稀缺资源变成了两样东西：对目标的独特理解（知道去哪里找别人没找过的不变式），和拼装成链的工程能力（模块化、可替换、有备份）。XBOW 这次赢，赢在第二样。

六天加四万美元，对六到九个月：成本坍缩是这件事真正的新闻

把三组数字并排看，冲击力才完整。XBOW 自己的回溯估计：前 LLM 时代，一条 Chrome 完整链需要四人团队干 6 到 9 个月；他们自己的第一条链（已经用上 LLM 和 agent）花了约两个月；获奖的这条，六天，约四万美元 API 费。CEO Oege de Moor 转述了一位"三字母情报机构"老兵的话：他的团队过去要花六个月才能找到这类漏洞并拿到完整控制，"我们六天就做到了"。

横向对照更有意思。网络安全媒体提到，漏洞经纪商 Crowdfense 给桌面 Chrome 零日链的广告报价上限是 150 万美元——这是黑市的"天花板价"。而 Google 这次按新规则付了 25 万美元，同一周还把内存安全 bug 的基础赏金翻了四倍到 2000 美元（此前四月刚砍过一轮）。白帽侧的价格在涨，黑市的天花板摆在那里，而生产一条链的成本掉到了四万美元量级。这个三角关系说明：漏洞的"发现成本"正在与"交易价格"脱钩，发现侧在以远快于价格侧的速度贬值。

同一周期的另一条新闻是绝佳的旁证：curl 8.23.0 一次修了 24 个 CVE，AI 审计公司 AISLE 声称其中 18 个是自家 AI 审计找到的。不同的目标、不同的团队，同一个方向——bug 从"存在"到"被找到"之间的时间与价格都在收缩。你的补丁窗口，跟着一起收缩。

人机分工：agent 干了什么，人干了什么

XBOW 的复盘对"AI 包办一切"的叙事做了诚实的降温。agent 用 gpt-5.6-sol（特意选的公开模型，而非受限的网络安全专用模型）做了绝大多数的体力活：读 Chrome 源码、验证假设、写 PoC、搭 exploit 的早期版本，而且是五个战役并行推进。但人类做了所有需要"判断"的事：选目标、给上下文、在 agent 跑偏时把它拽回来、决定把哪几段拼成链、设计可替换的模块接口和备份路线。

Dolan-Gavitt 的原话是"we did apply a fair bit of our own human expertise and judgment"——我们确实投入了相当多的人类专业与判断。他还给了后来者一条方法论：想让 agent 出活，就给它高质量的示例。这次的岛屿跳跃 loader、模块化拼装思路，都来自 XBOW Native Team 成员早年手写的 exploit 技术。也就是说，agent 放大的是已有的顶级人类经验，而不是凭空创造它。六天四万美元买到的，是"一个顶级人类研究员带一群不知疲倦的初级研究员"的生产力，而不是"一个 prompt 换一条 Chrome 链"。

这个区分很重要，因为它决定了这件事的可复制性。XBOW 自己也强调：这不意味着任何人拿四万美元、六天就能复刻一条 Chrome 链。但它确实意味着门槛"显著降低"了——以前只有国家级团队和顶级 boutique 能玩的游戏，现在一个有经验的安全研究员加云端 API 配额就能上桌。

防守侧的三条推论

第一，补丁窗口的假设要重写。过去防守方默认"从漏洞引入到被武器化有数月缓冲"，补丁可以按季度节奏走。当发现侧的成本掉到六天量级，缓冲就只剩"从披露到修复"的工程速度。Chrome 这次其实做得不错：8 月底批准奖金、漏洞在 8 月 25 日和 9 月 3 日的 152.0.7977.65/.82 中修复。但用户侧还有一层延迟——Chrome 自动更新下载了补丁，必须重启浏览器才生效。XBOW 在公告里专门提醒：看到更新按钮就重启，每次都重启。对企业而言，这意味着补丁合规的度量口径要从"是否推送"改成"是否重启生效"。

第二，沙盒的信任边界要重新审计，尤其是"被认为不可变"的假设。三段链里最值得防守方抄作业的是 XBOW 的选点思路：不去硬攻沙盒机制本身，去找威胁模型里"允许但可疑"的义务——下游代码必须防御笼内攻击者的并发修改、transfer 后缓冲的语义、被冻结进程的页保护翻转。Maglev 段违反的是"HeapNumber 不可变"，WebP 段违反的是"transfer 后的字节归我独占"，Crashpad 段违反的是"挂起的进程地址空间不变"。三段全是时间/状态假设在新威胁模型下失效。这类"不变式违反"恰恰是 LLM 最擅长枚举的：它有百科全书级的操作系统 API 和开源代码知识，能系统性地问"这个不变式在什么情况下不成立"。防守方的代码审计清单里，应该给"跨信任边界的不变式假设"单独留一章。

第三，agent 自动化挖洞的治理已经落后了。Google 最近关闭了 OSS VRP 的产品漏洞提交通道，原因正是 AI 生成的报告泛滥成灾。赏金规则在四月改写、十月又上调基础赏金，说明平台方也在边打边调。但更大的治理问题在攻击侧：用公开模型、几万美元就能生产的完整链，犯罪团伙和间谍软件厂商同样用得起。XBOW 的 CEO 说"限制最强模型的访问是问错了问题，因为我们用的模型本来就是公开的"，这话有立场（他卖的就是 AI 攻击能力），但逻辑上难以反驳——管不住供给，就只能加速需求侧：自己先测。

判断区：CEO 的"一年预言"靠谱吗？

Oege de Moor 在获奖公告里写下了一个预言："我们相信，一年之内，这三个 bug 中的每一个，都能被独立工作的 agent 自己找到。"（we believe that within a year, each of the three bugs could be found by agents working on their own.）这是全文最值得拆开检验的一句话。我们把它拆成三层看。

第一层：三个 bug 各自被 agent"找到"，可信度高。注意三个根因的共性——它们都是"违反明确不变式"的 bug：编译器注释里写着 HeapNumberRef 只用于不可变 HeapNumber；transfer 的语义文档写着旧视图被 detach；Crashpad 的重试逻辑写着"被挂起的进程不会变"。这类 bug 的发现模式是"读懂不变式 → 枚举违反场景 → 构造 PoC"，正是 LLM+agent 最擅长的流水线：知识广、能并行试错、不怕读几十万行代码。XBOW 这次三个 bug 本来就是 agent 在人类划定的方向里挖出来的，把"人类划定方向"这一步也交给更强的下一代 agent，一年之内并非夸张。

第二层："独立找到"不等于"独立拼成链"，这里要打折扣。找到三个 bug 和把它们拼成一条从网页到 calc.exe 的可靠链，是两种完全不同的工程。前者是搜索问题，后者是系统集成问题：接口设计、备份路线、撞洞后数小时换段、Windows 版本指纹与偏移重定向、绕过 CET/CFG 的调用序列。这次救场的恰恰是人类预先设计的模块化。预言里说的是"每个 bug 被独立找到"，聪明地避开了"整条链被独立拼出来"。一年之后，我们更可能看到的是"agent 找到 bug，人类拼链"的分工前移，而不是无人值守的端到端武器。

第三层：预言的商业动机要计入折扣，但方向大概率正确。de Moor 卖的是 AI 攻击平台，"一年"这个数字有营销成分。但即使把时间轴放宽到两年、三年，趋势线是清晰的：2026 年初 XBOW 的第一条链还要两个月，年中 agent 已经能六天交出获奖链；curl 那边 AI 审计一次认领 18 个 CVE。能力曲线的斜率摆在那里。真正的问题不是"一年准不准"，而是：当"找到"这个环节被自动化之后，防守方的组织形态跟得上吗？赏金猎人要开始和 agent 拼手速，企业要开始用 agent 先扫自己的代码——de Moor 的另一句话是对的："防守方有一个攻击方永远没有的优势：可以先测自己的代码。"（Defenders have an advantage attackers never will: they can test their own code first.）

我们的判断是：预言的措辞偏乐观、时间偏激进，但它指向的终局——"漏洞发现"从手艺变成算力密集型流水线——正在发生。把"一年"理解成"很快"，把"独立找到"理解成"人类只负责选题和拼装"，这个预言就基本成立。

给写代码的人的三句话

第一，内存安全不再是"最佳实践"，是生存线。三段链里两段是内存安全 bug（Maglev 越界读写、WebP 堆溢出），一段是并发假设 bug。用内存安全语言、开模糊测试、给关键组件加沙盒，过去是加分项，现在是攻击成本坍缩后的必答题。

第二，你用 agent 加速写代码，攻击者用同一类 agent 加速找你的 bug。这就是 vibe coding 时代每个开发者的新对称现实。你每用 agent 多交付一个功能，攻击侧就多一个用 agent 扫你代码的理由。发布前让 agent 先审一遍自己的代码——以攻测防，从"建议"变成"刚需"。

第三，更新 Chrome，现在就去点重启。三个漏洞已在 152.0.7977.82 及更高版本修复，XBOW 确认它们从未被用于真实攻击。但"已修复"和"你已修复"是两回事：补丁只有重启后才生效。去看一眼你的版本号，顺手也把自动更新打开。

六天、四万美元、一条完整链。这组数字会被记住，不是因为它打破了什么技术纪录，而是因为它第一次用一笔 Google 亲手开出的 25 万美元支票，给"攻击成本正在坍缩"这句话盖了个章。Dolan-Gavitt 在长文结尾只留了一句忠告："Six days and $40k is not a lot of time or money when the payoff is a Chrome chain. Defend accordingly."——六天加四万美元，换一条 Chrome 链，不贵。请据此防守。