Nel marzo 2025 Google ha pubblicato un aggiornamento di Chrome per la vulnerabilità CVE-2025-2783, segnalando che era già sfruttata. Il bollettino parla di un handle fornito in modo errato in circostanze non precisate su Windows. I dettagli pubblici dell'attacco sono limitati. Il bollettino di Chrome mostra perché conviene aggiornare subito anche quando la catena d'attacco completa non è stata divulgata.
Si parla di zero-day quando una vulnerabilità viene sfruttata prima che sia disponibile una correzione pubblica. Questo non significa che ogni browser o utente sia vulnerabile: contano versione, piattaforma, impostazioni e modalità di consegna dell'attacco. Gli aggiornamenti chiudono le falle note; le difese del browser e la prudenza con contenuti rischiosi possono ridurre l'esposizione prima dell'arrivo della patch.
Cos'è davvero uno zero-day

Immagina una porta con una serratura difettosa. Qualcuno potrebbe scoprire il difetto prima che il proprietario abbia una sostituzione pronta. In informatica, zero-day indica una vulnerabilità usata dagli attaccanti prima che esista una patch pubblica. Il produttore potrebbe già conoscerla oppure no. Se viene sfruttata dopo la pubblicazione della patch, di solito si parla di vulnerabilità n-day.
I browser elaborano contenuti web complessi e non affidabili, ma dispongono di più livelli di difesa. Un difetto nel processo che mostra le pagine è grave, senza però dare automaticamente il controllo del sistema operativo. In base al browser, alla piattaforma e all'obiettivo, potrebbe servire anche un modo per uscire dalla sandbox o elevare i privilegi. L'architettura di isolamento dei siti di Chromium descrive uno dei livelli che limitano un processo compromesso.
Il vantaggio di uno zero-day per l'attaccante è che i difensori non possono ancora installare una patch specifica. Non è però invisibile per definizione: monitoraggio del comportamento, isolamento dei siti, sandbox e analisi degli incidenti possono rilevare o limitare l'attacco. Serve inoltre un modo per raggiungere un sistema vulnerabile, per esempio una pagina malevola o contenuti preparati ad hoc.
Il ciclo di vita di uno zero-day
Questa sequenza semplificata distingue una falla senza patch da una ancora pericolosa dopo il rilascio della correzione.
- 1
Scoperta
Un ricercatore, il produttore o un attaccante trova la vulnerabilità. Può essere segnalata in privato, emergere durante un'indagine o restare nascosta. Non esiste una durata fissa per queste fasi. - 2
Preparazione dell'exploit
L'attaccante cerca di sfruttare il difetto nell'ambiente scelto. A volte basta un solo bug; in altri casi occorre combinarne più di uno, per esempio un difetto nel processo che mostra le pagine e un'uscita dalla sandbox. Il controllo completo del computer non è una conseguenza automatica. - 3
Sfruttamento reale
La consegna può passare da una pagina malevola, un sito compromesso o un link mirato. Potrebbe mancare una firma per l'exploit specifico, ma le difese del browser e gli strumenti che osservano i comportamenti possono comunque bloccare o rilevare parti dell'attacco. - 4
Patch e comunicazione
Il produttore indaga, prepara la correzione e pubblica un avviso. Tempi di comunicazione e distribuzione variano. Una volta disponibile la patch, installarla prontamente chiude quella falla nota sui sistemi interessati. - 5
Sfruttamento n-day
I sistemi che non hanno installato la correzione possono restare esposti. Gli attaccanti talvolta adattano dettagli pubblici o codice già esistente: il riutilizzo è possibile, ma non è una fase inevitabile né ha una durata stabilita. L'analisi di Google sugli exploit riutilizzati mostra perché la patch deve raggiungere davvero gli utenti.

Si parla di zero-day soltanto finché non esiste una patch pubblica. Dopo il rilascio, il rischio si concentra sui dispositivi non aggiornati. Identifica le versioni colpite, applica presto le correzioni e mantieni attive le difese del browser e del dispositivo in ogni fase.
Dove nascono i ritardi negli aggiornamenti

I test di compatibilità, le regole sui dispositivi gestiti o un browser lasciato aperto possono ritardare gli aggiornamenti. Questo ritardo è diverso dal periodo in cui la patch non esiste ancora. Entrambi richiedono più livelli di difesa, ma solo l'aggiornamento corregge una falla divulgata nella versione interessata.
Prima della patch. Non esiste ancora una correzione specifica per il software colpito. Versione, sistema operativo, impostazioni e condizioni dell'exploit determinano chi è esposto. Il produttore può limitare i dettagli tecnici mentre prepara la correzione.
Patch disponibile, ma non installata. Un'organizzazione può dover coordinare prove e distribuzione. Nel frattempo gli attaccanti possono puntare alle vecchie versioni. La pubblicazione di una patch non protegge il dispositivo finché il browser non usa la versione corretta.
Dispositivi dimenticati. Postazioni condivise, sistemi operativi non più supportati e browser non gestiti possono saltare la correzione. Un inventario e il controllo delle versioni aiutano a individuarli, senza dare per scontato che tutti siano aggiornati.
Rinvii eccezionali. Se devi rinviare un aggiornamento, limita l'accesso a contenuti rischiosi, conserva le protezioni del browser gestito e stabilisci quando installare la versione corretta. La navigazione remota può ridurre l'esposizione locale al codice dei siti, ma non giustifica un rinvio e non elimina i rischi per gli account usati nella sessione.
Cosa mostrano i dati
Nel 2024 Google Threat Intelligence Group ha contato 75 vulnerabilità zero-day sfruttate e divulgate, considerando prodotti di vario tipo, non soltanto browser. La sua analisi del 2024 comprende i casi individuati e resi pubblici, non ogni attacco avvenuto.
zero-day sfruttati e rilevati nel 2024, su tutti i prodotti
nei prodotti per utenti, compresi browser e sistemi operativi
nei prodotti destinati alle aziende
Nello stesso insieme di dati, gli zero-day dei browser rilevati sono scesi da 17 nel 2023 a 11 nel 2024. Questi numeri non indicano un ritardo universale delle patch né la probabilità che un qualsiasi utente venga attaccato. Mostrano perché bisogna conoscere le versioni in uso, installare le correzioni disponibili e mantenere altre difese prima che una patch esista.
Casi documentati nei browser
Gli avvisi dei produttori documentano la falla e la correzione, ma spesso forniscono pochi dettagli sulle vittime o sulla catena d'attacco completa. Questi quattro esempi mostrano anche i limiti delle informazioni pubbliche.

Chrome CVE-2023-2033. Il bollettino di Google dell'aprile 2023 descrive un errore di tipo nel motore V8 e conferma un exploit in circolazione. Non indica come sia stato distribuito né documenta il controllo completo del sistema.
Firefox CVE-2024-9680. Nell'avviso dell'ottobre 2024 Mozilla segnala un difetto di uso della memoria nelle animazioni e conferma che è stato sfruttato. L'avviso non descrive la campagna, un'uscita dalla sandbox o spyware.
Safari 18.1.1. L'avviso di sicurezza di Apple elenca CVE-2024-44308 in JavaScriptCore e CVE-2024-44309 in WebKit. Apple segnala che entrambe potrebbero essere state sfruttate su Mac con processori Intel. L'avviso non indica la modalità di consegna né una campagna successiva.
Chrome CVE-2025-2783. Il bollettino di marzo 2025 conferma lo sfruttamento della falla e fornisce un aggiornamento per desktop. Non specifica la modalità di consegna né i tempi di distribuzione sui dispositivi.
Lo sfruttamento di una falla del browser e il furto di una sessione autenticata sono conseguenze diverse. Un bug del processo che mostra le pagine può restare confinato nella sandbox; il furto di una sessione può avvenire anche senza vulnerabilità del browser. Per questo secondo rischio, leggi la nostra guida al furto di sessione.
Difese oltre le patch

Installare rapidamente le patch è essenziale, ma nessun produttore può correggere una falla prima di scoprirla e preparare la soluzione. Le altre difese hanno scopi distinti: ridurre l'accesso al codice vulnerabile, limitare gli effetti dell'exploit o rilevare l'abuso.
Estensioni. Un'estensione può avere ampio accesso alle pagine o ai dati di navigazione, secondo i permessi concessi. Controlla quelle installate ed elimina le inutili. L'abuso di un'estensione è un rischio distinto da uno zero-day del browser: aggiornare Chrome o Firefox non equivale a verificare l'affidabilità delle estensioni.
Difese del browser. Isolamento dei siti, sandbox e altre protezioni possono limitare gli effetti di alcuni difetti. L'efficacia dipende dalla falla e dalla piattaforma; prima di modificare le impostazioni di sicurezza di un browser gestito serve una necessità documentata e una valutazione del rischio.
Sistema operativo e protezione del dispositivo. Aggiorna il sistema operativo oltre al browser. Gli strumenti di sicurezza possono esaminare comportamenti anomali anche senza una firma per il singolo zero-day. Non sono ciechi per definizione, ma neppure garantiscono di fermare ogni attacco.
Browser remoto. Eseguire un sito in un browser remoto può ridurre l'esposizione diretta del browser locale e del sistema operativo al codice di quel sito. Non impedisce però attacchi agli account usati nella sessione, download rischiosi o interazioni tramite visualizzatore e appunti. Le sessioni Browser.lol non terminano necessariamente quando chiudi la scheda, e i profili salvati possono persistere. L'isolamento integra gli aggiornamenti, non ne giustifica il rinvio.
Una difesa a più livelli
Ogni misura interviene in una fase diversa. La sua efficacia dipende dalla falla, dalla configurazione e dall'uso concreto.
| Misura | Prima della patch pubblica | Dopo la pubblicazione della patch |
|---|---|---|
| Antivirus e protezione avanzata del dispositivo | Possono rilevare comportamenti sospetti; non correggono la falla | Possono rilevare attività mentre arrivano gli aggiornamenti |
| Aggiornamenti del browser e del sistema | Non esiste ancora la correzione per la falla sconosciuta | Installa prontamente la correzione del produttore |
| Reputazione degli URL | Può bloccare un sito di attacco già noto | Dipende ancora dalla visibilità del sito |
| Sandbox e isolamento locale dei siti | Possono limitare alcune fasi dell'attacco | Mantienili attivi insieme agli aggiornamenti |
| Tor Browser | Contano le sue difese e la versione installata | Aggiorna Tor Browser quando esce la correzione |
| Browser remoto | Può ridurre l'esposizione locale al codice web | Aggiorna comunque; account e dati remoti restano esposti |
Nessuna riga promette immunità. L'isolamento remoto cambia il luogo in cui gira il codice del sito; una falla nel browser remoto può comunque colpire quella sessione o gli account aperti al suo interno. Anche il visualizzatore di Browser.lol gira in un browser locale. Prima di considerare un flusso isolato, verifica download, appunti, credenziali ed eventuali profili salvati.
Se devi aprire siti sconosciuti per lavoro, usa un flusso controllato con account di prova ed evita segreti reali, quando possibile. Alla fine verifica che la sessione remota sia davvero terminata: chiudere la scheda non basta. Continua ad aggiornare i browser locali e remoti e a controllare gli avvisi degli altri sistemi.
Limita l'esposizione e aggiorna subito

I casi di zero-day ricordano che una patch specifica non può precedere la scoperta della falla. Non dimostrano che ogni browser sia sempre sotto attacco o che gli aggiornamenti siano inutili. Le correzioni dei produttori, la sandbox, il monitoraggio del dispositivo e il browser remoto hanno ruoli diversi, ciascuno con i propri limiti.
Aggiorna presto i browser interessati, lascia attive le protezioni del browser e usa una sessione remota dove riduce davvero l'esposizione locale. Considera credenziali, file trasferiti e la stessa sessione remota parte del confine di sicurezza. L'insieme di queste misure riduce il rischio senza promettere che ogni exploit sconosciuto verrà fermato.
Ti serve una sessione isolata per la prossima attività?
Apri un browser desktop isolato e inizia direttamente dal tuo browser.
Avvia una sessioneNon devi installare un altro browser • Le funzioni dipendono dal piano



