🌐 What is WebGPU?

When you want to understand why a vulnerability exists, you start with what the system was built to do and what assumptions it was designed around.

• W3C WebGPU Specification

  WebGPU exposes an API for performing operations, such as rendering and computation, on a Graphics Processing Unit. WebGPU is not an attempt to expose OpenGL or OpenGL ES (Embedded Systems). It is a new API that is built on the ideas of modern APIs such as Direct3D 12, Metal, and Vulkan.

WebGPU is the modern replacement for WebGL, the old GPU API that browsers have used for years. The key difference is that WebGPU was designed from the ground up for safety and explicit resource management. You declare the lifecycle of every buffer, texture, and pipeline yourself. The browser acts as a validation layer between your JavaScript and the GPU hardware.

The objects at the center of this vulnerability, in order of creation:

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

The rule that matters here: every object is owned by the GPUDevice. Destroying a buffer while the device still has commands in flight that reference it is explicitly illegal under the spec. The Dawn implementation is supposed to detect and reject that. CVE-2026-5281 is a case where it did not.

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

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<T>.
│                                    │  Freed only when you say so.
├────────────────────────────────────┤
│  BSS / Data / Text                 │  Globals, constants, compiled code.
└────────────────────────────────────┘
Low addresses

🕳️ The Vulnerability

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

💥 Impact and Exploitation Requirements

The NVD description is specific about one important constraint: exploitation requires that the attacker has already compromised the renderer process. This means CVE-2026-5281 is not a standalone one-click RCE from a cold start, it is a sandbox escape that becomes part of a chain.

In practice, a full attack chain would look something like:

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

This is exactly the exploitation model that makes browser GPU bugs high value: once you are in the renderer, Dawn is one of the natural next targets because it handles hardware-level memory with the kind of asynchronous complexity that produces these timing windows.

The confirmed impact at the time of disclosure was arbitrary code execution and the Vulners database notes data corruption and browser crashes as additional observed effects.

🎯 Exploit Strategy

The researcher's approach to triggering the UAF was designed to simultaneously satisfy the three conditions that make the race window reachable: enough GPU queue pressure to delay execution, tight enough timing between destroy and dispatch, and same-size buffer reallocation to maximize the chance of observable corruption.

The strategy breaks down into five steps:

Step 1 - Volume and pressure: 200 temporary WebGPU storage buffers allocated with randomized sizes (all multiples of 4 bytes as required by the WebGPU spec). This is not about filling VRAM, it is about creating enough pending work that the GPU cannot execute the commands immediately.

Step 2 - Compute thread saturation: 32 parallel compute pipelines queued with heavy workloads, inner loops running 1000 iterations and dispatch sizes of 4096 workgroups. The goal is to keep the GPU queue deeply backlogged so that the window between submit and execution stays open long enough to race.

Step 3 - The trap: Immediately after submitting all command buffers, destroy() is called on all 200 buffers. At this point the GPU has received the commands but has not yet executed them. Dawn has already passed its submit-time validation. The VRAM is freed.

Step 4 - The trigger: 32 new buffer allocations using the exact same sizes as the just-freed buffers. If the VRAM allocator returns the same physical addresses, which it often will since the sizes match, the GPU's pending commands now have a hardware handle pointing to memory that belongs to a different, live allocation.

Step 5 - Reuse commands submitted: Another round of command buffer submissions using the newly allocated buffers. At this point there are two sets of commands in the queue referencing what was once the same memory, with the GPU still working through the first set.

The result is a classic UAF at the VRAM layer: freed memory actively read by in-flight shader execution.

[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.

[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

💥 Denial of Service

We successfully reproduced a Denial of Service against a vulnerable Chrome installation in a controlled lab environment. The UAF trigger causes the GPU to saturate to 100% utilization as the heavily backlogged command queue prevents the driver from servicing new memory management requests. During some runs, the GPU process entered an unrecoverable fault state, producing the following observable effects:

• A brief OS-level visual freeze consistent with a Display Driver TDR (Timeout Detection and Recovery) reset
• DXGI_ERROR_DEVICE_HUNG (0x887A0006) propagated up from D3D12 through Dawn to the renderer
• Chrome's device.lost promise resolving with reason "unknown" and a DXGI_ERROR_DEVICE_HUNG message in the Dawn backend trace
• Complete loss of the WebGPU context for that tab

The GPU saturation and occasional exception confirm that the memory corruption is reaching the hardware layer: the freed buffer handle is accessed by in-flight shader execution, the GPU faults, and D3D12's TDR mechanism surfaces it as a device removal event. The patched version completed the same workload cleanly with no crash signal of any kind.

📬 Contact

Use only on systems you own or are explicitly authorized to test.