Sei Zero-Day in Otto Mesi, Una Ricompensa da Mille Dollari

Il team Chrome di Google ha distribuito le build 152.0.7977.82 e .83 per Windows e macOS, e 152.0.7977.82 per Linux, il 3 e 4 settembre 2026, correggendo CVE-2026-85046, un difetto di confusione di tipo nel motore JavaScript e WebAssembly V8 che Google ha confermato essere già sfruttato nel mondo reale. Il bug permette a una pagina web appositamente creata di ingannare il compilatore di V8 e ottenere accesso in lettura e scrittura arbitrario sull'heap del browser, aprendo un percorso verso l'esecuzione di codice remoto all'interno della sandbox di Chrome. Il ricercatore Salvatore Gulizia ha segnalato il difetto il 4 agosto 2026 ed è stato ricompensato con 1.000 dollari; Google ha trattenuto i dettagli tecnici finché la correzione non ha raggiunto la maggior parte degli utenti, così come prassi ormai consolidata per un bug sfruttato attivamente. Questo è il sesto zero-day di Chrome sfruttato attivamente corretto nel 2026, e ognuno di essi ha ottenuto un punteggio CVSS di 8.8 e ha richiesto una correzione d'emergenza fuori ciclo anziché attendere il normale ciclo di rilascio di Chrome.

Mese (2026)CVEComponenteCVSS
FebbraioCVE-2026-2441CSS (use-after-free)8.8
MarzoCVE-2026-3909Skia (scrittura fuori limite)8.8
MarzoCVE-2026-3910V88.8
AprileCVE-2026-5281Dawn / WebGPU (use-after-free)8.8
GiugnoCVE-2026-11645V8 (accesso fuori limite)8.8
SettembreCVE-2026-85046V8 (confusione di tipo)8.8

Otto Giorni Prima Che Partisse il Cronometro

La cronologia di Google mostra lo scarto che conta davvero: ha divulgato e corretto CVE-2026-85046 il 3 e 4 settembre, otto giorni prima della data di entrata in vigore dell'articolo del Cyber Resilience Act dell'UE che avrebbe richiesto una segnalazione formale esattamente di questo tipo di evento. Dall'11 settembre 2026, l'articolo 14 tratta software come Chrome come un prodotto con elementi digitali, e nel momento in cui un fornitore viene a conoscenza dello sfruttamento attivo di una vulnerabilità, deve inviare un allarme rapido a un punto di contatto nazionale e all'ENISA, l'agenzia per la cybersicurezza dell'UE, entro 24 ore, una notifica più completa entro 72 ore, e un rapporto finale entro 14 giorni dalla disponibilità della correzione. Se Google avesse scoperto e divulgato lo stesso bug il 12 settembre invece che il 3 settembre, la sequenza identica - un ricercatore che segnala un bug in V8, Google che conferma lo sfruttamento nel mondo reale, e Google che distribuisce una correzione d'emergenza - sarebbe diventata il primo vero banco di prova del Cyber Resilience Act invece di un avviso di routine. Sei zero-day di Chrome sfruttati in otto mesi nel 2026 rendono un settimo, che arrivi dopo che l'atto ha iniziato a mordere, una questione di quando e non di se.

La Regola Decisionale per Chi Gestisce la Politica delle Patch

La lezione pratica per qualsiasi azienda dell'UE non è aspettare una segnalazione normativa per venire a conoscenza del prossimo zero-day di Chrome, perché le stesse note di rilascio di Google hanno dichiarato che le build corrette sarebbero state distribuite nei giorni e nelle settimane successive anche dopo che la correzione era già disponibile, il che significa che è la velocità dell'aggiornamento automatico, non quella della divulgazione, a decidere per quanto tempo una flotta di computer portatili resta esposta. Chi gestisce la politica degli endpoint dovrebbe considerare il sesto zero-day di quest'anno come un tasso di base, non un'anomalia: con sei incidenti che si verificano ogni sei o sette settimane circa nel corso del 2026, la postura corretta è un processo permanente che confronta settimanalmente le versioni di Chrome installate con l'ultima build stabile, invece di fidarsi che ogni macchina si aggiorni da sola secondo programma. Una volta che il cronometro del Cyber Resilience Act è in funzione, un team IT con sede nell'UE ottiene anche un nuovo segnale da monitorare: la cronologia delle segnalazioni all'ENISA di un fornitore diventa un indicatore approssimativo di quanto spesso i suoi prodotti vengano attaccati attivamente, più concreto di un'affermazione di marketing sulla sicurezza di livello enterprise e vale la pena verificarlo già prima di un rinnovo, non dopo un incidente.