CVE-2026-5281: il quarto zero-day Chrome del 2026 colpisce WebGPU

CVE-2026-5281 è un use-after-free in Dawn, il layer WebGPU di Chrome, sfruttato attivamente dal 10 marzo 2026.

Il 1 aprile 2026, Google ha rilasciato un aggiornamento di emergenza per Chrome che correggeva 21 vulnerabilità. La più urgente era nascosta in un componente che la maggior parte degli utenti non ha mai sentito nominare: Dawn, la libreria che gestisce l’accesso della GPU all’interno del browser. Poche ore dopo la pubblicazione della patch, la CISA ha aggiunto la CVE al proprio catalogo delle vulnerabilità sfruttate attivamente, con scadenza per le agenzie federali fissata al 15 aprile 2026.

1. Scoperta e cronologia di CVE-2026-5281
2. Cos’è Dawn e perché è un bersaglio
3. Come funziona CVE-2026-5281
4. Versioni affette e come proteggersi

Ciò che rende questa storia più interessante di una semplice notizia di patch è il contesto in cui si inserisce. CVE-2026-5281 è il quarto zero-day Chrome sfruttato attivamente nel 2026, a soli quattro mesi dall’inizio dell’anno. Tutti e quattro sono vulnerabilità di tipo memory safety. Due dei quattro, incluso questo, colpiscono il layer grafico del browser. Tutti e tre i bug Dawn e WebGL che hanno preceduto questo, erano stati scoperti dallo stesso ricercatore anonimo, in meno di due settimane.

Ma come sempre, andiamo con ordine e affrontiamo per gradi l’argomento.

La scoperta e la cronologia di CVE-2026-5281

I dati raccolti da HivePro indicano che lo sfruttamento attivo di CVE-2026-5281 è confermato a partire dal 10 marzo 2026, tre settimane prima che Google rilasciasse la patch. Durante questo intervallo, chiunque usasse una versione vulnerabile di Chrome o di qualsiasi altro browser basato su Chromium navigava con una finestra aperta verso l’esecuzione di codice arbitrario, senza saperlo e senza che esistesse alcuna contromisura disponibile.

Il 23 marzo 2026, Google aveva già corretto due bug correlati segnalati dallo stesso ricercatore: CVE-2026-4675 e CVE-2026-4676, entrambi nel layer Dawn/WebGL. Tre bug critici nel componente grafico di Chromium, dallo stesso reporter, in undici giorni: il segnale di una campagna di fuzzing mirata e sistematica contro la superficie di attacco GPU di Chrome, non di scoperte casuali. Il 1 aprile arriva la patch per CVE-2026-5281, distribuita nel canale Stable Desktop di Chrome come aggiornamento di emergenza. Lo stesso giorno, la CISA inserisce la vulnerabilità nel catalogo KEV, confermando lo sfruttamento attivo e imponendo alle agenzie federali statunitensi di aggiornare entro il 15 aprile.

CVE-2026-5281 non è il primo zero-day Chrome del 2026: a febbraio era stato il turno di CVE-2026-2441, un use-after-free nel motore CSS. A marzo erano arrivati CVE-2026-3909 e CVE-2026-3910, rispettivamente un out-of-bounds write nella libreria grafica Skia e un bug nel motore JavaScript V8, entrambi con CVSS 8.8. Quattro zero-day in quattro mesi, tutti memory safety issues, tutti sfruttati prima della patch.

Cos’è Dawn e perché è un bersaglio

WebGPU è il successore di WebGL: uno standard web che concede ai siti web accesso diretto all’hardware grafico del dispositivo per operazioni ad alte prestazioni come rendering 3D, inferenza di modelli di machine learning ed effetti visivi computazionalmente intensi. È un’API potente, sempre più adottata nell’ecosistema web e progettata per esporre direttamente al browser funzionalità che fino a qualche anno fa erano riservate alle applicazioni native.

Dawn è la libreria C++ che Chrome usa internamente per tradurre le chiamate API WebGPU in comandi specifici per la piattaforma: Vulkan su Linux e Android, Metal su macOS e iOS, Direct3D 12 su Windows. È il layer di astrazione che si interpone tra il codice JavaScript di una pagina web e il driver della GPU installato sul sistema. Questo posizionamento architetturale lo rende un bersaglio di particolare interesse: un bug in Dawn opera in un punto in cui il codice web è ancora relativamente controllato, ma il confine con l’hardware fisico è già molto vicino.

Il problema è che Dawn, come la quasi totalità del codice grafico di Chromium, è scritto in C++, un linguaggio che non offre garanzie di memory safety a livello di compilatore. Google ha investito significativamente nella riscrittura di componenti critici di Chrome in Rust, che previene per design intere classi di vulnerabilità come gli use-after-free. Il graphics stack, tuttavia, non è ancora stato convertito. Finché questa migrazione non avviene, la superficie esposta dalle API GPU rimarrà un terreno fertile per la ricerca di vulnerabilità da parte di attori con le competenze e le risorse per farlo sistematicamente.

Come funziona CVE-2026-5281

Per comprendere la gravità della situazione, procederemo a spiegare il funzionamento della vulnerabilità attraverso una simulazione di attacco suddivisa in fasi.

Fase 1 — Compromissione del renderer

CVE-2026-5281 non è una vulnerabilità che si sfrutta direttamente dalla pagina web. La descrizione ufficiale NVD specifica che l’attaccante deve aver già compromesso il renderer process per poterla sfruttare. Chrome esegue ogni tab in un processo separato con privilegi ridotti, il cosiddetto renderer process, isolato dal sistema operativo tramite la sandbox. Per arrivare a CVE-2026-5281, l’attaccante ha bisogno di un primo bug che rompa il renderer. Nella pratica delle campagne di exploit in-the-wild, questo si ottiene con una vulnerabilità separata nel motore JavaScript V8 o nel parser HTML, che consente l’esecuzione di codice arbitrario all’interno del renderer attraverso una pagina HTML appositamente costruita. L’utente non deve fare nulla di particolare: visitare la pagina è sufficiente.

Fase 2 — Trigger del use-after-free in Dawn

Una volta dentro il renderer, l’attaccante esegue chiamate WebGPU malevole progettate per innescare la condizione di use-after-free in Dawn. Un use-after-free si verifica quando un oggetto viene deallocato dalla memoria, ma un puntatore a quell’oggetto viene mantenuto e successivamente dereferenziato. In Dawn, durante la gestione del ciclo di vita delle risorse GPU, certi oggetti possono essere liberati mentre i riferimenti a essi non vengono invalidati correttamente. L’attaccante costruisce una sequenza di chiamate WebGPU che porta Dawn a liberare un oggetto critico e poi a tentare di accedervi nuovamente attraverso il puntatore rimasto pendente, il cosiddetto dangling pointer.

Fase 3 — Corruzione della memoria e controllo del flusso

Quando il dangling pointer viene dereferenziato, il programma accede a una zona di memoria che nel frattempo potrebbe essere stata riallocata per altri scopi. In uno scenario di sfruttamento controllato, l’attaccante ha già preparato il terreno per fare in modo che quella zona di memoria contenga dati di propria scelta, una tecnica nota come heap grooming. Il risultato è che Dawn, credendo di accedere a un oggetto GPU legittimo, opera su dati malevoli. Attraverso questa corruzione, l’attaccante può sovrascrivere strutture dati critiche, come i puntatori a funzione, reindirizzando il flusso di esecuzione verso codice di propria scelta. A questo punto il renderer process esegue codice arbitrario dell’attaccante all’interno della sandbox di Chrome.

Fase 4 — Sanbox evasion e arbitrary code execution

L’esecuzione di codice nel renderer process è un risultato significativo, ma non definitivo. Chrome isola il renderer dalla maggior parte delle risorse di sistema tramite sandbox. Per causare danni concreti, come l’installazione di malware, l’accesso ai file o la persistenza sul sistema, l’attaccante ha bisogno di un secondo bug che gli permetta di uscire dalla sandbox. Questo tipo di vulnerabilità, noto come sandbox evasion, viene tipicamente concatenato con il primo in quello che i ricercatori chiamano una exploit chain.

Google non ha rivelato se CVE-2026-5281 venisse usata da sola o in combinazione con una sandbox evasion, ma la pratica di concatenare vulnerabilità è standard per gli attori più sofisticati. La conferma dello sfruttamento attivo prima della patch, insieme all’inserimento immediato nel catalogo KEV, suggerisce un livello di organizzazione coerente con questa ipotesi.

I quattro zero-day del 2026

Tutti e quattro gli zero-day Chrome del 2026 sono vulnerabilità di memory safety: use-after-free, out-of-bounds write, gestione errata del ciclo di vita degli oggetti. Il C++, su cui è costruita la maggior parte del codice critico di Chromium, lascia interamente al programmatore la responsabilità della gestione della memoria. In un codebase della complessità di Chrome, con milioni di righe di codice e decine di contribuitori, è statisticamente inevitabile che queste vulnerabilità emergano. Rust elimina questa intera classe di bug a livello di compilatore, ma la migrazione del graphics stack richiede tempo e risorse. Nel frattempo, ricercatori con strumenti di fuzzing avanzati continuano a trovare bug che esistono nel codice da anni, aspettando solo di essere scoperti.

Versioni affette da CVE-2026-5281 e come proteggersi

La vulnerabilità riguarda tutte le versioni di Google Chrome e dei browser basati su Chromium precedenti alle seguenti build:

• Windows e macOS: Chrome 146.0.7680.178;
• Linux: Chrome 146.0.7680.177.

Per verificare la versione installata e avviare l’aggiornamento, è sufficiente aprire Chrome e seguire il percorso Menu (⋮) → Guida → Informazioni su Google Chrome. Il browser verifica automaticamente la presenza di aggiornamenti e li scarica. È fondamentale riavviare il browser al termine del download: Chrome scarica gli aggiornamenti in background, ma la nuova versione non è attiva finché il processo non viene riavviato. Un badge “Aggiorna” nella barra degli strumenti indica che un aggiornamento è pronto ma non ancora applicato.

L’aggiornamento non riguarda solo Chrome. Tutti i browser basati su Chromium che includono il componente Dawn sono potenzialmente vulnerabili fino a quando non ricevono la correzione corrispondente: Microsoft Edge, Brave, Opera e Vivaldi sono tutti interessati. Vivaldi ha già distribuito la propria patch. Microsoft stava lavorando all’aggiornamento di Edge al momento della pubblicazione di questo articolo. Chi usa uno di questi browser in ambito aziendale deve verificare che il vendor abbia rilasciato un build che include i fix di Chromium 146.0.7680.177/178.

Per gli amministratori di sistema che gestiscono flotte aziendali, è importante verificare che le Group Policy non blocchino gli aggiornamenti automatici di Chrome. In presenza di politiche di aggiornamento gestito, il deploy del build corretto deve essere prioritario rispetto ai normali cicli di testing interni.

In conclusione

CVE-2026-5281 è l’ennesima conferma che il browser è diventato uno dei punti di attacco più redditizi per chi opera a un livello sufficientemente avanzato. Non perché Chrome sia scritto male, ma perché è un software di straordinaria complessità che espone superfici sempre più ampie verso l’hardware fisico, attraverso API come WebGPU che fino a pochi anni fa non esistevano. Ogni nuova funzionalità è anche una nuova potenziale superficie di attacco, e il C++ non perdona.

La risposta immediata è ovvia: aggiornare Chrome e tutti i browser Chromium-based, riavviarli e verificare che l’aggiornamento sia effettivo. La risposta è più lenta, dato che la migrazione del graphics stack a Rust non è ancora stata completata. Fino ad allora, il quinto zero-day del 2026 è solo una questione di tempo.