TheMalwareGuardian/CVE-2026-5281

GitHub: TheMalwareGuardian/CVE-2026-5281

针对Chrome Dawn WebGPU组件UAF漏洞CVE-2026-5281的深度技术分析与验证工具集。

Stars: 1 | Forks: 0

# ***⚡ CVE-2026-5281 - Chrome Dawn WebGPU Use-After-Free*** ![CWE](https://img.shields.io/badge/CWE--416-Use%20After%20Free-red?style=for-the-badge&logo=databricks&logoColor=white) ![Status](https://img.shields.io/badge/Status-Exploited%20In%20The%20Wild-critical?style=for-the-badge&logo=hackaday&logoColor=white) ![Fixed In](https://img.shields.io/badge/Fixed%20In-Chrome%20146.0.7680.178-brightgreen?style=for-the-badge&logo=googlechrome&logoColor=white)

此漏洞影响了我们提供服务的客户之一。该仓库是我们对原始研究的贡献:为团队提供一个集中化的起点,以便如果再次出现影响该组件的类似漏洞,我们已经具备基础。它汇集了漏洞背后的理论、对原始研究人员发现的文档化摘要,以及在实验室环境中验证暴露情况的一套实用工具。

注意:我本希望分享更多这项研究,但由于公司限制,我不能进一步披露。此处包含的所有内容都经过了审查,不违反我受约束的任何协议。因此,该仓库以当前状态归档。

## ***📑 目录***
## ***📌 背景与目的*** 2026 年 4 月 1 日,Google 发布了 Chrome 安全更新,修复了 21 个漏洞,其中之一 CVE-2026-5281 在披露时已被在野积极利用。三天后,CISA 将其添加到“已知已利用漏洞”目录中,并发布了一项具有约束力的操作指令,要求联邦机构进行修补。到那时,它已经对我们产生了影响。 该仓库存在的理由只有一个:以便下次发生类似情况时,我们有一个起点,而不是从头开始。它汇集了: - 理论:WebGPU 和 Dawn 是什么,Use-After-Free 在硬件层面意味着什么,以及为什么这个特定的漏洞是危险的。 - 研究:对原始研究人员利用策略和观察结果的文档化摘要。 - 工具:一个版本检测器,一个探测完整 WebGPU 攻击链的漏洞检查器,一个本地扫描器,一个用于批量 CSV 审计的机群扫描器,以及一个用于实验室验证的 UAF 触发器。
## ***🌐 什么是 WebGPU?*** 当您想要了解为什么存在漏洞时,您可以从系统构建的目的以及其设计基于的假设开始。 - **[W3C WebGPU Specification](https://www.w3.org/TR/webgpu/)** WebGPU 是 WebGL(浏览器使用了多年的旧 GPU API)的现代替代品。主要区别在于,WebGPU 从一开始就是为了安全性和显式资源管理而设计的。您需要自己声明每个缓冲区、纹理和管道的生命周期。浏览器充当您的 JavaScript 和 GPU 硬件之间的验证层。 按创建顺序排列,处于此漏洞核心的对象包括: ``` GPUAdapter ← represents a physical GPU or software fallback └─ GPUDevice ← your logical connection to the adapter; owns everything ├─ GPUBuffer ← a chunk of GPU-accessible memory ├─ GPUShaderModule ← a compiled WGSL shader program ├─ GPUComputePipeline ← a shader wired to a pipeline layout ├─ GPUBindGroup ← binds buffers as inputs to a pipeline ├─ GPUCommandEncoder ← records a sequence of GPU commands └─ GPUQueue ← submits recorded commands to hardware ``` 这里的关键规则是:每个对象都归 GPUDevice 所有。当设备仍有正在飞行中引用该对象的命令时,销毁缓冲区在规范下是明确非法的。Dawn 实现应该检测并拒绝这种情况。CVE-2026-5281 就是一个未能做到这一点的案例。
## ***⚙️ 什么是 Dawn?*** - **[Dawn - Open-Source WebGPU Implementation](https://dawn.googlesource.com/dawn)** Dawn 是 Chrome 内部的 C++ 库,用于将 WebGPU JavaScript 调用转换为平台原生的 GPU 命令。在 Windows 上,它面向 D3D12;在 macOS 上,它面向 Metal;在 Linux 上,它面向 Vulkan。它位于 Chrome 的 JavaScript 引擎和硬件驱动程序之间,负责四件事:验证 API 调用、序列化命令、跟踪对象生命周期以及将错误反馈给 JavaScript。 CVE-2026-5281 存在于生命周期跟踪部分。具体来说,即 Dawn 在引用它们的命令仍在硬件队列上等待执行时,将 GPU 缓冲区对象保持存活的时间长短。 ``` JavaScript (V8) │ WebGPU API calls ▼ Dawn (C++) - validates, serializes, tracks lifetimes, reports errors │ ▼ D3D12 (Windows) - Metal (macOS) - Vulkan (Linux) │ ▼ GPU hardware driver │ ▼ Physical GPU - shader cores, VRAM ```
## ***🧠 内存基础(栈、堆、VRAM)*** 在 Use-After-Free 变得直观之前,您需要对事物在内存中的位置有一个清晰的思维模型。 ``` High addresses ┌────────────────────────────────────┐ │ Kernel space │ The OS and drivers live here. │ │ User-mode code cannot touch it. ├────────────────────────────────────┤ │ Stack │ Function call frames. Fast. │ (grows downward) │ Freed automatically when the │ │ function returns. ├────────────────────────────────────┤ │ Heap │ Dynamic allocations - malloc, new, │ (grows upward) │ smart pointers like Ref. │ │ Freed only when you say so. ├────────────────────────────────────┤ │ BSS / Data / Text │ Globals, constants, compiled code. └────────────────────────────────────┘ Low addresses ``` Dawn 的 C++ 对象(例如支持 GPUBuffer 的内部对象)位于堆上。它们是引用计数的:智能指针记录持有该对象引用的事物数量。当该计数达到零时,析构函数运行,内存被返回给分配器。 GPUBuffer 同时具有两种表示形式,一种在 CPU 端,一种在 GPU 端: ``` CPU side (Dawn, system RAM) └─ C++ object - metadata, state flags, and a hardware handle │ │ handle: ID3D12Resource* (D3D12) - MTLBuffer (Metal) - VkBuffer (Vulkan) ▼ GPU side (driver, VRAM) └─ Actual memory allocation on the graphics card ``` 当 JavaScript 调用 buffer.destroy() 时,预期行为是:标记对象为已销毁,减少引用计数,释放硬件句柄,并释放 VRAM。CVE-2026-5281 中的错误导致在 GPU 命令队列仍持有对该硬件句柄的引用时释放了 VRAM,这意味着 GPU 正在主动读取或写入不再属于它的内存。
## ***💀 什么是 Use-After-Free?*** - **[CWE-416: Use After Free (MITRE)](https://cwe.mitre.org/data/definitions/416.html)** Use-After-Free 遵循固定的三步模式,是浏览器安全中最持续被利用的内存安全漏洞类别之一: ``` 1. ALLOCATE - a heap object is created, and a pointer to it is stored somewhere 2. FREE - the object is destroyed and its memory is returned to the allocator 3. USE - the stale pointer is read or written after the memory was freed ← the bug ``` 在第 2 步之后,分配器可以将同一个内存区域交给完全不同的分配。如果攻击者可以控制放入该已释放区域的内容(一种称为堆整理的技术),他们就可以控制过时指针读回的内容。这就是内存安全漏洞变成代码执行的方式。 GPU 端的 UAF 比 CPU 端的 UAF 更难观察到,因为: - “分配器”是 GPU 驱动程序的 VRAM 分配器,而不是系统的 malloc。 - “过时指针”是仍被命令队列引用的硬件句柄。 - GPU 异步执行命令,在崩溃发生很久之前,CPU 就已经继续执行了。
## ***🕳️ 漏洞详情***
### ***📋 从公开来源已知的信息*** 以下内容完全基于已公开确认的信息。 - **[NVD: CVE-2026-5281](https://nvd.nist.gov/vuln/detail/CVE-2026-5281)** - **[The Hacker News: April 1, 2026](https://thehackernews.com/2026/04/new-chrome-zero-day-cve-2026-5281-under.html)** - **[Help Net Security: April 1, 2026](https://www.helpnetsecurity.com/2026/04/01/google-chrome-zero-day-cve-2026-5281/)**
### ***🔗 从 JavaScript 到硬件*** 要了解 Dawn 中的 UAF 可能源自何处,了解 WebGPU 调用如何从一行 JavaScript 完全到达物理硬件会很有帮助: ``` JavaScript ↓ navigator.gpu → adapter → device → buffer / pipeline / encoder ↓ queue.submit([commandBuffer]) ← validation happens here ↓ buffer.destroy() ← if this races GPU execution, UAF Dawn (C++) - validates API calls, serializes commands, tracks lifetimes ↓ translates WebGPU calls to platform-native API calls D3D12 (Windows) ↓ ID3D12CommandQueue::ExecuteCommandLists() ↓ hardware handle for the buffer passed to the driver GPU hardware ↓ shader cores execute the queued commands ↓ if the buffer was freed prematurely → they access freed VRAM ← UAF ``` 根本的张力在于 queue.submit() 和 buffer.destroy() 都是立即返回的 JavaScript API 调用,但 GPU 异步执行已提交的命令,可能在这两个调用返回后很久。Dawn 需要在 GPU 执行的整个持续时间内保持缓冲区对象存活,而不仅仅是直到 JavaScript 调用返回。
### ***⚡ UAF 在 GPU 内存上的行为方式*** 当触发 UAF 时,GPU 会遇到 D3D12 所称的“Device Removed”事件。序列如下: ``` 1. GPU shader accesses freed or reused VRAM 2. GPU memory protection triggers a hardware-level fault 3. D3D12 Timeout Detection and Recovery (TDR) kicks in 4. The driver signals DXGI_ERROR_DEVICE_REMOVED back to Chrome 5. Dawn's device-lost callback fires 6. Chrome surfaces GPUDeviceLostInfo to JavaScript 7. The DeviceLost promise resolves, the GPU context is gone 8. An uncapturederror event fires: "device lost due to internal error" ``` 这也是本仓库中的自动化测试运行器所检测到的内容:它监视那些精确的控制台信号,以确定在给定的 Chrome 版本中是否可以触发该漏洞。
### ***💥 影响与利用条件*** NVD 描述特别指出了一个重要的限制条件:利用要求攻击者已经攻陷了渲染器进程。这意味着 CVE-2026-5281 不是一个从冷启动开始的独立一键式 RCE,而是一个成为攻击链一部分的沙箱逃逸。 在实践中,完整的攻击链可能如下所示: ``` Initial access ← some other vulnerability gets code running in the renderer ↓ CVE-2026-5281 ← UAF in Dawn used to escape the renderer sandbox ↓ Arbitrary code ← execution in a higher-privilege Chrome process or OS context ``` 这正是使浏览器 GPU 漏洞具有高价值的利用模型:一旦您进入渲染器,Dawn 就是自然的下一个目标之一,因为它以产生这些时间窗口的异步复杂性来处理硬件级别的内存。 在披露时确认的影响是任意代码执行,Vulners 数据库还将数据损坏和浏览器崩溃列为观察到的额外影响。
## ***📅 时间线*** CVE-2026-5281 并非孤立出现。它是 2026 年第四个 Chrome 零日漏洞,在这一年第一季度结束前,其零日漏洞总数就已经超过了 2025 年的八个。 | 日期 | 事件 | |---|---| | _2026 年 2 月_ | _修复 CVE-2026-2441,Chrome CSS 组件中的 UAF,已被积极利用_ | | _2026 年 3 月 10 日_ | _修复 CVE-2026-3909 和 CVE-2026-3910,均为已被积极利用的零日漏洞_ | | _2026 年 3 月 23 日_ | _修复 CVE-2026-4675(WebGL 堆缓冲区溢出)和 CVE-2026-4676(Dawn 中的 UAF),报告者与 CVE-2026-5281 相同_ | | _2026 年 4 月 1 日_ | _Google 发布 Chrome 146.0.7680.177/178,修复 21 个漏洞,确认 CVE-2026-5281 在野外被利用_ | | _2026 年 4 月 1 日_ | _CISA 将 CVE-2026-5281 添加到已知已利用漏洞目录_ | | _2026 年 4 月 3 日_ | _Google 确认针对 35 亿 Chrome 用户的积极利用_ | 报告 CVE-2026-5281 的同一位匿名研究人员还在该窗口期前后报告了其他三个漏洞(CVE-2026-4675、CVE-2026-4676、CVE-2026-5284,后两者也是 Dawn 中的 UAF)。这表明一种专门的、正在进行的针对 Dawn 内存管理的研究工作。
## ***🧪 原始研究*** 本仓库中的工具包是基于[原始安全研究](https://github.com/umair-aziz025/CVE-2026-5281-Research-Toolkit)构建的,该研究记录了漏洞在实验室环境中的行为。以下是对该研究的摘要,包括用于触发 UAF 的策略和观察到的结果。
### ***🎯 利用策略*** 研究人员触发 UAF 的方法旨在同时满足使竞争窗口可达的三个条件:足够的 GPU 队列压力以延迟执行、销毁和调度之间足够紧密的时间,以及相同大小的缓冲区重新分配以最大化可观察损坏的机会。 该策略分为五个步骤: **步骤 1 - 卷和压力**:分配 200 个具有随机大小的临时 WebGPU 存储缓冲区(根据 WebGPU 规范,全部为 4 字节的倍数)。这并不是为了填满 VRAM,而是为了创建足够的待处理工作,使 GPU 无法立即执行命令。 **步骤 2 - 计算线程饱和**: 32 个并行计算管道,具有繁重的工作负载,内循环运行 1000 次迭代,调度大小为 4096 个工作组。目标是使 GPU 队列严重积压,以便提交和执行之间的窗口保持足够长的时间以进行竞争。 **步骤 3 - 陷阱**:在提交所有命令缓冲区后,立即对所有 200 个缓冲区调用 destroy()。此时,GPU 已收到命令但尚未执行它们。Dawn 已经通过了其提交时的验证。VRAM 已被释放。 **步骤 4 - 触发器**:分配 32 个新缓冲区,使用与刚刚释放的缓冲区完全相同的大小。如果 VRAM 分配器返回相同的物理地址(由于大小匹配,通常会这样),GPU 的待处理命令现在拥有一个指向属于另一个活动分配的内存的硬件句柄。 **步骤 5 - 提交重用命令**:另一轮使用新分配缓冲区的命令缓冲区提交。此时,队列中有两组命令引用曾经是同一内存的内容,而 GPU 仍在处理第一组命令。 结果是 VRAM 层的经典 UAF:已释放的内存被正在进行的着色器执行主动读取。
### ***📊 观察结果*** 研究人员在易受攻击和已修补的 Chrome 安装上运行了 PoC,并观察到了明显的行为差异: **易受攻击的运行(Chrome < 146.0.7680.178):** ``` [INFO] CVE-2026-5281 AGGRESSIVE PoC Loaded [INFO] Initializing WebGPU context... [INFO] WebGPU device initialized [INFO] Starting aggressive UAF attacks... [ERROR] UNCAUGHT GPU ERROR: device lost due to internal error [CRASH] GPU DEVICE LOST: destroyed [CRASH] [!!!] CRASH DETECTED! Check console for details. ``` 目标 Chrome 进程完全停止渲染。操作系统经历了短暂的视觉冻结,这与显示驱动程序在 GPU 故障后必须重置或停止处理相一致。设备丢失事件被映射为致命的 GPU 错误,而不是标准的 WebGPU API 验证错误,这证实了损坏的内存布局在被 Chrome 的 JavaScript 端沙箱捕获之前到达了硬件层。 **已修补的运行(Chrome >= 146.0.7680.178):** ``` [INFO] CVE-2026-5281 AGGRESSIVE PoC Loaded [INFO] Initializing WebGPU context... [INFO] WebGPU device initialized [INFO] Starting aggressive UAF attacks... [INFO] Max attempts reached without crash [INFO] Either browser is patched or target build not affected ``` 在所有尝试中没有崩溃,没有设备丢失,没有致命的 GPU 信号。修复有效。
## ***🔬 实验室结果*** 以下截图是在配备 Intel 第 12 代低功耗集成 GPU 的 Windows 机器上,针对易受攻击和已修补的 Chrome for Testing 安装进行工具包实验室测试期间拍摄的。每个工具都针对这两个目标运行,以验证行为差异。
### ***🖥️ 工具屏幕截图*** **01 - 版本检测器** | 易受攻击 (< 146.0.7680.178) | 已修补 (>= 146.0.7680.178) | |---|---| | ![01 Vulnerable](https://static.pigsec.cn/wp-content/uploads/repos/2026/04/1a75c9ebc7175850.png) | ![01 Patched](https://static.pigsec.cn/wp-content/uploads/repos/2026/04/ae971e99c0175851.png) | **02 - 漏洞检查器** | 易受攻击 | 已修补 | |---|---| | ![02 Vulnerable](https://static.pigsec.cn/wp-content/uploads/repos/2026/04/f77f2e8746175853.png) | ![02 Patched](https://static.pigsec.cn/wp-content/uploads/repos/2026/04/059883960c175854.png) | **03 - 本地扫描器** | 易受攻击 | 已修补 | |---|---| | ![03 Vulnerable](https://static.pigsec.cn/wp-content/uploads/repos/2026/04/7d2606533f175855.png) | ![03 Patched](https://static.pigsec.cn/wp-content/uploads/repos/2026/04/23b706a070175856.png) | **04 - 机群扫描器** | 易受攻击 | 已修补 | |---|---| | ![04 Vulnerable](https://static.pigsec.cn/wp-content/uploads/repos/2026/04/0ab56c01eb175857.png) | ![04 Patched](https://static.pigsec.cn/wp-content/uploads/repos/2026/04/caf069022a175858.png) | **05 - UAF 触发器** | Chrome | Firefox | |---|---| | ![05 Chrome](https://static.pigsec.cn/wp-content/uploads/repos/2026/04/c892613eb1175900.png) | ![05 Firefox](https://static.pigsec.cn/wp-content/uploads/repos/2026/04/d3083cc33d175901.png) | 包含 Firefox 供比较。Firefox 使用自己的 WebGPU 实现,不受此漏洞影响。无论版本如何,它都能完成所有尝试而没有任何崩溃信号,这是预期的行为。 **06 - UAF 触发器 + 自动化运行器** | GPU 设备丢失 | |:---:| | ![06 Exception](https://static.pigsec.cn/wp-content/uploads/repos/2026/04/f5030d0e12175906.png) | 获得可见的崩溃信号并不总是那么容易。根据硬件和环境的差异,触发器可能需要一些调整才能产生可观察的结果。在我们的案例中,行为是可复现的,但如果不调整工作负载,就无法一致地暴露出来。
### ***💥 拒绝服务*** 我们在受控的实验室环境中成功重现了针对易受攻击的 Chrome 安装的拒绝服务攻击。UAF 触发器导致 GPU 饱和度达到 100%,因为严重积压的命令队列阻止驱动程序处理新的内存管理请求。在某些运行中,GPU 进程进入不可恢复的错误状态,产生以下可观察的影响: - 短暂的操作系统级别视觉冻结,与显示驱动程序 TDR(超时检测和恢复)重置一致 - DXGI_ERROR_DEVICE_HUNG (0x887A0006) 从 D3D12 通过 Dawn 向上传播到渲染器 - Chrome 的 device.lost promise 解析,原因为 "unknown",并且 Dawn 后端跟踪中出现 DXGI_ERROR_DEVICE_HUNG 消息 - 该选项卡的 WebGPU 上下文完全丢失 GPU 饱和和偶尔的异常确认内存损坏已到达硬件层:已释放的缓冲区句柄被正在进行的着色器执行访问,GPU 发生故障,D3D12 的 TDR 机制将其作为设备移除事件呈现。修补后的版本干净地完成了相同的工作负载,没有任何类型的崩溃信号。
### ***🔍 研究状态*** DoS 重现证实了该漏洞。正在进行的工作集中在补丁的二进制级别分析上,具体是比较 Dawn 的命令缓冲区提交路径在最后一个易受攻击的版本和 146.0.7680.178 之间的差异,以确切了解引用计数修复是在何处以及如何应用的。 关于自动化运行器:原始研究人员与他们的 PoC 一起发布了一个运行器脚本。我们的版本需要修改才能在本地实验室环境中可靠地工作,特别是切换到 Chrome 新的无头模式并添加一个选项,允许 GPU 崩溃信号从 GPU 进程传播到渲染器。如果没有这两个标志,Chrome 会静默吸收 GPU 进程崩溃,并且无法从 JavaScript 观察到易受攻击版本和修补版本之间的行为差异。 虽然逆向工程和二进制差异比较工作仍在进行中,但自动化运行器未在本仓库中发布。它将在补丁分析完成后包含在后续更新中。
## ***📚 参考资料*** - **[NVD: CVE-2026-5281](https://nvd.nist.gov/vuln/detail/CVE-2026-5281)** - **[MITRE CWE-416: Use After Free](https://cwe.mitre.org/data/definitions/416.html)** - **[CISA: Known Exploited Vulnerabilities (CVE-2026-5281)](https://www.cisa.gov/news-events/alerts/2026/04/01/cisa-adds-one-known-exploited-vulnerability-catalog)** - **[The Hacker News: New Chrome Zero-Day CVE-2026-5281 Under Active Exploitation](https://thehackernews.com/2026/04/new-chrome-zero-day-cve-2026-5281-under.html)** - **[Forbes: Google Issues Zero-Day Attack Alert For 3.5 Billion Chrome Users](https://www.forbes.com/sites/daveywinder/2026/04/03/google-issues-zero-day-attack-alert-for-35-billion-chrome-users/)** - **[Help Net Security: Google Chrome Zero-Day CVE-2026-5281](https://www.helpnetsecurity.com/2026/04/01/google-chrome-zero-day-cve-2026-5281/)** - **[Dawn Source Repository](https://dawn.googlesource.com/dawn)** - **[WebGPU Specification](https://www.w3.org/TR/webgpu/)** - **[WGSL Specification](https://www.w3.org/TR/WGSL/)**
## ***📬 联系方式***

仅用于您拥有或明确授权测试的系统。

标签:0day, Chrome, CISA项目, CMS安全, CVE, CVE-2026-5281, CWE-416, Dawn, Exploit, Google Chrome, Go语言工具, GPU, JavaScript, meg, POC, RCE, UAF, Use-After-Free, WebGPU, Web报告查看器, 信息安全, 内存安全, 图形渲染, 在野利用, 堆溢出, 实验室工具, 数字签名, 数据可视化, 漏洞分析, 漏洞复现, 编程工具, 补丁比对, 路径探测, 远程代码执行, 释放后重用, 验证环境