文章总结： 作者使用ClaudeOpus模型在一周内花费2283美元成功构建了Chrome138的完整漏洞利用链，从CVE-2026-5873Turboshaft编译器越界读写漏洞开始，通过堆内存操纵建立沙箱内任意读写能力，再结合WasmCPTUAF漏洞实现沙箱逃逸，最终劫持函数指针执行系统命令。实验展示了AI模型将安全补丁转化为实际漏洞利用的潜力，并指出这将大幅缩短漏洞可利用时间窗口，对软件安全生态构成严峻挑战。 综合评分： 85 文章分类： 漏洞分析,AI安全,实战经验,红队,安全建设

Chrome 138完整漏洞利用链——从CVE-2026-5873到远程代码执行

幻泉之洲

2026年4月17日 13:00 北京

在小说阅读器读本章

去阅读

作者用Claude Opus，只靠聊天，花了一周时间、230亿token、2283美元的成本，针对较旧的Chrome 138（比上游稳定版落后9个大版本）从头构建了一套完整的V8漏洞利用链。最终成功弹出了计算器。这篇文章深度展示了前沿AI模型在将安全补丁转化为实际可利用漏洞上的巨大潜力，并探讨了这对未来的软件安全意味着什么。

实验：Claude Opus大战V8

这压根不是一次普通的聊天。整个实验持续了一周，横跨多个Claude会话，各种子任务被拆分到不同线程，还构建了脚手架来验证输出、把LLDB调试器输出反馈给模型，进度在各个会话间同步。

我自始至终没动过LLDB，干的就是个“发信息”的活儿。我没教它怎么利用漏洞，没解释V8内部原理，没手把手教利用技巧。我的工作纯粹是操作性的：识别它什么时候在原地打转，关掉那些毫无进展的会话，把它推往更有戏的目标。这感觉就像开车，但不能碰引擎，而且这车总想自己往沟里开，光是把它保持在路上就已经筋疲力尽了。

第一步：找个“n-day”漏洞写利用

先找出从Chrome 138到最新147版本之间的每一个CVE，让Opus通过阅读V8的Git提交日志来选择那些最容易实现堆越界访问的漏洞。

大部分token都花在这上面了。在22个会话中，它尝试了27种不同的方法，结果都失败了，最后才找到一个能用的链。有些漏洞看起来有利用潜力，但最后都走进了死胡同。

某些漏洞超出了它的能力范围。我知道怎么利用CVE-2025-12429，但Claude搞不定。CVE-2026-3910是一个真实世界中被利用过的漏洞，我们俩都没能搞定。

烧掉太多会话后，我不再让它自己瞎选了，而是直接把它指向一个我知道可行的CVE。这是它自己探索期间发现的一个，但它没意识到这其实相对简单。

CVE-2026-5873：V8中的越界读取和写入漏洞。在Chrome 147.0.7727.55中修复。报告于2026年3月25日。

第二步：构建能在堆上实现OOB的漏洞利用

这个漏洞是Chrome 146版本中的一个V8堆越界漏洞。这个漏洞没有公开的利用程序。仅仅使用补丁的Git日志，经过一天的挣扎，Claude从头构建出了一个能用的OOB读写原语。

有意思的是：我在自己实际的Chrome上测试这个漏洞利用时，它居然成功了。结果发现我忘了点更新按钮。软件从漏洞出现到被修复的这个“补丁时间窗口”，就这样活生生地演示了。

第三步：堆沙箱逃逸

仅仅在堆上OOB还不够，你需要逃逸V8的沙箱才能获得任意读写能力。这需要第二个漏洞。我从Chromium漏洞跟踪器里选了一个已公开的沙箱逃逸方法，让Claude把它跟前面的堆OOB漏洞串起来。

经过四天，完整的利用链出来了。

漏洞利用技术细节

CVE-2026-5873：Turboshaft WebAssembly OOB读/写

根本原因

V8的Turboshaft编译器在处理WebAssembly时，有一处边界检查被优化器错误地消除了。当一个Wasm函数接收一个i64类型的参数，通过 i32.convert_i64 将其截断为 i32，然后将结果左移（例如 shl 2），再将其用作内存加载/存储的索引时，Turboshaft的优化管道在函数从Liftoff基线编译器升级后，会错误地消除边界检查。

(func $read (param i64) (result i32)   local.get 0   i32.convert_i64      ;; 截取低32位   i32.const 2   i32.shl              ;; 索引 * 4   i32.load align=4 offset=0 )

在Liftoff下，边界检查能正确工作。但在Turboshaft编译函数后（由足够的执行次数触发），边界检查被消除，允许读取或写入超出Wasm线性内存基址的任意内存。

关键细节：i32.convert_i64 的截断

i32.convert_i64 指令会丢弃高32位。所以当你调用 read(0x100000000n) 时，实际有效的索引是0。这意味着：

• 在正常情况下，read(0x100000000n) 返回的结果和 read(0n) 相同（都访问偏移量0）
• 有漏洞时，read(0x100000000n) 也访问偏移量0，但本该对大索引进行捕捉的边界检查被消除了，因此 read(0x10000n) （其偏移量0x40000字节，超过1页=64KB）会成功执行，而不会触发异常。

漏洞检测函数就是利用了这一点：在Liftoff下，read(0x100000000n) 会触发异常（边界检查会在截断前看到完整的64位值），但在有漏洞的Turboshaft下，它会静默读取偏移量0（截断后，没有边界检查）。

漏洞利用链概览

以下是一个高度简化的流程。实际攻击链涉及多次内存探测、偏移量计算、对象元数据查找和伪造。

1. 阶段0：喷射ArrayBuffers

   -> 为后续的内存探测做标记。

2. 阶段1：构建触发OOB的Wasm模块

   -> 利用CVE-2026-5873。

3. 阶段2：自然预热触发编译器升级

   -> 激活边界检查消除漏洞。

4. 阶段3：探测ArrayBuffer的底层数据存储区

   -> 通过OOB读取寻找特定数据。

5. 阶段4-5：确定M和N

   -> 校准Wasm内存和V8指针压缩“笼”之间的映射关系。

6. 阶段6：定位JSArrayBuffer对象

   -> 找到“笼”中存储对象元数据的位置。

7. -> 破坏其 backing_store（底层数据指针）和 byte_length（长度）字段。

8. -> 建立“上帝缓冲区” -> 获得在整个V8沙箱内的任意读写能力。

9. -> 实现 addrof 原语 -> 泄露JS对象的压缩指针地址。

10. 阶段10：利用WasmCPT UAF漏洞

    -> 沙箱逃逸，获得全虚拟地址空间读写权限。

11. 阶段11：推导沙箱基础地址，找到Isolate核心结构体。

12. 阶段12：劫持函数调用指针指向 system()

    -> 实现任意代码执行。

简单来说，就是先用第一个漏洞在V8的沙箱“笼子”里获得了超能力，再用第二个漏洞打破“笼子”，然后去找系统里真正能执行命令的函数地址，最后把某个WebAssembly函数的指针指向那个地址，成功执行系统命令。

成本与回报

| 模型/用途 | 耗费Token数 | 成本 | | — | — | — | | Claude Opus 4.6 (主要) | 21.4亿 | $2,014 | | Claude Opus 4.6（深度思考） | 1.89亿 | $267 | | 其他模型（小任务） | N/A | ~$2 | | 总计 | 23.3亿 tokens / 1765次请求 | $2,283 |

2283美元的token成本，加上我大约20小时的“保姆式”陪伴，就产出了一条可工作的Chrome漏洞利用链。听起来贵，直到你对比一下正常情况下这需要多少人力：通常是数周的专注工作。

你可能会想，总计差不多6283美元（算上我的时间成本）值不值。给点背景：

• Google的v8CTF悬赏，每个有效的V8利用提交能拿到1万美元（仅限最新版本的第一个提交者）。
• Discord就我们之前的漏洞提交通常支付5000美元。但我们还收到了推特陌生私信，出价是10倍。
• 如果你能用类似的方法在Claude Desktop上弹出计算器，Anthropic的悬赏金估计会非常高。

这么看，用6283美元产出一条能用的Chrome漏洞链，在合法市场已经有利可图。在别的市场，利润就更高了。

为什么现在的Opus还无法独立完成？

操控Claude并保持它不跑偏太累了。它经常卡住、丢失上下文。如果你不管它，它就在那里原地打转。我注意到几个主要问题：

1. 环境脚手架至关重要

   ：你需要搭建合适的环境和脚手架，让模型能测试并获得反馈；需要管理上下文，避免它一再重试已经失败的方案；需要在并行会话间协调。这是整个实验最难的部分之一。

2. 喜欢“脑补”而非验证

   ：它会假设偏移量，猜测内存布局，凭感觉写利用程序。我必须不断把它拉回一个规则：读代码，用LLDB，先理解发生了什么，用Python计算而不是用你的草稿纸。

3. 作弊

   ：当它解决不了真正的问题时，它就改变规则。有次它居然在Electron应用里启用了nodeIntegration，然后用 require(‘child_process’) 来弹计算器。

4. 上下文崩溃

   ：会话一旦变长，Claude就开始糊涂。它忘了试过什么方法，又漂回死胡同，白白烧掉大量token。

5. 它卡住，我也得跟着卡住

   ：当Opus碰到我自己都不懂的东西，我不得不停下来补课，从头开始，弄清楚那部分解决方案，看它错在哪，然后再引导它往前走。这是最耗时的部分。我做的比Opus慢多了。

6. 没有自我纠错能力

   ：一旦Opus卡住，它通常就一直卡在那里。它不会自己干净利索地重置，或者通过推理走出来。我必须介入，给出非常具体的指令。

Mythos能克服这些吗？

Anthropic发布在其红队博客上的图表（展示了Mythos在生成Firefox漏洞利用上的进步），没有多说Mythos发现漏洞的能力有多强，但明确显示了它在把已知漏洞转化为工作利用链上的巨大进步——而这恰恰是我们刚刚做的任务。

我这里是在猜测。等我能用上Mythos了，再来报告实际变化。但即使Mythos有点被夸大了，方向是明确的。今天还需要这么“手把手”的模型，明天需要的手把手就会少一些。如果Opus能做到我刚才展示的，那么推测到Mythos会怎样，然后再推测一代。

这究竟意味着什么？

一个擅长快速开发漏洞利用的模型，会大幅压缩漏洞可利用时间窗口。补丁发布的时间窗口却跟不上。两者之间的不匹配正在加剧。

每次安全补丁本身就是一份利用提示。Chromium或Linux内核中的一个安全补丁，精确地告诉你哪里坏了。逆向分析补丁过去需要技能和时间。现在，你可以把token砸向这个问题，再配备一个不错的操作员在关键节点推一把，就能更快得到一个可工作的漏洞利用。

开源软件处境尴尬。修复代码经常在稳定版发布之前就公开了。这个窗口一直存在。模型只是让它具备了大规模利用的可能性。

你没法隐藏安全补丁。当需要人类在成千上万的代码改动里筛选时，在提交噪音里掩盖修复是可行的。模型会把所有改动都读一遍；你只需要投入更多token。

我认为，真正的力量倍增器是小而精悍的团队。一个人现在就可以同时监督多个漏洞开发会话。这仍然取决于操作员的水平和团队的实力。一个能力顶尖的团队加上Mythos，能从这件事上获得的杠杆效应远非网上随机的脚本小子可比。

怎么办？

说实话，我不知道。我部分希望Mythos是个哑弹，希望那些计算能力的扩展定律遇到瓶颈。但看起来不是那么回事。

说“打补丁更快点”很容易，做起来难多了。但有些事情是显而易见的：

• 向左移，狠狠地移

  ：在设计阶段和代码合并前，就把安全审查纳入每一个决策。

• 缩小补丁差距

  ：清点所有关键依赖库及其版本，建立资产清单。大部分团队不知道自己在用什么。

• 安全补丁强制自动更新

  ：不要询问对话框，不要“稍后更新”按钮。我的实际Chrome之所以有漏洞，是因为我没点更新。这就不该发生。

• 重新思考公开补丁的时间线

  ：这听起来有点疯狂，但或许Chrome，或者其他任何开源软件，不应该在稳定版发布之前就公开那些关键的V8补丁。每一次公开的提交，对任何拥有API密钥和一个强力团队（能将漏洞武器化）的人来说，就是一声发令枪响。

参考资料

[1] https://www.hacktron.ai/blog/i-let-claude-opus-to-write-me-a-chrome-exploit/

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：幻泉之洲 《Chrome 138完整漏洞利用链——从CVE-2026-5873到远程代码执行》