Chrome sotto attacco: basta visitare una pagina web per essere compromessi

Google ha corretto CVE-2026-11645, una vulnerabilità zero-day nel motore V8 di Chrome già sfruttata in attacchi reali. Il difetto consente l'esecuzione di codice tramite pagine HTML malevole e richiede un aggiornamento immediato.

Una singola pagina web può bastare per compromettere un browser non aggiornato. È il motivo per cui una recente vulnerabilità scoperta e risolta in Google Chrome  deve essere tratta con la massima solerzia, installando l’aggiornamento già disponibile. Rilasciando Chrome 149.0.7827.103, Google ha infatti corretto 74 difetti di sicurezza, ma uno in particolare ha attirato l’attenzione degli analisti: la vulnerabilità CVE-2026-11645, già sfruttata in attacchi reali prima della distribuzione della patch.

Il problema interessa V8, il motore che esegue codice JavaScript e WebAssembly all’interno di Chrome. È il pilastro su cui poggia il funzionamento delle applicazioni web moderne ed è utilizzato in numerosi progetti basati su Chromium.

La nuova falla porta a 5 il numero di zero-day di Chrome sfruttati attivamente e corretti da Google dall’inizio del 2026.

La vulnerabilità CVE-2026-11645 ha ricevuto un punteggio CVSS pari a 8,8 su 10 e il ricercatore che ha identificato il problema ha ricevuto una ricompensa di 55.000 dollari nell’ambito del programma bug bounty di Google.

Come funziona la vulnerabilità CVE-2026-11645

La documentazione tecnica disponibile descrive il difetto come un caso di out-of-bounds read/write all’interno di V8. In termini pratici, il motore JavaScript può accedere a porzioni di memoria che si trovano oltre i limiti previsti: quando un attaccante riesce a controllare tali accessi, può alterare strutture dati interne, leggere informazioni personali e riservate oppure provocare condizioni favorevoli all’esecuzione di codice arbitrario.

La caratteristica più preoccupante riguarda il vettore di attacco: non è infatti necessario installare software o aprire allegati.

Secondo le informazioni pubblicate da Google, un aggressore può predisporre una pagina HTML appositamente costruita per attivare la vulnerabilità. La semplice visita del sito malevolo può innescare la catena di attacco.

L’esecuzione del codice avviene inizialmente all’interno della sandbox del browser: Chrome utilizza da anni meccanismi di isolamento progettati per limitare i danni derivanti da una compromissione. Tuttavia, la storia delle campagne di attacco più sofisticate insegna che una vulnerabilità nel motore JavaScript rappresenta spesso soltanto il primo anello della catena. I criminali informatici tendono infatti ad abbinarla a ulteriori difetti capaci di aggirare la sandbox e ottenere privilegi elevati sul sistema in cui il browser è installato.

Perché il motore V8 continua a essere un bersaglio privilegiato

Le applicazioni web eseguono quantità sempre maggiori di codice direttamente nel browser: per garantire prestazioni elevate, V8 utilizza tecniche di ottimizzazione molto sofisticate come compilazione just-in-time, gestione avanzata degli oggetti JavaScript e supporto nativo a WebAssembly. Questa complessità aumenta inevitabilmente la superficie di attacco.

Le vulnerabilità legate alla gestione della memoria continuano a essere tra i problemi più critici nei software sviluppati principalmente in C++: un errore che consente di accedere a dati oltre i limiti previsti può permettere la lettura o la modifica arbitraria della memoria. A partire da questo punto, un aggressore può tentare di alterare l’organizzazione della memoria, corrompere l’heap (l’area utilizzata per l’allocazione dinamica dei dati) oppure eludere protezioni come ASLR (Address Space Layout Randomization), una tecnica che assegna indirizzi di memoria casuali per rendere più complessa la creazione di exploit affidabili.

Le versioni corrette e i browser coinvolti

Le correzioni sono disponibili nelle versioni 149.0.7827.102 e 149.0.7827.103 di Chrome per Windows e macOS, mentre i sistemi Linux ricevono la versione 149.0.7827.102. Chi utilizza release precedenti dovrebbe considerare il browser vulnerabile fino all’installazione dell’aggiornamento.

Il problema non riguarda esclusivamente Google Chrome. Numerosi browser adottano il codice sorgente di Chromium e condividono gran parte dei componenti fondamentali. Microsoft Edge, Brave, Opera e Vivaldi sono chiamati a integrare le stesse correzioni nei rispettivi canali di distribuzione. Quando emerge una vulnerabilità critica in V8, l’impatto può estendersi ben oltre il prodotto sviluppato da Google.

Un aspetto spesso trascurato riguarda le applicazioni desktop costruite con framework basati su Chromium, come molte soluzioni sviluppate tramite Electron. Sebbene non tutte risultino automaticamente esposte, la presenza di V8 come componente condiviso impone verifiche aggiuntive da parte degli amministratori di sistema e dei responsabili della sicurezza.

La misura più efficace resta l’aggiornamento immediato del browser. Chrome di solito scarica gli update in background, ma la correzione non entra in funzione finché l’applicazione non viene riavviata. Molti utenti mantengono sessioni aperte per settimane senza chiudere il programma; una situazione che può lasciare attive versioni vulnerabili anche dopo il download automatico delle patch.

Un anno particolarmente intenso per la sicurezza di Chrome

Come anticipato in apertura, CVE-2026-11645 rappresenta il quinto zero-day di Chrome corretto dopo la conferma di sfruttamento attivo nel corso del 2026. Nei mesi precedenti Google aveva già affrontato problemi significativi con CVE-2026-2441, CVE-2026-3909, CVE-2026-3910 e CVE-2026-5281.

I browser moderni custodiscono credenziali, cookie di autenticazione, token aziendali, documenti e informazioni personali. Per molti utenti costituiscono la principale interfaccia verso servizi cloud e piattaforme di produttività. Di conseguenza rappresentano uno degli obiettivi più redditizi per gruppi criminali, operatori di spyware e attori sponsorizzati da Stati.

La frequenza con cui emergono vulnerabilità in componenti complessi come V8 non indica necessariamente un peggioramento della qualità del software. Al contrario, riflette l’intensità delle attività di ricerca svolte da ricercatori indipendenti, programmi di bug bounty e team specializzati nell’individuazione di difetti prima che possano essere sfruttati su larga scala.

Ti consigliamo anche

Link copiato negli appunti