Vulnerabilità Chrome: rischio exploit per tutti i browser basati su Chromium.

Dietro la sigla CVE-2026-2441 si nasconde un insidioso bug di tipo “use-after-free” nel motore CSS, già attivamente sfruttato, che si aggiunge a una lunga lista di vulnerabilità zero-day che hanno colpito il browser negli ultimi anni.

Il 13 febbraio 2026, Google ha rilasciato un aggiornamento di sicurezza d’emergenza per Chrome, il browser utilizzato da oltre 3,4 miliardi di persone nel mondo.

La ragione è una vulnerabilità critica, classificata come “zero-day”, che gli ingegneri di Mountain View sanno già essere sfruttata attivamente da attaccanti nel mondo reale.

L’identificativo ufficiale è CVE-2026-2441, e dietro questa sigla si nasconde un classico, ma sempre insidioso, bug di tipo “use-after-free” nel motore che gestisce il CSS, il linguaggio che definisce lo stile delle pagine web.

In termini pratici, un attaccante remoto può eseguire codice arbitrario all’interno della sandbox del browser semplicemente convincendo una vittima a visitare una pagina HTML appositamente manipolata.

La patch è stata spinta al canale stabile in soli due giorni dalla segnalazione, avvenuta l’11 febbraio da parte della ricercatrice di sicurezza Shaheen Fazim, un tempo di reazione che tradisce un’urgenza fuori dall’ordinario.

Questa non è una storia isolata, ma l’ultimo capitolo di una serie preoccupante.

Già nel 2024, Chrome si era confermato il browser più colpito da vulnerabilità zero-day sfruttate attivamente, con 75 casi documentati dal gruppo di intelligence di Google.

La frequenza di questi eventi critici solleva domande sulla complessità intrinseca di un software che deve interpretare continuamente codice non attendibile da internet, bilanciando performance, nuove funzionalità e sicurezza.

Ogni componente aggiunto – dai motori JavaScript e WebAssembly ai codec video – espone una nuova “superficie di attacco”.

Il bug di febbraio 2026 colpisce proprio uno di questi componenti fondamentali, il CSSFontFeatureValuesMap, dimostrando come nemmeno le parti più mature e centrali dell’infrastruttura web siano immuni da errori potenzialmente catastrofici.

La corsa contro il tempo tra patch e exploit

La risposta di Google al CVE-2026-2441 è un esempio di efficienza operativa nel campo della sicurezza informatica.

Il processo è codificato e trasparente: una volta ricevuta una segnalazione critica, il team di sicurezza Chromium sviluppa una correzione mirata, la testa e la invia attraverso i canali di rilascio.

Per le emergenze, si bypassa il ciclo di rilascio regolare di sei settimane di Chrome a favore di un aggiornamento “cherry-picked”, selezionato appositamente per la versione stabile corrente.

L’obiettivo è chiudere la falla nel minor tempo possibile, prima che le informazioni tecniche si diffondano troppo.

Per questo, Google mantiene solitamente l’accesso ai dettagli del bug riservato fino a quando la maggior parte degli utenti non ha applicato la correzione.

Tuttavia, la velocità di Google si scontra con la lentezza, spesso inevitabile, del mondo reale.

L’aggiornamento correttivo, le versioni 145.0.7632.75/76 per Windows e macOS e la 144.0.7559.75 per Linux, non raggiunge tutti simultaneamente.

Il rollout è progressivo e, come spesso accade per gli aggiornamenti significativi, inizia con gli utenti di lingua inglese negli Stati Uniti per poi espandersi a tutti i paesi e le lingue nei mesi successivi.

Questo crea una finestra di vulnerabilità differenziale: mentre alcuni sono già protetti, altri, magari in regioni con connessioni lente o abitudini digitali diverse, rimangono esposti.

È in questo lasso di tempo che gli attori malevoli intensificano i loro sforzi, cercando di massimizzare il numero di vittime prima che la patch diventi ubiqua.

Google è a conoscenza del fatto che esiste uno exploit per CVE-2026-2441 in circolazione.

— Google Chrome Releases Blog

La dichiarazione ufficiale è secca e non fornisce dettagli sugli attaccanti, sui loro obiettivi o sulle modalità precise dell’attacco.

Questo silenzio è una prassi consolidata, volta a non fornire istruzioni utili a potenziali emulatori.

Ma lascia anche un alone di incertezza.

Chi sta sfruttando questa falla? È un gruppo criminale interessato al furto di credenziali finanziarie o un attore statale impegnato in una campagna di sorveglianza mirata?

L’unica certezza è che la vulnerabilità permette di saltare una delle fondamentali barriere protettive di Chrome: la sandbox.

Questo meccanismo dovrebbe confinare l’esecuzione del codice della pagina web in un ambiente isolato, impedendole di danneggiare il sistema operativo sottostante.

Un “use-after-free” di successo può permettere di fuggire da questa gabbia, anche se parziale, concedendo privilegi pericolosi.

Il paradosso della complessità e la sfida della superficie d’attacco

Guardando oltre il singolo episodio, l’accumularsi di zero-day in Chrome pone una questione tecnologica spinosa.

Da un lato, il progetto Chromium è un trionfo dell’open source e della collaborazione, con una sicurezza rafforzata da programmi di bug bounty e audit continui.

Dall’altro, la sua stessa natura di “piattaforma web universale” lo rende un bersaglio iper-appetibile e di una complessità mostruosa.

Ogni nuova API, ogni ottimizzazione per le performance, ogni supporto a uno standard emergente aggiunge linee di codice che devono essere perfette.

Non lo sono mai.

La vulnerabilità CVE-2026-2441 arriva a pochi giorni da un altro aggiornamento di sicurezza, quello del 10 febbraio, che aveva corretto due falle ad alta criticità in componenti come il codec video VP9 (libvpx) e il motore JavaScript V8.

E mentre Google tampona queste falle, il panorama delle minacce evolve.

Un’altra issue tracciata nei bug tracker di Chromium, ad esempio, evidenzia come il metodo di cifratura utilizzato per proteggere dati sensibili come password e cronologia in alcuni browser basati su Chromium possa essere troppo debole, esponendo gli utenti a rischi se un malware riesce ad accedere localmente ai file del browser.

Sono problemi di natura diversa – uno è un bug di memoria, l’altro una scelta progettuale discutibile – ma concorrono allo stesso risultato: minare la fiducia nell’ambiente browser come luogo sicuro.

La domanda finale, allora, non è tanto se Google sia bravo a rispondere alle emergenze (lo è), ma se il modello di sviluppo attuale sia sostenibile a lungo termine.

Possiamo continuare ad aggiungere funzionalità a un software che è ormai un sistema operativo per il web, affidandoci a un ciclo perpetuo di scoperta, sfruttamento e patch?

O serve un cambio di paradigma, che forse passa per linguaggi di programmazione più sicuri per i componenti critici, per sandbox ancora più aggressive, o per un’architettura che riduca radicalmente la quantità di codice “trusted” necessario?

Per ora, l’unica risposta pratica per miliardi di utenti è quella suggerita dal blog sulle release di Chrome: cliccare su “Aggiorna” il prima possibile.

Ma è una soluzione che tratta il sintomo, non la malattia strutturale della sicurezza informatica moderna.