themalwareguardian/cve-2026-5281Analisi di CVE-2026-5281 (Chrome Dawn WebGPU UAF), strumenti di validazione di laboratorio e ambiente riproducibile per build vulnerabili vs patchate.
Questa vulnerabilità ha colpito uno dei clienti a cui forniamo servizi. Questo repository è il nostro contributo alla ricerca originale: un punto di partenza centralizzato per il gruppo, così che se una vulnerabilità simile che colpisce questo componente dovesse ricomparire, abbiamo già le fondamenta pronte. Riunisce la teoria alla base del bug, un riepilogo documentato delle scoperte del ricercatore originale e una serie di strumenti pratici per verificare l'esposizione in un ambiente di laboratorio.
Nota: avrei voluto condividere più di questa ricerca, ma a causa delle restrizioni aziendali non posso divulgarne altro. Tutto ciò che è incluso qui è stato revisionato e non viola alcun accordo a cui sono soggetto. Il repository è quindi archiviato nel suo stato attuale.
Il 1° aprile 2026, Google ha rilasciato un aggiornamento di sicurezza di Chrome che affrontava 21 vulnerabilità, una delle quali, CVE-2026-5281, era già stata attivamente sfruttata in natura (in the wild) al momento della divulgazione. Tre giorni dopo, CISA l'ha aggiunta al catalogo Known Exploited Vulnerabilities e ha emanato una direttiva operativa vincolante che richiedeva alle agenzie federali di applicare la patch. A quel punto ci aveva già colpito.
Questo repository esiste per un solo motivo: che la prossima volta che qualcosa del genere accada, abbiamo un punto di partenza invece di ricominciare da zero. Riunisce:
Quando vuoi capire perché esiste una vulnerabilità, inizi da ciò che il sistema è stato costruito per fare e dalle assunzioni attorno alle quali è stato progettato.
WebGPU espone un'API per eseguire operazioni, come rendering e calcolo, su una unità di elaborazione grafica. WebGPU non è un tentativo di esporre OpenGL o OpenGL ES (Embedded Systems). È una nuova API costruita sulle idee di API moderne come Direct3D 12, Metal e Vulkan.
WebGPU è il sostituto moderno di WebGL, la vecchia API GPU che i browser hanno usato per anni. La differenza fondamentale è che WebGPU è stata progettata da zero per la sicurezza e la gestione esplicita delle risorse. Dichiari tu stesso il ciclo di vita di ogni buffer, texture e pipeline. Il browser agisce come livello di validazione tra il tuo JavaScript e l'hardware GPU.
Gli oggetti al centro di questa vulnerabilità, in ordine di creazione:``` 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
La regola che conta qui: ogni oggetto è di proprietà di GPUDevice. Distruggere un buffer mentre il dispositivo ha ancora comandi in sospeso che vi fanno riferimento è esplicitamente illegale secondo la specifica. L'implementazione di Dawn dovrebbe rilevarlo e rifiutarlo. CVE-2026-5281 è un caso in cui non lo ha fatto.
---
---
---
<div id='whatisdawn'/>
## ***⚙️ Cos'è Dawn?***
- **[Dawn - Implementazione open-source di WebGPU](https://dawn.googlesource.com/dawn)**
> Dawn è un'implementazione open-source e multipiattaforma dello standard WebGPU in fase di definizione. Espone un'API C++ nativa che rispecchia l'IDL di WebGPU con alcune estensioni.
Dawn è la libreria C++ all'interno di Chrome che traduce le chiamate JavaScript WebGPU in comandi GPU nativi della piattaforma. Su Windows usa D3D12, su macOS usa Metal e su Linux usa Vulkan. Si trova tra il motore JavaScript di Chrome e il driver hardware ed è responsabile di quattro cose: validare le chiamate API, serializzare i comandi, tenere traccia dei cicli di vita degli oggetti e riportare gli errori a JavaScript.
CVE-2026-5281 risiede nella parte di tracciamento dei cicli di vita. Nello specifico, per quanto tempo Dawn mantiene in vita gli oggetti buffer GPU mentre i comandi che vi fanno riferimento sono ancora in attesa di esecuzione sulla coda hardware.```
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
Hai bisogno di un modello mentale chiaro di dove vivono le cose in memoria prima che un Use-After-Free abbia senso intuitivo.``` 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. │ │ Freed only when you say so. ├────────────────────────────────────┤ │ BSS / Data / Text │ Globals, constants, compiled code. └────────────────────────────────────┘ Low addresses
Gli oggetti C++ di Dawn, come l'oggetto interno che supporta un GPUBuffer, vivono sullo heap. Hanno un conteggio dei riferimenti: uno smart pointer tiene traccia di quante cose contengono un riferimento all'oggetto. Quando quel conteggio arriva a zero, il distruttore viene eseguito e la memoria viene restituita all'allocatore.
Un GPUBuffer ha due rappresentazioni contemporaneamente, una sul lato CPU e una sul lato GPU:```
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
Quando JavaScript chiama buffer.destroy(), il comportamento previsto è: contrassegnare l'oggetto come distrutto, decrementare il contatore dei riferimenti, rilasciare l'handle hardware e liberare la VRAM. Il bug in CVE-2026-5281 fa sì che la VRAM venga liberata mentre la coda dei comandi della GPU mantiene ancora un riferimento a quell'handle hardware, il che significa che la GPU sta leggendo o scrivendo attivamente in memoria che non le appartiene più.
CWE-416: Use After Free (MITRE)
Fare riferimento a memoria dopo che è stata liberata può causare il crash del programma, l'uso di valori imprevisti o l'esecuzione di codice. L'uso di memoria precedentemente liberata può avere innumerevoli conseguenze negative, che vanno dalla corruzione di dati validi all'esecuzione di codice arbitrario.
Un Use-After-Free segue uno schema fisso in tre fasi ed è una delle classi di bug di sicurezza della memoria più costantemente sfruttate nella sicurezza dei browser:```
Dopo il passaggio 2, l'allocatore può assegnare quella stessa regione di memoria a un'allocazione completamente diversa. Se un attaccante può controllare cosa viene inserito in quella regione liberata, una tecnica chiamata heap grooming, può controllare ciò che il puntatore stantio legge di ritorno. È così che un bug di memory safety diventa esecuzione di codice.
L'UAF lato GPU è più difficile da osservare rispetto all'UAF lato CPU, perché:
- L'"allocatore" è l'allocatore VRAM del driver GPU, non la malloc di sistema.
- Il "puntatore stantio" è un handle hardware ancora referenziato dalla coda dei comandi.
- La GPU esegue i comandi in modo asincrono; la CPU è già andata avanti molto prima che si verifichi il crash.
---
---
---
<div id='thevulnerability'/>
## ***🕳️ La Vulnerabilità***
---
<div id='thevulnerability-whatweknow'/>
### ***📋 Cosa Sappiamo dalle Fonti Pubbliche***
Quanto segue si basa interamente su ciò che è stato confermato pubblicamente.
- **[NVD: CVE-2026-5281](https://nvd.nist.gov/vuln/detail/CVE-2026-5281)**
> Un use-after-free in Dawn in Google Chrome precedente alla 146.0.7680.178 consentiva a un attaccante remoto che aveva compromesso il processo di rendering di eseguire codice arbitrario tramite una pagina HTML appositamente predisposta.
- **[The Hacker News: 1 aprile 2026](https://thehackernews.com/2026/04/new-chrome-zero-day-cve-2026-5281-under.html)**
> Google è a conoscenza del fatto che esiste un exploit per CVE-2026-5281 in circolazione.
- **[Help Net Security: 1 aprile 2026](https://www.helpnetsecurity.com/2026/04/01/google-chrome-zero-day-cve-2026-5281/)**
> CVE-2026-5281 è stato segnalato da un cacciatore di bug pseudonimo (86ac1f1587b71893ed2ad792cd7dde32), che in precedenza aveva segnalato due vulnerabilità corrette nell'aggiornamento di Chrome rilasciato il 23 marzo 2026: un heap buffer overflow in WebGL (CVE-2026-4675) e un altro bug use-after-free in Dawn (CVE-2026-4676). Il cacciatore di bug ha anche segnalato un terzo use-after-free in Dawn (CVE-2026-5284) che è stato corretto questa volta.
---
<div id='thevulnerability-executionlayers'/>
### ***🔗 Da JavaScript all'Hardware***
Per capire da dove può nascere un UAF in Dawn, è utile vedere esattamente come una chiamata WebGPU viaggia da una riga di JavaScript fino all'hardware fisico:```
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
The fundamental tension is that queue.submit() and buffer.destroy() are both JavaScript API calls that return immediately, but the GPU executes the submitted commands asynchronously, potentially long after both calls have returned. Dawn needs to keep buffer objects alive for the entire duration of GPU execution, not just until the JavaScript call returns.
Quando la UAF si attiva, la GPU incappa in quello che D3D12 chiama un evento "Device Removed". La sequenza è:```
Questo è anche ciò che rileva il runner di test automatizzato in questo repository: osserva quei segnali console esatti per determinare se la vulnerabilità è sfruttabile in una data versione di Chrome.
---
<div id='thevulnerability-impact'/>
### ***💥 Impatto e requisiti di sfruttamento***
La descrizione NVD è specifica su un vincolo importante: lo sfruttamento richiede che l'attaccante abbia già compromesso il processo renderer. Ciò significa che CVE-2026-5281 non è un RCE autonomo con un solo clic da un avvio a freddo, è un sandbox escape che diventa parte di una catena.
In pratica, una catena di attacco completa sarebbe qualcosa del tipo:```
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.
CVE-2026-5281 non è apparsa in isolamento. È stato il quarto zero-day di Chrome del 2026, un anno che era già sulla buona strada per superare il totale di otto zero-day del 2025 prima della fine del Q1.
| Data | Evento |
|---|---|
| Febbraio 2026 | CVE-2026-2441 corretta, UAF nel componente CSS di Chrome, attivamente sfruttata |
| 10 marzo 2026 | CVE-2026-3909 e CVE-2026-3910 corrette, entrambi zero-day attivamente sfruttati |
| 23 marzo 2026 | CVE-2026-4675 (overflow del buffer heap in WebGL) e CVE-2026-4676 (UAF in Dawn) corrette, stesso segnalatore di CVE-2026-5281 |
| 1 aprile 2026 | Google rilascia Chrome 146.0.7680.177/178, 21 vulnerabilità corrette, CVE-2026-5281 confermata sfruttata in natura |
| 1 aprile 2026 | CISA aggiunge CVE-2026-5281 al catalogo Known Exploited Vulnerabilities |
| 3 aprile 2026 | Google riconosce lo sfruttamento attivo contro 3,5 miliardi di utenti Chrome |
Lo stesso ricercatore pseudonimo che ha segnalato CVE-2026-5281 ha segnalato anche altre tre vulnerabilità nella finestra temporale circostante (CVE-2026-4675, CVE-2026-4676, CVE-2026-5284, le ultime due anch'esse UAF in Dawn). Ciò suggerisce uno sforzo di ricerca mirato e continuo specificamente incentrato sulla gestione della memoria di Dawn.
Il toolkit in questo repository è stato costruito sulla base di una ricerca di sicurezza originale che documenta il comportamento della vulnerabilità in un ambiente di laboratorio. Quello che segue è un riepilogo di quella ricerca, della strategia utilizzata per innescare la UAF e dei risultati osservati.
L'approccio del ricercatore per innescare la UAF è stato progettato per soddisfare simultaneamente le tre condizioni che rendono raggiungibile la race window: pressione sufficiente sulla coda della GPU per ritardare l'esecuzione, tempistiche sufficientemente strette tra destroy e dispatch e riallocazione di buffer della stessa dimensione per massimizzare la probabilità di una corruzione osservabile.
La strategia si articola in cinque passaggi:
Passaggio 1 - Volume e pressione: 200 buffer di storage WebGPU temporanei allocati con dimensioni casuali (tutti multipli di 4 byte, come richiesto dalle specifiche WebGPU). Non si tratta di riempire la VRAM, ma di creare abbastanza lavoro in sospeso da impedire alla GPU di eseguire i comandi immediatamente.
Passaggio 2 - Saturazione dei thread di compute: 32 pipeline di compute parallele accodate con carichi di lavoro pesanti, cicli interni con 1000 iterazioni e dimensioni di dispatch di 4096 workgroup. L'obiettivo è mantenere la coda della GPU profondamente congestionata, così che la finestra tra submit ed esecuzione rimanga aperta abbastanza a lungo da permettere la race.
Passaggio 3 - La trappola: Immediatamente dopo l'invio di tutti i command buffer, viene chiamato destroy() su tutti i 200 buffer. A questo punto la GPU ha ricevuto i comandi ma non li ha ancora eseguiti. Dawn ha già superato la sua validazione al momento del submit. La VRAM viene liberata.
Passaggio 4 - Il grilletto: 32 nuove allocazioni di buffer che utilizzano esattamente le stesse dimensioni dei buffer appena liberati. Se l'allocatore della VRAM restituisce gli stessi indirizzi fisici, cosa che spesso accade poiché le dimensioni coincidono, i comandi in sospeso della GPU ora hanno un handle hardware che punta a memoria appartenente a un'allocazione diversa e ancora attiva.
Passaggio 5 - Riutilizzo dei comandi inviati: Un altro giro di invii di command buffer che utilizzano i buffer appena allocati. A questo punto ci sono due insiemi di comandi in coda che fanno riferimento a quella che un tempo era la stessa memoria, con la GPU ancora intenta a elaborare il primo insieme.
Il risultato è una classica UAF a livello di VRAM: memoria liberata letta attivamente dall'esecuzione di shader ancora in corso.
Il ricercatore ha eseguito il PoC sia su un'installazione di Chrome vulnerabile sia su una corretta e ha osservato una netta separazione comportamentale:
Esecuzione vulnerabile (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.
Il processo Chrome preso di mira ha completamente smesso di eseguire il rendering. Il sistema operativo ha subito un breve blocco visivo, coerente con il ripristino o l'arresto dell'elaborazione da parte del driver di visualizzazione dopo il guasto GPU. L'evento device lost è stato mappato a un errore GPU fatale anziché a un errore di validazione standard dell'API WebGPU, il che conferma che la disposizione corrotta della memoria ha raggiunto il livello hardware senza essere intercettata dalla sandbox lato JavaScript di Chrome.
**Esecuzione con patch (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
No crash, nessuna perdita del dispositivo, nessun segnale GPU fatale in tutti i tentativi. La correzione regge.
Le seguenti acquisizioni sono state effettuate durante i test del toolkit in laboratorio contro un'installazione sia vulnerabile sia corretta di Chrome for Testing su una macchina Windows con GPU integrata Intel gen-12lp. Ogni strumento è stato eseguito contro entrambi i target per verificare la differenza di comportamento.
01 - Rilevatore di Versione
| Vulnerabile (< 146.0.7680.178) |
|---|
| Corretto (>= 146.0.7680.178) |
|---|
 |  |
02 - Verificatore di Vulnerabilità
| Vulnerabile | Corretto |
|---|---|
 |  |
03 - Scanner Locale
| Vulnerabile | Corretto |
|---|---|
 |  |
04 - Scanner di Flotta
| Vulnerabile | Corretto |
|---|---|
 |  |
05 - Trigger UAF
| Chrome | Firefox |
|---|---|
 |  |
Firefox è incluso per confronto. Firefox utilizza una propria implementazione WebGPU e non è interessato da questa vulnerabilità. Completa tutti i tentativi senza alcun segnale di crash indipendentemente dalla versione, che è il comportamento atteso.
06 - Trigger UAF + Esecutore Automatico
| Perdita del Dispositivo GPU |
|---|
 |
Ottenere un segnale di crash visibile non è sempre immediato. A seconda dell'hardware e dell'ambiente, il trigger può richiedere alcune regolazioni per produrre risultati osservabili. Nel nostro caso, il comportamento era riproducibile, ma non sempre si manifestava in modo coerente senza adattare il carico di lavoro.
Abbiamo riprodotto con successo un Denial of Service contro un'installazione vulnerabile di Chrome in un ambiente di laboratorio controllato. Il trigger UAF porta la GPU a saturazione al 100% di utilizzo, poiché la coda di comandi fortemente intasata impedisce al driver di servire nuove richieste di gestione della memoria. In alcune esecuzioni, il processo GPU è entrato in uno stato di fault irreversibile, producendo i seguenti effetti osservabili:
La saturazione della GPU e l'eccezione occasionale confermano che la corruzione della memoria raggiunge il livello hardware: l'handle del buffer liberato viene acceduto dagli shader ancora in esecuzione, la GPU va in fault e il meccanismo TDR di D3D12 lo fa emergere come evento di rimozione del dispositivo. La versione corretta ha completato lo stesso carico di lavoro senza problemi e senza alcun segnale di crash.
La riproduzione del DoS conferma la vulnerabilità. Il lavoro in corso è incentrato sull'analisi a livello binario della patch, in particolare sul diff del percorso di invio del command buffer di Dawn tra l'ultima build vulnerabile e la 146.0.7680.178, per capire esattamente dove e come è stata applicata la correzione al reference counting.
Per quanto riguarda l'esecutore automatico: il ricercatore originale ha pubblicato uno script runner insieme alla propria PoC. La nostra versione ha richiesto modifiche per funzionare in modo affidabile in un contesto di laboratorio locale, in particolare il passaggio alla nuova modalità headless di Chrome e l'aggiunta di un'opzione per consentire la propagazione dei segnali di crash della GPU dal processo GPU al renderer. Senza questi due flag, Chrome assorbe silenziosamente i crash del processo GPU e la differenza di comportamento tra build vulnerabili e corrette non è osservabile da JavaScript.
Poiché il lavoro di reverse engineering e di diff binario è ancora in corso, l'esecutore automatico non è pubblicato in questo repository. Sarà incluso in un aggiornamento successivo al termine dell'analisi della patch.
Usa solo su sistemi di tua proprietà o per cui hai ricevuto esplicita autorizzazione ai test.