Use-after-free in Dawn in Google Chrome

This repository is a small proof-of-concept for CVE-2026-5281 targeting Chromium's WebGPU implementation, specifically the Dawn wire client/server object lifetime and callback handling. The repo contains 5 files: a patch file (ApiProcs.cpp.patch), a browser PoC (poc.html), an ASAN crash log (asan.log), and two documentation files (README.md and writeup.md). The exploit capability is limited to vulnerability triggering and crash reproduction. The HTML PoC uses WebGPU from JavaScript: it requests an adapter and device, installs device.onuncapturederror, creates a buffer, then calls device.queue.writeBuffer with a crafted offset value of 0x414141. The supplied patch modifies the Dawn wire client template so that when QueueWriteBuffer sees this sentinel offset, it forcibly unregisters the device object on the client and rewrites the offset to UINT64_MAX before continuing. This creates an invalid object lifetime/state transition that leads to a server-side callback referencing freed memory. A subsequent queue.submit flushes commands and helps deliver the error/callback path, producing the demonstrated heap-use-after-free. The ASAN logs and writeup indicate the bug manifests in the Dawn wire server / GPU process path, with the crash occurring in Server::DoAdapterRequestDevice callback handling after device-related object data has been freed. The writeup explains the root cause: older cleanup logic only cleared logging callbacks, while uncaptured error and device lost callbacks could still fire after ObjectData deallocation, causing UAF. The referenced upstream fix replaces callback clearing with explicit device destruction (deviceDestroy) to ensure callbacks are flushed safely before object teardown. There are no hardcoded remote C2, IPs, or exploit delivery servers. The only actionable/fingerprintable artifacts are local file paths, upstream review URLs, and the browser-exposed WebGPU API calls. Overall, this is a browser/web attack vector PoC for local reproduction of a Chromium WebGPU memory safety issue, not a weaponized exploit and not a detection-only script.

Repository is a standalone Python-and-HTML proof-of-concept toolkit for CVE-2026-5281, a Chrome Dawn/WebGPU use-after-free. It is not tied to a common exploit framework. The structure is simple: a top-level README with vulnerability background and lab notes, a '01 Vulnerable Binaries' folder documenting official Chrome-for-Testing builds for vulnerable and patched versions, and a '02 PoC' folder containing five Python generators/servers plus prebuilt HTML artifacts. Each Python script writes a self-contained HTML/JavaScript page into the Artifacts directory and serves it via Python's built-in HTTP server on port 8080 bound to 0.0.0.0. The browser-side logic is where the actual capability resides: - 01 Version Detector reads the full Chrome version via navigator.userAgentData.getHighEntropyValues() and compares it to the patched threshold 146.0.7680.178. - 02 Vulnerability Checker probes the full WebGPU attack chain: navigator.gpu availability, adapter/device acquisition, storage buffer allocation, shader compilation, compute pipeline creation, command encoding, queue submission, and buffer destruction after submit. - 03 Local Scanner combines versioning, chain probing, system/GPU context collection, risk scoring, and remediation guidance for a single machine. - 04 Fleet Scanner is a client-side CSV auditor for bulk version triage; it does not exploit targets directly, but helps identify potentially vulnerable hosts from supplied inventory data. - 05 UAF Trigger is the closest thing to an exploit: it repeatedly creates GPU resources and compute workloads, submits them, then destroys buffers after queue.submit() to try to hit the vulnerable race window. It tracks attempts, errors, and possible GPU stall/TDR indicators, and treats crash-like behavior as confirmation. Overall, this repository mixes detection and active triggering. Most files are assessment tools, but the UAF trigger is an operational browser-based PoC for denial-of-service/lab validation rather than full code execution. No reverse shell or post-exploitation payload is present. The exploit path is browser/web-based and depends on a user opening the served page in a vulnerable Chrome build with hardware WebGPU support.

Repository contains a standalone Python-based exploit kit for alleged CVE-2026-5281 in Chrome/Dawn WebGPU, plus automation and scanning utilities. The main file, cve_2026_5281_exploit.py, is the core artifact: it embeds an HTML/JavaScript WebGPU payload intended to trigger a use-after-free by stressing GPU buffer lifecycle handling, generates payload/support files, and can host them via a local Python HTTP server. The exploit flow is browser-delivered: operator serves exploit.html locally, opens it in a Chromium-based browser, and the JavaScript attempts repeated WebGPU buffer allocation/submission/destruction patterns to induce GPU device loss or crash. The demonstrated capability is primarily denial of service / crash triggering rather than reliable code execution. Supporting files broaden the repository beyond a pure exploit: cve_2026_5281_automated_test.py uses Pyppeteer to launch a Chromium-based browser headlessly with unsafe WebGPU and reduced sandboxing flags, navigate to the exploit URL, and classify console output for fatal crash markers. cve_2026_5281_scanner.py is a defensive/audit utility that checks Windows registry keys and common Chrome binary paths for vulnerable versions, supports CSV fleet audits, and triages logs for exploit signatures. The markdown report documents the claimed vulnerability, affected versions, test setup, and observed crash behavior. Two sample logs illustrate vulnerable versus patched outcomes. Overall, this is a mixed exploit-and-validation repository: operational enough to generate and serve a browser payload and observe crash behavior, but not part of a known exploit framework and not obviously weaponized with a customizable post-exploitation payload. The most fingerprintable runtime targets are localhost HTTP serving on port 8080, Windows Chrome registry keys, common Chrome executable paths, and the default Edge executable path used for automation.