Google pubblica exploit Chromium e Chrome: perché milioni di utenti sono esposti, da 42 mesi

Una falla ancora priva di correzione nel codice di Chromium ha riaperto un tema scomodo per chi sviluppa e usa browser moderni: alcune API pensate per migliorare l’esperienza d’uso sul web possono trasformarsi in un canale utilizzabile per attaccare gli utenti. Il caso in questione riguarda la Background Fetch API, una funzione introdotta addirittura in Chrome 74 (siamo ormai a Chrome 149) e poi arrivata anche nei browser Chromium come Edge 79 e Opera 62.

Non parliamo di una nicchia: secondo StatCounter, ad aprile 2026 Chrome da solo valeva il 68% del mercato browser globale, Edge il 5,5% e Opera l’1,9%. Basta questo dato per capire perché un bug nella base comune di Chromium possa avere un impatto vastissimo.

La vicenda nasce da una segnalazione privata della ricercatrice indipendente Lyra Rebane, inviata a Google alla fine del 2022. Per circa 42 mesi il problema è rimasto confinato nel bug tracker di Chromium, classificato con priorità P1 e severità S2. Poi Google ha pubblicato per errore i dettagli tecnici e il proof of concept, prima di accorgersi della “frittata” e rimuovere tutto.

Perché Background Fetch è una funzione delicata di Chromium e Chrome

Background Fetch nasce con una finalità ben precisa: permettere a una web app di scaricare file di grandi dimensioni, per esempio video, podcast, pacchetti software o modelli AI, anche se l’utente chiude la scheda o perde temporaneamente la connessione.

La documentazione di Chrome descrive così il flusso coinvolto: il sito registra un service worker, avvia un gruppo di richieste tramite backgroundFetch.fetch(), il browser mostra un’interfaccia di avanzamento e, quando il download termina o fallisce, risveglia il worker per gestire l’evento.

In condizioni normali la scelta ha senso. Un service worker non dovrebbe restare vivo per un tempo indefinito, anche per motivi di privacy, consumo energetico e controllo dell’utente. Background Fetch sposta quindi il lavoro pesante sul browser e mantiene il download visibile e annullabile.

Firefox e Safari non supportano Background Fetch; di conseguenza non risultano interessati da questa specifica catena di abuso. Nei browser basati su Chromium, invece, il supporto deriva dalla stessa implementazione di base: Chrome, Edge, Brave, Opera, Vivaldi e Arc condividono una parte rilevante del rischio.

Come funziona l’abuso dell’API

L’attacco descritto sfrutta una pagina malevola visitata dall’utente. Il codice JavaScript richiama la funzionalità di background fetching e apre una connessione gestita attraverso il worker: da quel momento il browser può mantenere o riaprire l’attività anche dopo la chiusura della scheda; in alcuni casi il comportamento sopravvive persino al riavvio del browser o del dispositivo, secondo quanto emerso dai test della Rebane.

L’attaccante non ottiene automaticamente accesso ai file locali, alle email o alle credenziali salvate: la portata resta confinata a ciò che un browser può fare ovvero effettuare richieste di rete, raggiungere siti, fungere da nodo intermedio, generare traffico verso un bersaglio, osservare alcuni segnali indiretti sull’attività dell’utente.

Molte vulnerabilità attirano attenzione quando permettono esecuzione di codice a distanza a livello nativo, fuga dalla sandbox o lettura di dati sensibili. Nel caso delle API Background Fetch il rischio è meno immediato ma più subdolo: un sito qualsiasi può lasciare dietro di sé un’attività persistente, poco visibile e gestita da un componente che l’utente di solito non conosce.

Botnet limitata, ma non innocua

Definire questa falla come una backdoor completa sarebbe eccessivo. Parlare di rischio trascurabile, però, sarebbe altrettanto sbagliato.

Un insieme di browser agganciati in background può fornire traffico distribuito, relay per richieste anonime, rumore utile a mascherare altre attività e una base pronta per combinarsi con bug futuri.

Gli scenari più realistici includono la configurazione di richieste ripetute verso server controllati dall’attaccante, traffico verso siti terzi per forme di DDoS applicativo, raccolta di timestamp e indirizzi IP osservabili dal lato server, uso come proxy per navigazione o ricognizione.

Non parliamo di un impianto malware tradizionale: non vi è l’installazione di un eseguibile, non c’è persistenza nel registro di Windows, non c’è un’estensione malevola da approvare. Proprio questo schema, tuttavia, l’abuso facile da sottovalutare e, quindi, allo stesso tempo, potenzialmente più pericoloso.

Perché il ritardo nella correzione di Chrome/Chromium pesa

Una segnalazione privata giunta a fine 2022, un problema definito serio dagli sviluppatori nel thread corrispondente, una priorità elevata e poi anni senza una patch pubblica creano un messaggio poco rassicurante. Le grandi code di bug esistono, e chi lavora su progetti complessi lo sa bene. Tuttavia un componente capace di tenere attività di rete in background avrebbe meritato di certo una gestione molto più rapida o, almeno, una qualche forma di neutralizzazione temporanea.

Una possibile spiegazione è che la vulnerabilità non rientri nelle categorie più “definite”: non buca la sandbox, non legge memoria arbitraria, non consegna subito un controllo nativo. Molti processi di triage premiano le falle con impatto diretto e immediatamente dimostrabile; qui invece l’impatto vive nella persistenza, nella visibilità insufficiente e nella possibilità di aggregare più  browser. Per un team di sicurezza maturo, però, questi elementi dovrebbero contare. E pure tanto!

La pubblicazione accidentale del proof of concept peggiora la situazione: quando uno sviluppatore espone codice di sfruttamento prima che la patch correttiva sia disponible, restringe il margine di manovra delle potenziali vittime e allarga quello degli attaccanti.

Cosa possono fare utenti e amministratori

La prima misura resta banale ma necessaria: aggiornare il browser appena il produttore rilascia una correzione specifica.

In attesa delle patch, conviene trattare con sospetto finestre o menu di download che comparissero senza un’azione esplicita: non è un indicatore definitivo, ma è un segnale da non ignorare.

Gli amministratori possono valutare policy che limitano l’esecuzione di JavaScript su siti non affidabili, isolamento tramite profili separati, strumenti DNS o proxy per bloccare domini appena registrati e controllo dei log verso host anomali. In ambienti ad alto rischio, disabilitare o limitare funzionalità sperimentali quando possibile diventa una scelta prudente.

Gli sviluppatori web dovrebbero inoltre tenere presente come un’API quale Background Fetch vada usata solo quando serve davvero, con interazioni utente chiare, dimensioni dichiarate, UI comprensibile e percorsi di annullamento evidenti. Le API persistenti non sono scorciatoie per migliorare l’esperienza; richiedono attenzione simile a quella dedicata a notifiche push, sincronizzazione in background e cache offline.