📌 Kontext und Zweck

Am 1. April 2026 veröffentlichte Google ein Chrome-Sicherheitsupdate, das 21 Schwachstellen behob, von denen eine, CVE-2026-5281, zum Zeitpunkt der Offenlegung bereits aktiv im Internet ausgenutzt wurde. Drei Tage später fügte CISA sie dem Katalog bekannter ausgenutzter Schwachstellen hinzu und erließ eine verbindliche operative Anweisung, die Bundesbehörden zum Patchen verpflichtete. Zu diesem Zeitpunkt hatte sie uns bereits getroffen.

Dieses Repository existiert aus einem Grund: damit wir beim nächsten Mal, wenn so etwas passiert, einen Ausgangspunkt haben, anstatt bei Null anfangen zu müssen. Es vereint:

• Die Theorie: Was WebGPU und Dawn sind, was ein Use-After-Free auf Hardwareebene bedeutet und warum dieser spezielle Fehler gefährlich ist.
• Die Forschung: eine dokumentierte Zusammenfassung der Ausnutzungsstrategie und der beobachteten Ergebnisse des ursprünglichen Forschers.
• Die Werkzeuge: einen Versionsdetektor, einen Schwachstellenprüfer, der die gesamte WebGPU-Angriffskette testet, einen lokalen Scanner, einen Flottenscanner für die CSV-Stapelprüfung und einen UAF-Trigger für die Laborverifikation.

Die Regel, die hier zählt: Jedes Objekt gehört dem GPUDevice. Das Zerstören eines Puffers, während das Gerät noch Befehle ausführt, die darauf verweisen, ist laut Spezifikation ausdrücklich illegal. Die Dawn-Implementierung soll dies erkennen und ablehnen. CVE-2026-5281 ist ein Fall, in dem sie es nicht tat.



---
---
---



<div id='whatisdawn'/>

## ***⚙️ Was ist Dawn?***

- **[Dawn - Open-Source WebGPU Implementation](https://dawn.googlesource.com/dawn)**

	> Dawn ist eine quelloffene und plattformübergreifende Implementierung des in Arbeit befindlichen WebGPU-Standards. Sie stellt eine native C++-API bereit, die das WebGPU-IDL mit einigen Erweiterungen abbildet.

Dawn ist die C++-Bibliothek in Chrome, die WebGPU-JavaScript-Aufrufe in plattformnative GPU-Befehle übersetzt. Unter Windows zielt sie auf D3D12, unter macOS auf Metal und unter Linux auf Vulkan. Sie sitzt zwischen der JavaScript-Engine von Chrome und dem Hardwaretreiber und ist für vier Dinge zuständig: Validieren von API-Aufrufen, Serialisieren von Befehlen, Verfolgen von Objektlebensdauern und Melden von Fehlern zurück an JavaScript.

CVE-2026-5281 befindet sich im Teil der Lebensdauerverfolgung. Genauer gesagt darin, wie lange Dawn GPU-Pufferobjekte am Leben hält, während Befehle, die auf sie verweisen, noch auf der Hardware-Warteschlange auf ihre Ausführung warten.```
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

Dawns C++-Objekte, wie das interne Objekt eines GPUBuffers, befinden sich auf dem Heap. Sie sind referenzgezählt: Ein Smart Pointer zählt, wie viele Referenzen auf das Objekt gehalten werden. Wenn dieser Zähler Null erreicht, wird der Destruktor ausgeführt und der Speicher an den Allokator zurückgegeben.

Ein GPUBuffer hat gleichzeitig zwei Darstellungen, eine auf der CPU-Seite und eine auf der GPU-Seite:```
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

💀 Was ist ein Use-After-Free?

• CWE-416: Use After Free (MITRE)

  Der Zugriff auf Speicher, nachdem er freigegeben wurde, kann dazu führen, dass ein Programm abstürzt, unerwartete Werte verwendet oder Code ausführt. Die Nutzung von zuvor freigegebenem Speicher kann eine Vielzahl negativer Konsequenzen haben, von der Korruption gültiger Daten bis hin zur Ausführung beliebigen Codes.

Ein Use-After-Free folgt einem festen Drei-Schritte-Muster und ist eine der regelmäßig ausgenutzten Speichersicherheitsfehlerklassen in der Browsersicherheit:```

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

Nach Schritt 2 kann der Allokator dieselbe Speicherregion einer völlig anderen Allokation zuweisen. Wenn ein Angreifer kontrollieren kann, was in diese freigegebene Region gelegt wird – eine Technik namens Heap Grooming –, kann er kontrollieren, was der veraltete Zeiger zurückliest. So wird ein Memory-Safety-Fehler zur Codeausführung.

GPU-seitiger UAF ist schwieriger zu beobachten als CPU-seitiger UAF, weil:

- Der "Allokator" ist der VRAM-Allokator des GPU-Treibers, nicht der systemische malloc.
- Der "veraltete Zeiger" ist ein Hardware-Handle, der immer noch von der Befehlswarteschlange referenziert wird.
- Die GPU führt Befehle asynchron aus, die CPU ist schon lange vor dem Auftreten des Absturzes weitergezogen.



---
---
---



<div id='thevulnerability'/>

## ***🕳️ Die Schwachstelle***

---

<div id='thevulnerability-whatweknow'/>

### ***📋 Was wir aus öffentlichen Quellen wissen***

Das Folgende beruht vollständig auf dem, was öffentlich bestätigt wurde.

- **[NVD: CVE-2026-5281](https://nvd.nist.gov/vuln/detail/CVE-2026-5281)**

	> Use-After-Free in Dawn in Google Chrome vor 146.0.7680.178 erlaubte es einem entfernten Angreifer, der den Renderer-Prozess kompromittiert hatte, beliebigen Code über eine präparierte HTML-Seite auszuführen.

- **[The Hacker News: 1. April 2026](https://thehackernews.com/2026/04/new-chrome-zero-day-cve-2026-5281-under.html)**

	> Google ist bekannt, dass ein Exploit für CVE-2026-5281 im Umlauf ist.

- **[Help Net Security: 1. April 2026](https://www.helpnetsecurity.com/2026/04/01/google-chrome-zero-day-cve-2026-5281/)**

	> CVE-2026-5281 wurde von einem pseudonymen Bug-Hunter (86ac1f1587b71893ed2ad792cd7dde32) gemeldet, der zuvor zwei Schwachstellen gemeldet hatte, die im Chrome-Update vom 23. März 2026 behoben wurden: einen Heap-Buffer-Overflow in WebGL (CVE-2026-4675) und einen weiteren Use-After-Free-Fehler in Dawn (CVE-2026-4676). Der Bug-Hunter meldete außerdem einen dritten Use-After-Free in Dawn (CVE-2026-5284), der dieses Mal behoben wurde.

---

<div id='thevulnerability-executionlayers'/>

### ***🔗 Von JavaScript zur Hardware***

Um zu verstehen, wo ein UAF in Dawn entstehen kann, hilft es, genau zu sehen, wie ein WebGPU-Aufruf von einer JavaScript-Zeile bis zur physischen Hardware reist:```
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

Die grundlegende Spannung besteht darin, dass queue.submit() und buffer.destroy() beide JavaScript-API-Aufrufe sind, die sofort zurückkehren, aber die GPU die übermittelten Befehle asynchron ausführt, möglicherweise lange nachdem beide Aufrufe zurückgekehrt sind. Dawn muss Pufferobjekte während der gesamten Dauer der GPU-Ausführung lebendig halten, nicht nur bis zum Zeitpunkt der Rückkehr des JavaScript-Aufrufs.

Das erkennt auch der automatisierte Testrunner in diesem Repository: Er überwacht genau diese Konsolensignale, um festzustellen, ob die Schwachstelle in einer bestimmten Chrome-Version auslösbar ist.

---

<div id='thevulnerability-impact'/>

### ***💥 Auswirkungen und Anforderungen an die Ausnutzung***

Die NVD-Beschreibung ist präzise hinsichtlich einer wichtigen Einschränkung: Die Ausnutzung erfordert, dass der Angreifer den Renderer-Prozess bereits kompromittiert hat. Das bedeutet, CVE-2026-5281 ist keine eigenständige RCE mit einem Klick aus dem kalten Start, sondern eine Sandbox-Escape, die Teil einer Kette wird.

In der Praxis würde eine vollständige Angriffskette etwa so aussehen:```
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

📅 Zeitleiste

CVE-2026-5281 trat nicht isoliert auf. Es war der vierte Chrome Zero-Day des Jahres 2026, ein Jahr, das bereits vor Ende des ersten Quartals auf dem besten Weg war, die Gesamtzahl von acht Zero-Days im Jahr 2025 zu übertreffen.

Derselbe pseudonyme Forscher, der CVE-2026-5281 meldete, meldete auch drei weitere Schwachstellen im nahen Zeitfenster (CVE-2026-4675, CVE-2026-4676, CVE-2026-5284, die letzten beiden ebenfalls UAFs in Dawn). Dies deutet auf einen fokussierten, laufenden Forschungsaufwand hin, der speziell auf das Speichermanagement von Dawn abzielt.

📊 Beobachtete Ergebnisse

Der Forscher führte den PoC sowohl auf einer verwundbaren als auch auf einer gepatchten Chrome-Installation aus und beobachtete eine klare verhaltensbezogene Trennung:

Verwundbarer Lauf (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.

Der gezielte Chrome-Prozess stellte die Darstellung vollständig ein. Das Betriebssystem erlebte kurzzeitiges visuelles Einfrieren, was darauf hindeutet, dass der Grafiktreiber nach dem GPU-Fehler zurückgesetzt werden musste oder die Verarbeitung anhielt. Das device lost-Ereignis wurde einem fatalen GPU-Fehler zugeordnet, nicht einem standardmäßigen WebGPU-API-Validierungsfehler. Dies bestätigt, dass das beschädigte Speicherlayout die Hardware-Ebene erreichte, ohne von der JavaScript-seitigen Sandboxing von Chrome abgefangen zu werden.

**Gepatchter Durchlauf (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

Kein Absturz, kein Geräteverlust, keine fatalen GPU-Signale bei allen Versuchen. Der Fix hält.

💥 Denial-of-Service

Wir haben in einer kontrollierten Laborumgebung erfolgreich einen Denial-of-Service gegen eine verwundbare Chrome-Installation reproduziert. Der UAF-Trigger führt dazu, dass die GPU zu 100 % ausgelastet wird, da die stark zurückgestaute Befehlswarteschlange den Treiber daran hindert, neue Speicherverwaltungsanfragen zu bedienen. Bei einigen Durchläufen geriet der GPU-Prozess in einen nicht behebbaren Fehlerzustand, der folgende beobachtbare Effekte verursachte:

• Ein kurzzeitiges visuelles Einfrieren auf Betriebssystemebene, das einem TDR-Reset (Timeout Detection and Recovery) des Anzeigetreibers entspricht
• DXGI_ERROR_DEVICE_HUNG (0x887A0006) wurde von D3D12 über Dawn an den Renderer weitergegeben
• Das device.lost-Promise von Chrome wurde mit dem Grund "unknown" aufgelöst und eine DXGI_ERROR_DEVICE_HUNG-Meldung im Dawn-Backend-Trace angezeigt
• Vollständiger Verlust des WebGPU-Kontexts für diesen Tab

Die GPU-Sättigung und die gelegentliche Ausnahme bestätigen, dass der Speicherfehler die Hardwareebene erreicht: Das freigegebene Pufferhandle wird von der laufenden Shader-Ausführung angesprochen, die GPU stürzt ab, und D3D12s TDR-Mechanismus gibt dies als Geräteentfernungsereignis aus. Die gepatchte Version hat die gleiche Arbeitslast sauber und ohne jegliches Absturzsignal abgeschlossen.