Uno zero-day su Chrome è in fase di sfruttamento attivo. Ecco cosa dovrebbe fare davvero il tuo team di sviluppo.

Questa settimana Google ha rilasciato una patch d'emergenza per CVE-2026-3910, uno zero-day ad alta gravità nel motore JavaScript e WebAssembly V8 di Chrome. La vulnerabilità è un bug di type confusion nel compilatore JIT Maglev di V8 che consente a un attaccante di eseguire codice arbitrario all'interno della sandbox del browser, innescato semplicemente visitando una pagina web malevola. Il Threat Analysis Group di Google lo ha scoperto il 10 marzo e ha confermato lo sfruttamento attivo in the wild prima del rilascio della patch. La CISA lo ha aggiunto al catalogo delle Known Exploited Vulnerabilities il 13 marzo, con scadenza federale per l'applicazione della patch al 27 marzo.

Questo è il terzo zero-day attivamente sfruttato su Chrome nel 2026. Il precedente, CVE-2026-2441, era una use-after-free nella gestione del CSS, corretta appena un mese fa. Il ritmo sta accelerando, non rallentando.

Perché questo caso è più importante del solito avviso «aggiorna il browser»

Ecco quello che molta della copertura mediatica si perde: CVE-2026-3910 non riguarda solo Chrome. Riguarda ogni browser basato su Chromium, inclusi Edge e Opera, perché condividono tutti il motore V8. Se il tuo team usa uno qualsiasi di questi browser per lo sviluppo, i test o il lavoro quotidiano, sono tutti esposti.

Il vettore d'attacco è incredibilmente semplice. Nessun download di file, nessuna interazione dell'utente oltre al caricamento di un URL. Uno sviluppatore clicca su un link in un messaggio Slack, apre un sito di documentazione compromesso, o visita una watering-hole page, e l'exploit scatta. Durante il nostro lavoro di penetration testing con gli studi di gaming, questo è esattamente il tipo di punto d'ingresso che simuliamo: il browser di uno sviluppatore come anello più debole in un ambiente altrimenti ben difeso.

Il punteggio CVSS è 8,8. Sfruttabile via rete, nessuna autenticazione richiesta, bassa complessità. L'unica cosa che separa un attaccante dall'esecuzione di codice è un singolo clic.

Il vero problema: la maggior parte dei team tratta il patching del browser come un compito di qualcun altro

Negli ambienti enterprise, gli aggiornamenti del browser spesso cadono in una lacuna tra le operazioni IT e i team di sviluppo. L'IT gestisce il patching della flotta per i laptop aziendali, ma potrebbe non coprire le workstation degli sviluppatori con configurazioni personalizzate. Gli sviluppatori, nel frattempo, ignorano gli aggiornamenti del browser o rimandano i riavvii perché hanno 47 schede aperte e un deploy in corso.

Lo vediamo costantemente quando facciamo security review per clienti enterprise, specialmente nei settori regolamentati. La policy di patching esiste sulla carta, ma i computer degli sviluppatori ricevono eccezioni. Quelle eccezioni diventano la superficie d'attacco.

Se la tua organizzazione esegue qualsiasi tipo di applicazione web interna, le cose peggiorano. Sviluppatori e QA engineer trascorrono la giornata nei browser testando il prodotto. Se quei browser non sono aggiornati, il tuo stesso ambiente di staging diventa un potenziale vettore se un attaccante riesce a iniettare contenuto a monte.

Cosa fare subito

Prima, l'ovvio: aggiorna Chrome alla versione 146.0.7680.75 o successiva. Poi riavvia il browser. L'aggiornamento non serve a nulla finché il processo non viene riavviato, e il badge «aggiornamento disponibile» di Chrome è facile da ignorare per giorni.

Ma ecco la parte che la maggior parte degli avvisi salta:

1. Controlla anche Edge e Opera. Se il tuo team usa qualsiasi browser basato su Chromium, necessita della stessa patch. Opera ha già rilasciato il suo aggiornamento. Edge dovrebbe essersi aggiornato automaticamente, ma verificalo.
2. Controlla le tue pipeline CI/CD. Se esegui Chrome o Chromium headless per i test end-to-end (Playwright, Puppeteer, Cypress), verifica quale versione stanno fissando quei container. Abbiamo visto immagini Docker con build di Chromium vecchie di mesi nelle pipeline di test in produzione. Nel nostro lavoro di sviluppo web, fissiamo le versioni del browser in CI ma impostiamo anche alert automatici quando arrivano patch di sicurezza per Chromium.
3. Rivedi la tua policy di gestione del browser. Se non ne hai una che copra specificamente le macchine degli sviluppatori, hai una lacuna. Non deve essere complicata. Un semplice controllo che l'aggiornamento automatico sia abilitato e non sovrascritto da group policy è un inizio.
4. Pensa agli header Content Security Policy. Un CSP robusto non previene l'exploit V8 in sé, ma limita ciò che un attaccante può fare dopo aver ottenuto un punto d'appoggio. Se stai servendo un'applicazione web e non hai rivisto il tuo CSP negli ultimi sei mesi, questo è un buon momento per farlo.

Il quadro generale: V8 sta diventando un bersaglio ricorrente

Tre zero-day su Chrome in meno di tre mesi del 2026. Google ha tracciato 90 zero-day sfruttati in the wild nel corso del 2025, in aumento rispetto ai 78 dell'anno precedente, e le tecnologie enterprise hanno rappresentato quasi la metà di essi.

V8 è un bersaglio appetibile perché è ovunque: Chrome, Edge, Opera, app Electron, Node.js (anche se questo specifico CVE prende di mira la compilazione JIT lato browser, non V8 lato server). Il motore elabora JavaScript non attendibile da ogni sito web visitato da un utente. Ogni ottimizzazione del compilatore JIT è una potenziale superficie d'attacco, e Maglev, il compilatore di livello intermedio in cui vive questo bug, è relativamente nuovo e ancora in fase di maturazione.

Dalla nostra esperienza nel lavoro di sicurezza su web e mobile, gli attacchi basati su browser stanno ricevendo sempre più attenzione da parte di threat actor sofisticati, proprio perché la sicurezza dei browser è migliorata su tutti gli altri fronti. Le sandbox sono più robuste, le catene di exploit sono più lunghe, ma compromettere la sessione browser di uno sviluppatore — con accesso a strumenti interni, console cloud e repository del codice sorgente — vale lo sforzo.

Una nota per i team mobile

Se sviluppi app mobile ibride o usi componenti WebView, tieni d'occhio la versione di Chromium su cui gira la tua WebView su Android. Android System WebView si aggiorna indipendentemente da Chrome sulla maggior parte dei dispositivi, ma non su tutti. Nei nostri progetti nativi iOS e Android, ci siamo allontanati dalle architetture con WebView pesante in parte proprio a causa di questo tipo di rischio nella supply chain. Quando uno zero-day colpisce V8 e la tua app renderizza contenuto web non attendibile attraverso una WebView, la postura di sicurezza della tua app è improvvisamente legata al fatto che il dispositivo dell'utente abbia aggiornato automaticamente i suoi componenti di sistema. Una dipendenza che non puoi controllare.

Conclusione

CVE-2026-3910 non è la vulnerabilità più sofisticata né la più dannosa che vedremo quest'anno. Ma è un buon banco di prova. Se il tuo team non riesce a confermare entro 24 ore che ogni workstation di sviluppo e ogni ambiente CI sta eseguendo una build di Chromium aggiornata, hai un problema di processo che ti farà molto più male quando arriverà qualcosa di più grande.

Il fix richiede due minuti. Costruire l'abitudine organizzativa di applicarlo rapidamente, su ogni macchina che conta, richiede un lavoro vero. È quella la parte su cui vale la pena investire.

Se il tuo team ha bisogno di aiuto per inserire il patching del browser e delle dipendenze in un processo ripetibile, o vuoi una security review che copra le lacune a cui la maggior parte dei team non pensa, parliamone.