Exploit zero-day: perché il tuo browser è vulnerabile

Cos'è davvero uno zero-day

Immagina una casa con una porta sul retro a cui manca la maniglia. Il proprietario non lo sa. Nemmeno il fabbro che segue il quartiere. Un intruso che si accorge per primo della maniglia mancante può entrare e uscire a piacimento, notte dopo notte, senza che nessuno se ne accorga, finché qualcun altro non inciampa per caso sulla stessa porta. Uno zero-day è esattamente quella porta. Lo «zero» indica il numero di giorni che il produttore ha avuto per sistemarlo: il difetto viene sfruttato prima ancora di essere riconosciuto.

Tutti i browser più diffusi ne hanno. Chrome ha patchato dieci zero-day solo nel 2024, Firefox quattro, Safari sette. Il ritmo sta accelerando invece di rallentare, perché la superficie d'attacco non smette di crescere. Ogni nuova API (WebGL, WebAssembly, WebRTC, service workers) aggiunge complessità e nuove classi di bug su cui ricercatori e attaccanti possono mettere le mani.

Quello che distingue uno zero-day dalle vulnerabilità ordinarie è il tipo di danno che permette. Chi ne ha uno in mano può colpire chiunque, ovunque, senza lasciare strumenti né telemetria che la vittima possa ragionevolmente notare. Basta portarti su una pagina, e una pagina si prepara senza fatica.

Il ciclo di vita di uno zero-day

Ogni zero-day attraversa una sequenza prevedibile. Ogni fase ti mostra dove le tue difese tengono e dove cedono.

1. 1

   Scoperta

   Un ricercatore o un attaccante trova il bug. Le scoperte etiche vengono segnalate al produttore. Il resto resta segreto. Alcuni zero-day dormono per mesi prima del primo utilizzo reale.
2. 2

   Weaponizzazione

   Si costruisce l'exploit. Difficilmente si tratta di un solo bug. La maggior parte degli attacchi moderni concatena un bug del renderer, un sandbox escape e un'escalation a livello kernel. Gli attori statali accumulano catene complete e le tengono da parte per bersagli di alto valore.
3. 3

   Sfruttamento sul campo

   L'exploit arriva tramite pubblicità malevole, siti compromessi o link di spear-phishing. Rilevarlo è complicato perché nulla nella consegna sembra fuori posto e l'antivirus non ha firme con cui fare confronto.
4. 4

   Patch e disclosure

   Appena rileva l'abuso, il produttore fa uscire una correzione d'urgenza. Un advisory chiede a tutti di aggiornare subito. La maggior parte degli utenti non aggiorna per giorni o settimane, e le aziende spesso ci mettono ancora di più.
5. 5

   Riutilizzo negli exploit kit

   Gli exploit kit commerciali raccolgono la vulnerabilità ormai patchata e tartassano per mesi la lunga coda dei sistemi non aggiornati. Gli attaccanti riconfezionano la catena per altri browser o la combinano con bug nuovi per allungarne la vita utile.

Gli utenti restano esposti nelle fasi due e tre, e ben dentro la fase quattro. Anche dopo che hai installato la patch, altri dispositivi della tua rete possono essere ancora indietro. Il contenimento deve essere già attivo prima che arrivi la patch, non dopo.

Le tue finestre di esposizione

Tenere i browser aggiornati sembra semplice. In pratica le aziende si destreggiano fra dipendenze, review di compliance e finestre di deployment programmate. Gli utenti comuni liquidano i prompt di aggiornamento nel bel mezzo di una riunione. Il risultato è una serie di buchi prevedibili su cui gli attaccanti possono contare.

Prima della patch (da ore a settimane). L'exploit è attivo e una correzione non esiste. Tutti i browser online sono vulnerabili. I produttori spesso tacciono mentre indagano, lasciando agli attaccanti campo libero su tutta l'utenza esposta.

Patchata, ma non applicata (7-30 giorni). I team IT testano la compatibilità, pianificano i rollout e si destreggiano fra i reboot. Nel frattempo gli attaccanti fanno reverse engineering della patch e costruiscono exploit kit di massa. Appena la correzione diventa pubblica, la corsa cambia marcia di colpo.

Lunga coda (a tempo indeterminato). Chioschi condivisi, sistemi legacy e dispositivi personali restano su vecchie versioni per mesi o anni. Gli attaccanti continuano a sfruttarli molto dopo che i titoli sui giornali si sono spenti.

Aggiornamenti in pausa. Capita che i team congelino gli aggiornamenti per bug, problemi di compatibilità o change freeze di fine trimestre. Il congelamento stesso diventa un bersaglio. Questi buchi esistono anche in ambienti ben gestiti, ed è proprio per questo che l'isolamento conta: gli utenti continuano a lavorare mentre le patch vengono testate, perché il codice non affidabile non arriva mai sulla macchina locale.

Zero-day in numeri

Qualche numero serve a inquadrare la scala. Sono cifre reali del settore, raccolte negli ultimi due anni.

Il divario fra «patch disponibile» e «patch effettivamente distribuita» è il punto in cui si concentra il grosso dei danni. Il Verizon Data Breach Investigations Report mostra che gli attaccanti sfruttano le vulnerabilità pubblicate entro un giorno dal rilascio in più della metà dei casi, mentre la maggior parte delle aziende ha bisogno di due settimane piene per distribuire gli aggiornamenti in sicurezza. È una corsa che non si vince se l'unica difesa su cui si punta è il patching.

Incidenti recenti che hanno scritto il copione

Viene da trattare gli zero-day come rari fulmini a ciel sereno. In realtà sono più simili a un brusio di fondo costante. Bastano pochi esempi recenti per vedere lo schema.

Chrome CVE-2023-2033. Un bug di type-confusion in V8, sfruttato tramite circuiti pubblicitari malevoli. Il payload arrivava a una remote code execution senza alcuna interazione dell'utente. Google ha confermato lo sfruttamento attivo giorni prima che la patch fosse disponibile.

Firefox CVE-2024-29902. Usata in una campagna di spear-phishing di due settimane contro ONG. La catena evadeva dalla sandbox del browser e piazzava spyware persistente sugli endpoint Windows prima ancora che qualcuno segnalasse l'incidente.

Safari WebKit CVE-2024-43817. Mirata agli utenti iOS tramite link iMessage. Il payload installava software di sorveglianza senza alcuna azione da parte dell'utente. Apple ha rilasciato una correzione d'urgenza e gli attaccanti hanno ripiegato per mesi sui dispositivi macOS non aggiornati.

Chrome CVE-2025-1023. Nascosta dentro portali di customer support fraudolenti che invitavano gli utenti a cliccare su «Avvia assistenza remota». Le aziende hanno impiegato cinque giorni per distribuire la patch. Quella finestra è bastata a compromettere diversi bersagli di alto valore nel settore finanziario e in quello sanitario.

Il filo conduttore salta all'occhio una volta che lo individui: consegna via browser, weaponizzazione rapidissima e una comunità di difensori sempre un passo indietro. Per uno sguardo più ampio su come vengono dirottate le sessioni una volta che l'exploit colpisce, leggi la nostra guida sulla protezione dal session hijacking.

Perché patchare non basta

Anche un patching impeccabile lascia buchi. I browser moderni dipendono da estensioni, librerie di sistema, configurazioni utente e componenti del sistema operativo. Ogni anello debole tiene la porta aperta.

Estensioni. Un'estensione compromessa o malevola aggira completamente le patch del browser iniettando script in ogni pagina. L'incidente QuickTranslate del 2025 ha colpito quattro milioni di utenti che avevano il browser perfettamente aggiornato.

Policy mal configurate. Le aziende che disabilitano la site isolation o lo split tunneling per le app legacy aprono varchi. Gli zero-day, spesso, sfruttano proprio quella scorciatoia di configurazione più che un bug del browser stesso.

Escalation di privilegi. Gli exploit del browser si concatenano abitualmente con bug a livello di sistema operativo. Un browser patchato perde comunque se il kernel o il driver grafico sottostante è vulnerabile, ed è lo stato di default della maggior parte dei desktop.

Ritardo umano. Le patch richiedono reboot, gli utenti rimandano per non perdere lavoro, e gli attaccanti calibrano le campagne proprio su quel momento. L'isolamento non sostituisce il patching. Guadagna tempo. Quando la sessione del browser vive in un container cloud usa e getta, una vulnerabilità non patchata esplode lì dentro e svanisce alla fine della sessione. Puoi distribuire gli aggiornamenti con un ritmo ragionevole invece di reagire nel panico.

Cosa ti protegge davvero

Ogni team si crede protetto perché ha i controlli standard. Ecco come si comportano davvero le difese abituali contro un vero zero-day.

L'isolamento cloud è l'unica riga che regge il giorno zero. Tutte le altre presuppongono di sapere cosa cercare, cosa per definizione impossibile davanti a uno zero-day. Un browser remoto usa e getta non ha bisogno di firme né di patch: l'exploit gira dentro un ambiente che butti via in pochi minuti.

Lo schema pratico è semplice. La navigazione ad alto rischio (triage di phishing, onboarding di fornitori, threat research, controllo di fatture sospette) passa per una sessione isolata che si distrugge da sola dopo l'uso. La navigazione di routine resta in locale, dietro i soliti strati di patching e filtri di reputazione. Isolamento e patching non sono alternative, sono le due facce dello stesso approccio.

Contenere l'ignoto prima, patchare dopo

Gli zero-day non spariranno. Il ritmo cresce anno dopo anno e il canale di consegna diventa sempre più affilato. Ogni team che tratta il patching come difesa principale scommette tutto sul fatto che i produttori siano più rapidi degli attaccanti, ed è una scommessa che si perde da un decennio.

La mossa strategica è invertire l'ordine. Prima contenere, poi patchare. Fai passare il traffico rischioso da una sessione che puoi cancellare, lascia che le patch escano a un ritmo ragionevole, e gli zero-day smettono di essere minacce esistenziali. Diventano incidenti: piccoli, circoscritti e risolti senza svegliare nessuno alle 3 di notte.