themalwareguardian/cve-2026-5281CVE-2026-5281 (Chrome Dawn WebGPU UAF) analysis, lab validation tools, and reproducible environment for vulnerable vs patched builds.
This vulnerability affected one of the clients we provide services to. This repository is our contribution to the original research: a centralized starting point for the group, so that if a similar vulnerability affecting this component appears again, we already have the groundwork in place. It brings together the theory behind the bug, a documented summary of the original researcher's findings, and a set of practical tools to verify exposure in a lab setting.
Note: I would have liked to share more of this research, but due to company restrictions I cannot disclose it further. Everything included here has been reviewed and does not violate any agreements I am subject to. The repository is therefore archived in its current state.
On April 1, 2026, Google released a Chrome security update addressing 21 vulnerabilities, one of which, CVE-2026-5281, was already being actively exploited in the wild at the time of disclosure. Three days later, CISA added it to the Known Exploited Vulnerabilities catalog and issued a binding operational directive requiring federal agencies to patch. By that point it had already affected us.
This repository exists for one reason: so that the next time something like this happens, we have a starting point instead of starting from scratch. It brings together:
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.
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.
Dawn - Open-Source WebGPU Implementation
Dawn is an open-source and cross-platform implementation of the work-in-progress WebGPU standard. It exposes a native C++ API that mirrors the WebGPU IDL with some extensions.
Dawn is the C++ library inside Chrome that translates WebGPU JavaScript calls into platform-native GPU commands. On Windows it targets D3D12, on macOS it targets Metal, and on Linux it targets Vulkan. It sits between Chrome's JavaScript engine and the hardware driver, and it is responsible for four things: validating API calls, serializing commands, tracking object lifetimes, and surfacing errors back to JavaScript.
CVE-2026-5281 lives in the lifetime tracking part. Specifically, in how long Dawn keeps GPU buffer objects alive while commands that reference them are still pending execution on the hardware queue.
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
You need a clear mental model of where things live in memory before a Use-After-Free makes intuitive sense.