Google ha rilasciato il 4 settembre 2026 un aggiornamento d'emergenza per Chrome che chiude CVE-2026-85046, una falla nel motore JavaScript V8 per la quale esiste già un exploit in circolazione. È il sesto zero-day di Chrome corretto nel 2026 e arriva insieme ad altre undici correzioni di sicurezza distribuite nello stesso rilascio.

I fatti verificati

La vulnerabilità è un type confusion in V8, il motore JavaScript e WebAssembly su cui girano tutte le pagine web aperte nel browser. Ha punteggio CVSS 8.8 e permette a un attaccante remoto di eseguire codice arbitrario all'interno della sandbox di Chrome semplicemente convincendo la vittima ad aprire una pagina HTML costruita ad arte.

Le versioni corrette sono Chrome 152.0.7977.82/.83 per Windows e macOS e 152.0.7977.82 per Linux. Tutto ciò che precede la 152.0.7977.82 è vulnerabile.

La segnalazione è arrivata il 4 agosto 2026 dal ricercatore Salvatore Gulizia, che nel proprio write-up descrive la causa come un bug nei compilatori di V8: un array con elementi PACKED_ELEMENTS riceve la mappa PACKED_SMI_ELEMENTS, e da questa confusione di tipi si arriva a lettura e scrittura arbitrarie sull'heap JavaScript. La ricompensa riconosciuta è stata di appena 1.000 dollari — cifra bassa che tipicamente segnala una segnalazione con proof of concept parziale, non l'assenza di gravità.

Come da prassi, Google si è limitata a dichiarare che «un exploit per CVE-2026-85046 esiste in natura» senza fornire dettagli su chi stia attaccando, contro quali bersagli e da quando. La restrizione delle informazioni resta in vigore finché una quota sufficiente di utenti non ha aggiornato.

Cosa significa davvero "dentro la sandbox"

Questo è il punto che nella cronaca in italiano viene quasi sempre appiattito, e vale la pena chiarirlo perché cambia il livello di allarme.

Un'esecuzione di codice confinata nella sandbox del renderer non è un compromesso immediato del sistema operativo: per uscire dal processo isolato e arrivare al sistema serve una seconda vulnerabilità, un cosiddetto sandbox escape, da concatenare alla prima. Chi sfrutta zero-day di V8 in campagne reali normalmente possiede già quella seconda falla, oppure la compra.

Questo significa due cose in pratica. La prima: uno zero-day di V8 sfruttato attivamente va trattato come il primo anello di una catena, non come una curiosità accademica. La seconda: anche restando dentro la sandbox, un attaccante ottiene accesso al contenuto della scheda in esecuzione — sessioni, token, dati inseriti nei form della web app aperta. Per un'azienda che vive su applicativi SaaS nel browser, questo è già danno sufficiente.

Cosa significa per le aziende italiane

Chrome (e con lui tutti i browser basati su Chromium: Edge, Brave, Opera, Vivaldi) è il livello software più esposto e meno governato del parco macchine di una PMI italiana media. Nella mia esperienza da consulente, l'aggiornamento del browser è quasi sempre lasciato al meccanismo automatico e nessuno lo misura: non compare nei report di patch management, che si concentrano su sistema operativo e server.

Il problema è che l'aggiornamento automatico di Chrome si completa solo al riavvio del browser. Su un portatile aziendale tenuto in sospensione per settimane, con quaranta schede aperte che nessuno vuole perdere, la patch è scaricata ma non attiva. È esattamente lo scenario in cui uno zero-day già armato continua a funzionare per giorni dopo il rilascio della correzione.

Da tenere presente anche che i browser basati su Chromium non ricevono la correzione lo stesso giorno: Microsoft, Brave e gli altri integrano la nuova base di Chromium con un ritardo che va da poche ore a diversi giorni. Se in azienda Edge è il browser predefinito, la finestra di esposizione è più lunga di quella di Chrome, non uguale.

Sul piano normativo: un incidente che parta da qui e arrivi a dati personali fa scattare gli obblighi dell'art. 33 GDPR, con notifica al Garante entro 72 ore dalla conoscenza. Per i soggetti in perimetro NIS2, un browser non aggiornato su endpoint che accedono a sistemi essenziali è una debolezza difficile da giustificare in sede di verifica: le misure di gestione dei rischi richiedono procedure di gestione delle vulnerabilità documentate, non solo l'attivazione dell'aggiornamento automatico.

Cosa fare subito

  • Verificare la versione: aprire chrome://settings/help e controllare di essere almeno alla 152.0.7977.82. La pagina forza anche il controllo degli aggiornamenti.
  • Riavviare il browser, non solo aggiornarlo. Senza riavvio la patch non è attiva. Su Chrome comparirà il pulsante "Riavvia".
  • Forzare la distribuzione da policy: su parco Windows gestito, impostare RelaunchNotification = 2 e RelaunchNotificationPeriod (per esempio 24 ore) via GPO o Chrome Browser Cloud Management, in modo che il riavvio diventi obbligatorio e non una richiesta ignorabile.
  • Estendere il controllo a Edge, Brave, Opera e Vivaldi e a qualunque applicazione desktop basata su Electron o CEF che incorpori Chromium: quelle non si aggiornano con Chrome e sono la coda lunga del problema.
  • Censire il browser nell'inventario: se la versione di Chrome non compare nel vostro strumento di asset o vulnerability management, aggiungerla è la correzione strutturale che vale più della singola patch.
  • Non fidarsi solo dell'aggiornamento automatico su macchine in mobilità: verificare a campione i portatili che restano fuori rete a lungo.

In sintesi

Nessun panico, ma nemmeno rinvio. La correzione esiste, è gratuita e richiede trenta secondi per macchina; l'unico vero ostacolo è culturale, cioè l'abitudine a non riavviare mai il browser. Chi ha un processo di patch management che si ferma al sistema operativo, oggi ha un buon motivo per estenderlo.