Four Chrome Zero-Days In Three Months: WebGPU Is the New Attack Surface
Here’s a fun April 1st gift from Google: a Chrome zero-day that’s been exploited in the wild. CVE-2026-5281 — a use-after-free in Dawn, Chrome’s WebGPU implementation layer — dropped alongside 20 other fixes, patched in v146.0.7680.177/178 for Windows and Mac, and .177 for Linux.
Patch your browser. We’ll wait.
Okay. Now let’s talk about why this particular class of bug keeps showing up, and why Dawn is going to be a recurring theme for the next few years.
What’s Dawn and Why Should You Care
Dawn is the library that sits between WebGPU API calls and actual GPU hardware. Your browser tab wants to run a compute shader? Dawn translates that into Vulkan on Linux, Metal on macOS, or Direct3D on Windows. It manages memory shared between the CPU and GPU: allocations, deallocations, synchronization. The stuff that, when it goes wrong, goes spectacularly wrong.
WebGPU itself is still relatively new — it shipped in Chrome stable in 2023, and it’s been slowly colonizing the web ever since. Games. ML inference in the browser. Data visualization. Every new use case is another code path through Dawn. Every new code path is another opportunity for memory lifecycle bugs.
Use-after-free in 2026: still the gift that keeps on giving.
The Bug
CVE-2026-5281 follows the classic UAF playbook: code accesses memory through a pointer after the underlying allocation has been freed. If an attacker can cause a controlled allocation to land in that freed slot before the stale pointer is dereferenced, they can redirect execution. In GPU-adjacent code where memory is shared across device boundaries, the timing is delightful for attackers and miserable for defenders.
Critically, the NVD description says it requires “a remote attacker who has already compromised the renderer process.” That’s the tell. This isn’t a standalone drive-by. It’s a chain link — something else breaks into the renderer, then this finishes the job by escaping Chrome’s sandbox entirely.
Google has locked down the bug tracker, which is standard practice for actively exploited flaws. Technical details won’t surface until most users have updated. That’s the correct call; it’s also the reason security disclosures are always a tradeoff between transparency and “we’d rather attackers not read the patch diff before everyone updates.”
Fourth Zero-Day This Year. Fourth.
That’s not a typo. CVE-2026-5281 is Chrome zero-day number four for 2026, following a CSS engine bug, a Skia graphics bug, and a V8 bug. The browser is a large and complicated attack surface. This is not news. But the pattern here is interesting: three of the four bugs (including CVE-2026-5281) were reported by the same pseudonymous researcher — hash identifier 86ac1f1587b71893ed2ad792cd7dde32.
This person also reported CVE-2026-4675 (heap buffer overflow in WebGL) and CVE-2026-4676 (another Dawn UAF), both patched in the March 23rd update. Then CVE-2026-5284, a third Dawn UAF, fixed in the same batch as 5281.
One researcher. Three Dawn UAFs and a WebGL overflow. In six weeks.
Either someone went very deep on Dawn’s source code, or Dawn is the kind of codebase that rewards sustained attention with a steady stream of findings. Given that Dawn is written in C++ and manages GPU memory with all the memory safety guarantees that implies (which is: none), I’d bet on the latter.
The WebGPU Footprint Problem
Here’s the thing about WebGPU: it’s powerful on purpose. The whole pitch is GPU-level access from inside a browser tab. That means closer-to-metal than almost anything else in the browser engine. It means complex state machines, resource lifetimes tied to async GPU operations, and synchronization primitives that are subtle to get right.
The browser vendors collectively agreed to expose this surface because the web needed it. Figma, web-based games, ML inference, scientific visualization — the demand was real. But “close to the GPU” and “runs in a sandboxed browser process” are architectural tensions that C++ resolves with a lot of trust that developers will get the lifetime semantics right.
They don’t always get the lifetime semantics right.
Rust would help here. Dawn is not written in Rust. Chrome has been incrementally adopting Rust for memory-safety-critical components — there’s a safe allocator, some parsing code — but the core GPU abstraction layer is still C++. For now.
What To Actually Do
-
Update Chrome. Stable is at 146.0.7680.177+. If you’re on a Chromium-based browser (Edge, Vivaldi, Brave), check for updates — Vivaldi has already shipped the fix, Edge is working on it.
-
If you manage a fleet: treat this as urgent. “Renderer process already compromised” doesn’t mean you can ignore it — it means this bug is in exploit chains, which means it’s being used against real targets.
-
Watch the Dawn source history when Google eventually unlocks the bug tracker. These UAFs cluster in specific subsystems. When the details surface, there’s usually more to find nearby.
The entropy is telling you something. It’s just doing it through a stale GPU memory pointer.
Sources: Help Net Security, Dark Web Informer, The Hacker News