文章总结： Chrome153前版本存在CVE-2026-87491在野利用漏洞，属Medium级V8越界写缺陷，CVSS评分8.8，修复需升级至153.0.8010.36或更高版本并重启浏览器。Edge用户已于9月4日通过152.0.4191.66获得防护。该漏洞利用WebAssembly异常处理路径，企业可通过禁用WebAssembly临时缓解但无法替代补丁。建议立即更新并重启进程以确保生效。
综合评分： 85
文章分类： 漏洞预警,WEB安全,安全大事件,恶意软件,威胁情报
五个 V8 漏洞里唯一的 Medium：Chrome 在野0Day CVE-2026-87491
Ots安全
2026年9月16日 13:04
广东
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
威胁简报
恶意软件
漏洞攻击
2026 年 9 月 9 日，美国网络安全和基础设施安全局把 CVE-2026-87491 收进了已知被利用漏洞目录，给出的修复截止日是 9 月 23 日。此前一天，Google 在 Chrome 153 稳定版更新里提到，这个编号的漏洞利用已经在野外出现。这是 2026 年 Chrome 修补的第七个在野利用零日，也是五天之内第二个落在 V8 引擎上的。
让人意外的地方在于定级。Chromium 安全团队给它的是 Medium，而同一次更新里还有四个 V8 漏洞被标为 High，那四个没有一个被确认在野利用。公开 exploit 在补丁发布两天后就出现在代码托管平台上，两个仓库都把 CVE-2026-87491 与五天前修补的 CVE-2026-85046 串成一条链。
更值得关注的是根因的形态。修复提交在 V8 源码里删掉了一段实现，而那段实现的正上方，另一份描述文件里留着一句工程师注释，写着这条路径”从当前调用方到不了”。这句话就是漏洞本身。本文核对官方公告、补丁 diff、上游源码与公开 exploit 的自述，把能确认的与确认不了的分开写。
一、先看问题：编号、评分与五天的间隔
CVE-2026-87491 由 Chrome 作为 CNA 分配，9 月 8 日 22 时 38 分保留编号，9 月 9 日 0 时 09 分公开发布。官方描述是一句模板化的表述。
Out of bounds write in V8 in Google Chrome prior to 153.0.8010.36 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: Medium)
这段话里有三个可核实的点：缺陷类型是 V8 中的越界写，受影响的是 153.0.8010.36 之前的版本，能力边界是”沙箱内执行任意代码”。括号里的 Medium 是 Chromium 项目自己的定级口径，与后加的 CVSS 评分不是一套体系。
CISA 的漏洞富化流程给出的评分是另一回事。同一份记录里，CVSS 3.1 基础分 8.8，向量 AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H。美国国家漏洞数据库截至本文写作时仍未给出评分，页面上写的是 N/A。也就是说，同一个编号存在官方未评分与第三方 8.8 并存的局面，而 Chromium 自己的 Medium 既不是前者也不是后者。
真正需要解释的落差不在评分，在同一批次里的横向对比。Chrome 153 一共修了 230 个安全问题，其中 V8 相关的有九个：
| 报告日 | 定级 | 编号 | 赏金 | 缺陷类型 |
| — | — | — | — | — |
| 2026-07-09 | Medium | CVE-2026-87625 | 未列 | V8 释放后使用 |
| 2026-07-27 | Low | CVE-2026-87489 | 未列 | V8 内存损坏 |
| 2026-08-01 | Low | CVE-2026-87601 | 待定 | V8 竞态 |
| 2026-08-03 | Medium | CVE-2026-87657 | $1,000 | V8 释放后使用 |
| 2026-08-06 | Medium | CVE-2026-87491 | $2,500 | V8 越界写 |
| 2026-08-21 | High | CVE-2026-87587 | 待定 | V8 释放后使用 |
| 2026-08-25 | High | CVE-2026-87564 | 待定 | V8 类型混淆 |
| 2026-08-29 | High | CVE-2026-87612 | 待定 | V8 类型混淆 |
| 2026-08-29 | High | CVE-2026-87536 | 待定 | V8 释放后使用 |
四个定级更高的 V8 漏洞都没有被确认利用。本文主角是九个里唯一一个被写明”在野外存在利用”的，定级却只是 Medium。这个组合恰好说明，Chromium 的定级描述的是单个缺陷自身的影响范围，不描述它正在被谁使用。
时间线上的另一个数字更值得注意。CVE-2026-85046 是 V8 类型混淆，Chrome 在 152.0.7977.82 中修复，发布日 9 月 3 日，次日进 KEV。五天之后 9 月 8 日，Chrome 153.0.8010.36 修掉了本文主角，9 月 9 日进 KEV。两个编号都在 V8 上，两个都被确认在野利用，中间隔了五天。
Google 在公告里没有说明利用细节、攻击目标或使用者身份，只说了一句”Google is aware that an exploit for CVE-2026-87491 exists in the wild.”。按其一贯做法，缺陷详情与链接会保持受限状态，直到大部分用户完成更新。
一个容易被忽略的细节是报告的集中度。这三个 V8 漏洞由同一位研究者 Jihyeon Jeong 在同一批次内提交，他是首尔大学 Compsec Lab 的研究实习生：8 月 3 日的 CVE-2026-87657 拿 $1,000，8 月 6 日的 CVE-2026-87491 拿 $2,500，8 月 21 日的 CVE-2026-87587 定级 High 且赏金待定。同一个人一个月内在同一个引擎上连报三个内存安全问题，其中一个后来演变成在野零日，说明 V8 的攻击面密度依然很高。
把 Medium 读成”不重要”，或者把 8.8 读成”已能控制主机”，两个方向都会误导读者。 前者忽略了在野利用这个事实，后者忽略了缺陷自身的能力边界。
二、影响范围：上游版本、下游分支与网页侧的可达性
2.1 Chrome 的版本区间
Chrome 侧的判定很干净：稳定版低于 153.0.8010.36 就受影响，Windows 与 macOS 的对应版本是 153.0.8010.36 与 153.0.8010.37，Linux 是 153.0.8010.36。CVE 记录的受影响区间写法是 lessThan: 153.0.8010.36。
2.2 下游分支的修复落差
Chromium 系浏览器需要单独判定，因为修复进入上游仓库之后，各家 cherry-pick 到哪条分支、何时发版，各自决定。这里出现了本篇最反直觉的一个事实：Microsoft 在官方发布说明里写明，2026 年 9 月 4 日发布的 Edge 稳定版 152.0.4191.66 就包含了 CVE-2026-87491 的修复，并注明”Chromium 团队报告称 CVE-2026-87491 存在漏洞/在野利用”。Edge 的修复比 Chrome 自己早了四天。
| 时间 | Chrome | Edge |
| — | — | — |
| CVE-2026-85046 修复 | 152.0.7977.82（9 月 3 日） | 152.0.4191.62（9 月 2 日） |
| CVE-2026-87491 修复 | 153.0.8010.36（9 月 8 日） | 152.0.4191.66（9 月 4 日） |
“Chrome 是上游，所以 Chrome 用户先拿到修复”这个直觉在本次不成立。 上游指的是代码库，不是发版节奏。Edge 把修复回填到了 152 分支，Chrome 把它放进了 153 主版本，于是下游用户比上游主产品用户提早四天得到保护。这四天里，Edge 用户的攻击窗口关闭了，Chrome 用户的还开着。
需要留意的一处转述失准：某漏洞情报平台给出的 Edge 处置建议是”升级到 151 通道的 151.0.4129.107 或更高，或 152 通道的 152.0.4191.66 或更高”。但按 Microsoft 官方发布说明，151.0.4129.107 的发布日是 8 月 31 日，早于该修复进入分支的时间。按这条建议把 Edge 停在 151 最新版的设备，仍然没有这道修复。 可执行的版本下限只有 152.0.4191.66。
2.3 网页侧的那条可达路径
前一项判的是浏览器版本，这一项判的是攻击面本身是否打开。缺陷的触发路径经过 WebAssembly 的异常处理，具体是 WebAssembly.Exception 与异常解包流程。一个完全不使用 WebAssembly 的浏览环境，这条链没有入口。
这一项的意义在于它是唯一能主动收敛的条件。企业侧如果通过策略关闭 WebAssembly，或者站点本身不加载任何 wasm 模块，那么即便浏览器版本落后，这条特定路径也走不通。Chrome 的企业策略支持按站点或全局禁用该特性。
需要把话说清楚：关掉 WebAssembly 只是关掉这一条路径，不修复底层的越界写。同一批次里四个定级更高的 V8 漏洞与 WebAssembly 无关，其中三个是释放后使用、两个是类型混淆，走的是普通 JavaScript 路径。以策略替代补丁，挡住的只是本次这一条链，不构成一般性防护。
2.4 无需前置权限，但要那一次重启
第三项判的是权限前置，而它的结论是反向的：这个漏洞不需要任何前置权限。CVSS 向量里的 PR:N 与 CISA 富化记录里的 Exploits: active 都指向同一点，攻击者只需要让受害者用未修复的浏览器打开一个页面。
同一份向量里的 UI:R 说明需要用户交互，这一项的实质内容是”访问页面”本身。CISA 的 SSVC 评估把 Automatable 判为 no，理由也在这里：它不能像蠕虫那样自行扩散，需要把受害者引到承载页面上。CISA 同时把 Technical Impact 判为 total，指的是缺陷被利用后对目标的破坏程度，与自动化难度是两个维度。
真正需要单独判定的是部署状态。Chrome 的更新在后台下载，新版本要等浏览器进程重启才会真正替换运行中的二进制。只看到”已更新到 153″的提示、没有重启浏览器或退出全部 Chrome 进程的终端，运行的仍是旧版本。 这一项在补丁日之后往往比版本号本身更能决定处置是否有效。
三、原因导致：一处会调用 getter 的内置函数
3.1 私有符号与内置函数的职责
V8 在内部用私有符号给某些对象打标记，wasm_exception_tag_symbol 与 wasm_exception_values_symbol 就是其中两个，WebAssembly 异常对象靠它们存放标签与取值。WasmGetOwnProperty 这个内置函数的作用是检查对象上是否存在这类私有符号，属于 GetOwnProperty 行为的一个特化版本。
按设计意图，它只需要回答”这个对象上有没有这个符号”，不需要取值，更不需要让任何用户代码参与进来。这个意图决定了后文全部的技术走向。
3.2 契约写在注释里
它的语义约束被明确写在源码注释里。当前上游 src/builtins/builtins-wasm-gen.cc 中，该内置函数定义的上方有这几行：
// Wasm uses private symbols (e.g. wasm_exception_tag_symbol) to stamp certain// objects. This builtin checks for presence of such symbols; it is a// specialization of "GetOwnProperty" behavior: if the object is not a plain// JS objector the propertyisnot an own data property, return undefined.// To allow compilers to assume no side effects from this builtin, it's// particularly important to not invoke any getters.
这句注释是全部问题的起点：为了让编译器能假定这个内置函数无副作用，特别重要的是不调用任何 getter。 编译器作这个假定的目的很实际。优化后的代码在一个代码区间内需要知道哪些状态会变，内置函数每次被调用都去保守地重新读取状态，优化就失去了空间。
问题在于这条约束在当时没有被实现守住。
3.3 会走到 GetPropertyWithReceiver 的旧实现
修复前的 WasmGetOwnProperty 并不在上面那个 C++ 文件里，而是用 Torque 写在同一目录族的 src/builtins/wasm.tq 中。修复提交把这整段实现删掉了。
删除内容里的关键两行是这样的：
const receiver: JSReceiver = Cast<JSReceiver>(heapObject) otherwise NotFound;try { TryHasOwnProperty( receiver, receiver.map, receiver.instanceType, uniqueName) otherwise Found, NotFound, NotFound;} label Found { return GetPropertyWithReceiver( receiver, uniqueName, receiver, SmiConstant(kReturnUndefined));}
第一层判断是 TryHasOwnProperty，它确实只查自有属性。但命中之后走的是 GetPropertyWithReceiver，这是一个完整的属性读取入口。自有属性存在并不意味着读取过程不会执行用户代码，属性本身可以定义成访问器，而 GetPropertyWithReceiver 会调用它。
这就构成了一个直接矛盾：注释要求”不调用任何 getter”，实现里却保留了一条能调用 getter 的分支。引擎内部在解包 WasmExceptionPackage 时会调用这个内置函数，而攻击者只要能构造出符合条件的对象，就能让引擎在解包过程中执行自己提供的 JavaScript。
3.4 编译器侧那句”到不了”
矛盾之所以长期没有暴露，是因为编译器一侧也做了配合，而这个配合被写成注释留在了代码里。Turboshaft 优化编译器在 src/compiler/turboshaft/builtin-call-descriptors.h 中为每个可调用内置函数登记副作用描述，修复提交把这一段也改了。
修复前的版本这样写：
staticconstexprbool kNeedsContext = false;staticconstexpr ClobberingOpProperties = Operator::kNoThrow;// Calls {GetPropertyWithReceiver} which has paths that can allocate.// But from this caller we won't reach them. Nevertheless, to please the// verifier we currently have no other choice than setting the CanAllocate// effect here.// TODO(verwaest): Support overriding the automatic can-allocate// inference.staticconstexpr OpEffects kEffects = base_effects.CanReadHeapMemory().CanAllocate();
第二行把该内置函数标记为 kNoThrow，即认为它不会抛出异常。注释则承认它会调用 GetPropertyWithReceiver，也承认那条路径上存在可分配的代码段，然后用一句判断把它们放行了：“但从这个调用方我们到不了那里”。
这个判断是整条链的技术核心。它把风险建立在”当前所有调用方都不会走到那条路径”这个前提上，而不是建立在实现本身的安全性上。前提一旦被打破，编译器就会按照”这个调用无副作用、不会抛异常”的假设继续优化，而实际执行已经发生了状态改变。
修复后的版本删掉了 kNeedsContext，注释改成了关于 MutableHeapNumber 的可分配性说明，并保留了 kNoThrow。区别不在于缩进几个空格，而在于实现真的不再需要上下文、不再需要调用 getter 之后，那句放行判断才变得成立。 顺序在这里很重要：先让实现守住契约，注释才有资格陈述契约。
四、漏洞触发：伪造 getter 改写函数表
4.1 从真实异常对象里取出私有符号
触发的前提是让引擎在解包异常时去读一个由攻击者控制的属性。引擎内部读的是私有符号，私有符号不出现在 JavaScript 可见的符号集合里，所以不能直接用名字访问。
公开 exploit 的做法是从一个真实的异常对象反向取出来。它先创建一个合法的 WebAssembly.Exception，再从这个对象的描述符数组里把符号类型的那个槽位读出来。
// Recover the private exception-tag symbol from a genuine exception.const genuine = newWebAssembly.Exception(newWebAssembly.Tag({parameters: []}), []);const genuineDescriptors = descriptorArrayOf(genuine);const hiddenTagSymbol = findTaggedWord(genuineDescriptors, 'SYMBOL_TYPE').value;
这一段的性质是地址与槽位的读取，本身不构成利用。它的价值在于说明私有符号并非不可获取：只要能从任意一个真实对象上把它读出来，就可以用它去构造自己的对象。“私有”在这里指的是不导出到语言层，不等于拿不到，这一点在依赖私有符号做完整性判断的设计里需要单独评估。
4.2 伪造 getter 与函数表的一次改写
拿到符号之后，攻击者构造一个普通对象，在其上定义一个访问器属性，然后把刚取出的私有符号作为键放进去。引擎在解包异常时会按这个符号去读属性，于是走到访问器，执行攻击者提供的函数。
let getterCount = 0;const forged = Object.defineProperty({}, 'x', { get() { ++getterCount; table.set(0, d.exports.target); returnundefined; }, configurable:true,});
这个 getter 里只有一句实质动作：table.set(0, d.exports.target)，把共享函数表第 0 项改写成另一个实例导出的函数。按上一章的契约，这个时刻引擎应当处在”本次属性读取不产生副作用”的假设之下，而实际发生的是函数表被改写。
后面的链条由此展开。exploit 让两个 WebAssembly 实例共享同一张导入函数表与同一个标签，getter 在优化编译完成之后被调用，编译器已经按”无副作用”把函数表的内容与其他隐式元数据固定下来，于是保留了实例 A 的陈旧元数据，实际派发却落到了实例 D 的目标函数上。实例 D 使用内存索引 6，按 exploit 的断言与实例 A 的可执行跳转表区域别名，由此得到对已编译 wasm 代码的读写能力，改写代码后调用即完成执行。
必须说明边界：本文不提供该链的构造代码，也不复现其地址布局。 这一段的作用是佐证普通一点的结论，即 CVE-2026-87491 在整条链中承担的是”打破编译器假设”这一环，它把一次本应无副作用的内置函数调用，变成了攻击者可插入状态改变的时机。
4.3 陈旧元数据为何能存活到派发时刻
到这里需要回答一个更基础的问题：为什么一次函数表改写能让引擎在错误的前提下继续执行。原因在优化编译的时间线。JavaScript 引擎对热点函数做优化时，会把此刻观察到的对象形状、函数表内容、调用目标等写成假设，生成只在这些假设成立时才正确的机器码。执行期间若假设被打破，引擎有机制把代码退回未优化状态，这个动作需要被触发。
触发的前提是引擎知道假设被打破了。在无副作用的假设之下，内置函数调用被视作不影响这些前提的事件，于是没有触发任何失效检查。 函数表在第 0 项上被替换，而依赖该表项的优化代码继续按旧内容派发，指针与元数据就此错位。这也解释了为什么缺陷被归到越界写：错位之后的写入落在按旧布局计算的位置上，超出了对应缓冲区的真实边界。
4.4 作者自己划下的能力边界
关于这个漏洞能走多远，最可靠的说法来自公开 exploit 的作者。仓库 README 的结尾只有一句：
To go any further you’d have to have an local priv esc of sorts.
译文是，想再往前走一步，得另外有一个本地提权之类的东西。这是 exploit 作者对自己作品边界的陈述，与官方描述里的”沙箱内执行任意代码”相互印证。作者同时说明了这个仓库的运行方式：起一个本地服务，最多尝试五次全新配置，抓到渲染进程输出的成功字样即停。
第三方平台对同一件事有另一种表述，把它描述为”多漏洞利用链中与 WebAssembly 相关的 V8 沙箱逃逸组件”。这个措辞容易被读成”已经逃出浏览器沙箱”，与 exploit 作者的自述并不一致。准确的位置是：该缺陷提供的是渲染进程内的代码执行原语，从渲染进程到主机操作系统之间还隔着浏览器沙箱这一层，需要额外漏洞才能跨越。 原文配图给出的技术描述与 exploit README 一致，两者都把终点定在本地提权之前。
五、补丁分析：一次搬迁与两处注释
5.1 从 Torque 搬到 C++
修复提交的题目是 [wasm][sandbox] Fix side effects of WasmGetOwnProperty builtin，提交说明只有两句，第二句直接对应上一章的判断。
We want this builtin to have no side effects, so it should not invoke any getters.
修复方式不是删掉 GetPropertyWithReceiver 那一行，而是把整个内置函数从 Torque 实现搬迁到 C++ 的代码桩汇编实现。新实现在 builtins-wasm-gen.cc 中，路径换成先查自有属性、再按属性种类判定：
TNode<Uint32T> kind = DecodeWord32<PropertyDetails::KindField>(var_details.value());constexprint kData = static_cast<int>(PropertyKind::kData);GotoIfNot(Word32Equal(kind, Int32Constant(kData)), &return_undefined);GotoIfLazyClosure(CAST(var_value.value()), &return_undefined);Return(var_value.value());
键在倒数第三行：属性种类必须等于 kData，也就是普通数据属性，否则直接返回 undefined。访问器属性在新的判定下不再返回取值，因为不再有取值这个过程。 查找本身也换成了 TryLookupPropertyInSimpleObject 与 LoadPropertyFromFastObject、LoadPropertyFromDictionary，这三者都只读元数据与槽位，不执行用户代码。
作者是 Jakob Kummerow，前后两版的审阅者都是 Thibaud Michaud。改动通过 chromium-review 完成，评审地址是 https://chromium-review.googlesource.com/c/v8/v8/+/8234942，变更标识 Ifa3c166e54f2084524c562ba2f57d55e0a51bff6，提交位置 refs/heads/main@{#109190}，提交说明中的 Fixed: 543557673 与 CVE 记录里引用的 Chromium 缺陷编号一致。
5.2 两处注释的同步
补丁同时改了 Turboshaft 侧的描述符，这一处改动比实现搬迁更容易被漏掉。前面看到的 kNoThrow 标记在新版本里保留了下来，kNeedsContext 被删除，注释换成了关于堆数字可分配性的说明。
保留 kNoThrow 是合理的选择，前提是实现真的不再调用任意用户代码。摘掉 kNeedsContext 则是因为新实现不再需要上下文参数，这一点恰好是”不调用 getter”在接口层面的体现。搬迁本身才是修复，描述符的同步是让编译器侧的声明与实现重新对齐。 两者缺一，要么实现仍然可被重入，要么编译器继续按错误的副作用模型优化。
5.3 与前一编号的关系
CVE-2026-85046 与本文主角是同一周修补的两个 V8 缺陷，类型不同：前者是类型混淆，走的是 sort() 期间的打包对象与整数数组混淆；后者是越界写，走的是异常解包期间的内置函数重入。两者的修补时间相差五天。
公开 exploit 把两者串成一条链，用前者取得 V8 cage 内的读写原语，再用后者取得对已编译 wasm 代码的改写能力。这说明在野利用与公开 exploit 采用了相近的组合思路。但这一相似不构成两个缺陷同源的证据，官方未披露在野利用的技术细节，公开仓库的自述也只说明了自己的构造方式。把”公开 exploit 这么串”读成”在野攻击也这么串”，是这一步常见的过度推断。
5.4 未随补丁一起公开的部分
补丁能读出根因，读不出在野利用的样子。Google 在公告里只确认了”存在利用”这件事，没有说明投递方式、攻击目标、使用者身份，也没有给出任何可用于检测的产物。Chromium 的缺陷条目 543557673 在本文写作时仍处于受限状态，访问不到修复前的讨论与复现步骤。
CISA 的 KEV 条目提供了两个字段：knownRansomwareCampaignUse 为 Unknown，forensicTriage 为 No。前者表示尚无与勒索活动关联的公开记录，后者表示本次收录没有附加强制取证要求。这两个字段描述的是公开信息的状态，不是威胁本身的状态。 把 Unknown 读成”确认与勒索无关”，属于典型的越界解读。
判断在野利用长什么样，还有一个容易走偏的地方。公开 exploit 有两条，都创建于补丁发布之后，都给出了自己的构造路径。它们的价值是证明这条链在技术上可行，但公开仓库的存在不能反推在野利用采用了同一套构造。两者可能共享同一处根因，也可能在触发方式上完全不同，而后者恰恰是公开信息无法回答的部分。
六、结束语
这个案例值得记住的地方，不在漏洞本身有多复杂，而在它暴露的判定失误形态。一个”不调用 getter”的契约被写进了注释，实现里却保留着一条能调用 getter 的分支，编译器一侧则用”从这个调用方到不了那里”把矛盾放行。三层代码，三处都在陈述同一件事应当如何，没有一处去验证它是否如此。
从 8 月 6 日报告到 9 月 8 日修复，33 天。Chromium 上游先修，下游各自回填，Edge 在 9 月 4 日就拿到了修复，比 Chrome 自己早四天。渠道差异在这次具体地体现为四天攻击窗口，而 KEV 的十四条摘要按 Chrome 口径书写。补丁进入代码库的时间与用户受保护的时间是两件事，中间隔着的差距需要按产品分别核算。
公开 exploit 在修复发布两天后出现，第一个仓库创建于 9 月 10 日，第二个在 9 月 12 日，都给出了完整的链条自述。而 Google 公告里那句”缺陷详情与链接会保持受限，直到大部分用户完成更新”在同一周内被外部现实绕过。这说明对于位于渲染进程内的内存安全缺陷，官方限制发布信息的做法只能延迟细节扩散，不能阻止有能力的研究者从补丁本身反推。
唯有把内置函数的副作用契约当作必须验证的实现约束而非注释里的声明，把下游分支的修复时点当作影响范围的一部分而不仅是版本号列表，把”更新已下载”与”补丁已生效”分开核算，才能让这类缺陷在下一个五天的间隔里不再重复同一种失误。
七、参考
官方公告与记录
- Chrome 稳定版更新公告（含 230 项修复清单与 87491 条目），Google，
https://chromereleases.googleblog.com/2026/09/stable-channel-update-for-desktop_0808145027.html - Chrome 稳定版更新公告（CVE-2026-85046 所在批次），Google，
https://chromereleases.googleblog.com/2026/09/stable-channel-update-for-desktop_01882797386.html - CVE-2026-87491 官方记录（Chrome CNA，含 CISA-ADP 富化），
https://cveawg.mitre.org/api/cve/CVE-2026-87491 - CVE-2026-85046 官方记录，
https://cveawg.mitre.org/api/cve/CVE-2026-85046 - CISA 已知被利用漏洞目录条目（收录日 2026-09-09，截止日 2026-09-23），
https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json - Microsoft Edge 安全更新发布说明（含 9 月 4 日 152.0.4191.66 条目），Microsoft，
https://learn.microsoft.com/en-us/deployedge/microsoft-edge-relnotes-security - Chromium 缺陷条目（写作时仍受限），编号 543557673，
https://issues.chromium.org/issues/543557673
补丁与源码
- 修复提交
[wasm][sandbox] Fix side effects of WasmGetOwnProperty builtin，Jakob Kummerow，变更标识Ifa3c166e54f2084524c562ba2f57d55e0a51bff6，评审地址https://chromium-review.googlesource.com/c/v8/v8/+/8234942 - 修复后实现，
https://raw.githubusercontent.com/v8/v8/main/src/builtins/builtins-wasm-gen.cc（WasmGetOwnProperty定义及其上方契约注释） - 修复后描述符，
https://raw.githubusercontent.com/v8/v8/main/src/compiler/turboshaft/builtin-call-descriptors.h - 异常对象实现，
https://raw.githubusercontent.com/v8/v8/main/src/wasm/wasm-objects.cc（WasmExceptionPackage相关方法）
公开 exploit 与分析
- 原文，《0-Day Alert: Chrome v8 RCE》，Zero Day Engineering，2026-09-15，
https://intelligence.zerodayengineering.com/0-day-alert-cve-2026-87491/ - 同站前一编号快讯，《0-Day Alert: Chrome v8 RCE》，2026-09-08，
https://intelligence.zerodayengineering.com/0-day-alert-cve-2026-85046/ - 公开 exploit 仓库一，SneakyNachos，2026-09-10 创建，
https://github.com/SneakyNachos/CVE-2026-87491-and-CVE-2026-85046-the-bagel-fell-off-the-counter - 公开 exploit 仓库二，SneakyNachos，2026-09-12 创建，
https://github.com/SneakyNachos/CVE-2026-87575-CVE-2026-87606-CVE-2026-87491-and-CVE-2026-85046.-Escape-the-v8-carcass.
END
公众号内容都来自国外等平台- 搜索的内容通过结合编写 –
提供整洁 – 广告已关
公众号 | AnQuan7 (Ots安全)
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：Ots安全 《五个 V8 漏洞里唯一的 Medium：Chrome 在野0Day CVE-2026-87491》