Chrome CVE-2026-125350: ottavo zero-day del 2026 sfruttato

Il 9 novembre Google ha distribuito un aggiornamento di emergenza per Chrome che chiude nove falle di sicurezza, una delle quali è già usata negli attacchi. CVE-2026-125350 è un use-after-free nel componente XML di Chrome e, per ammissione di Google, per questa vulnerabilità "esiste un exploit in rete". È l'ottavo zero-day di Chrome confermato sfruttato quest'anno: il browser presente su quasi ogni desktop aziendale è, di nuovo, l'obiettivo.

Notizia in evoluzione — pubblicata alle 11:12 (10:12 UTC) del 10 novembre 2026. Aggiornata man mano che Google e gli altri vendor pubblicano.

In breve

CVE	CVE-2026-125350
Prodotto / versioni colpite	Google Chrome (Desktop) precedente a 157.0.8103.50 · browser basati su Chromium con lo stesso engine
Corretta in	Chrome Stable 157.0.8103.50/.51 (Windows, Mac); 157.0.8103.50 (Linux) — rilasciata il 9 novembre 2026
CVSS	Non ancora assegnato da NVD; Google la classifica High
Sfruttata attivamente	Sì — "Google is aware that an exploit for CVE-2026-125350 exists in the wild"
CISA KEV	Non presente (catalogo versione 2026.11.09)
PoC pubblico	Nessuno; Google limita i dettagli del bug finché la maggioranza non aggiorna
Advisory ufficiale	Chrome Releases — Stable Channel Update for Desktop

Che cos'è CVE-2026-125350

Un use-after-free è un errore di gestione della memoria: il codice libera un blocco e continua a usare il puntatore ormai obsoleto. Chi riesce a controllare cosa finisce in quello slot liberato può dirottare l'esecuzione; in un browser significa una pagina web costruita ad arte che trasforma un bug di rendering in codice eseguito dentro la sandbox. Il resto di un attacco reale è l'evasione dalla sandbox verso il sistema, ma il primo passo è semplicemente visitare una pagina.

La falla risiede nel componente XML di Chrome — il codice che analizza e trasforma l'XML, raggiungibile dai normali contenuti web. Secondo l'advisory di Chrome Releases, CVE-2026-125350 è stata segnalata in forma anonima il 6 novembre 2026 e Google ha riconosciuto lo sfruttamento in rete tre giorni dopo. Google non ha attribuito gli attacchi né ha detto se siano mirati, e trattiene i dettagli tecnici — prassi normale finché la maggior parte degli utenti non ha aggiornato. Lo stesso rilascio corregge anche un secondo, distinto use-after-free nel componente XML (CVE-2026-125346, segnalato da un ricercatore di Neonix Security) che non risulta sfruttato.

"Siamo a posto, lo scanner dice Chrome 157." Distribuire il binario non è la stessa cosa che eseguirlo. Chrome prepara l'aggiornamento in background e lo attiva solo al riavvio completo successivo: un portatile non chiuso da due settimane è ancora sulla build vulnerabile, qualunque cosa riporti l'installer.

L'ottavo zero-day Chrome del 2026 — e una rottura dello schema

È l'ottavo zero-day di Chrome che Google segnala come sfruttato nel 2026, dopo una serie iniziata a febbraio con CVE-2026-2441, un use-after-free in CSS, e proseguita fino a CVE-2026-87491 a settembre, il settimo. Cinque dei sette precedenti vivevano in V8, il motore JavaScript di Chrome. CVE-2026-125350 interrompe la serie: è il primo zero-day Chrome sfruttato dal bug CSS di febbraio a cadere fuori da V8. Chi stava scavando nel motore JavaScript si è spostato in un angolo più silenzioso dello stack di rendering — segno che "blindare V8" non è una strategia: l'intera superficie di parsing dei contenuti è in gioco.

Il ritmo è la vera notizia. Uno zero-day di browser sfruttato prima della divulgazione, corretto con dettagli trattenuti e nessuna attribuzione, si addice ai fornitori di spyware e agli operatori allineati a uno Stato, che bruciano catene client-side su bersagli precisi. Per tutti gli altri la finestra di esposizione non è il giorno dell'exploit, ma i giorni e le settimane che servono a una flotta per riavviarsi davvero sulla build corretta — che Google stessa dice "si distribuirà nei prossimi giorni/settimane".

Remediation

1. Sono esposto? Apri chrome://version (oppure chrome://settings/help, che forza il controllo). Qualsiasi build Desktop precedente a 157.0.8103.50 è vulnerabile. Per una flotta gestita, inventaria la versione di Chrome per endpoint e — soprattutto — verifica se il browser è stato riavviato dopo il download dell'aggiornamento.
2. Patch — versioni corrette esatte. Aggiorna a 157.0.8103.50/.51 (Windows, Mac) o 157.0.8103.50 (Linux). La distribuzione è già in corso; non aspettare che arrivi da sola.
3. Forza il riavvio. La correzione si applica solo quando ogni processo di Chrome termina e il browser riparte. Premi Riavvia quando compare il banner, o imponi il riavvio via policy (RelaunchNotification / RelaunchNotificationPeriod tramite Chrome Browser Cloud Management o l'MDM). Non dimenticare il canale Extended Stable e ogni browser basato su Chromium — Edge, Brave, Opera, Vivaldi — che ereditano lo stesso bug e rilasciano la correzione con tempi propri.
4. Non puoi aggiornare subito? Riduci la finestra. Non esiste un'opzione pulita che disabiliti il parsing XML senza rompere il web, quindi l'azione tampone è la riduzione dell'esposizione: assicurati che Site Isolation ed Enhanced Safe Browsing siano imposte da policy e dai priorità agli utenti ad alto valore (amministratori, finanza, dirigenti) per il riavvio forzato.
5. Cerca segni di compromissione. Google non ha pubblicato indicatori, quindi la caccia è comportamentale, non per IOC. Cerca processi figli anomali generati da chrome.exe/dai processi renderer, nuove persistenze (attività pianificate, chiavi run, elementi di avvio) comparse poco dopo la navigazione, crash dump dei renderer concentrati su host specifici e connessioni in uscita verso destinazioni mai viste subito dopo una sessione del browser. Mappalo su MITRE ATT&CK T1189 (drive-by compromise), T1203 (exploitation for client execution) e T1071 (C2 su protocolli web).
6. Bonifica e verifica. Su ogni host che accende quei segnali: isolalo, ruota le credenziali e i cookie di sessione che vivevano in quel profilo del browser (una compromissione a livello renderer può leggerli) e reinstalla se confermi un impianto. Verifica che l'endpoint sia su 157.0.8103.50+ e che si sia riavviato prima di dichiararlo pulito.

Cosa non si sa ancora

• Nessun CVSS da NVD. Al momento della pubblicazione il record non era ancora disponibile; Google la classifica High. La tabella In breve sarà aggiornata quando NVD assegnerà il punteggio.
• Nessuna voce KEV. CVE-2026-125350 non è nel catalogo CISA KEV (versione 2026.11.09) alla pubblicazione; dato lo sfruttamento confermato, un inserimento non sorprenderebbe.
• Nessuna attribuzione, nessun IOC, nessun PoC. Google non ha indicato l'attore, il bersaglio o la catena di exploit, e non esiste alcun proof-of-concept pubblico. Tratta con sospetto qualunque "lista di IOC" che circoli nelle prossime 24 ore.
• Il trigger esatto dentro il componente XML resta non divulgato finché la maggioranza non aggiorna.

Perché la patch non chiude la finestra, e cosa lo fa

Il problema onesto di ogni zero-day di browser sfruttato è il tempo. La patch esisteva il 9 novembre; la tua flotta sarà completamente riavviata su di essa la settimana prossima. In quella finestra l'exploit è attivo e una scansione delle versioni ti dice chi è indietro, non chi è stato colpito. Ciò che intercetta uno sfruttamento riuscito non è l'endpoint, ma quello che il payload fa dopo sulla rete: il beacon verso un server di command-and-control, lo staging silenzioso dei dati per l'esfiltrazione. L'AI Traffic Analysis di Zero Hunt gira un modello di deep learning proprietario con quattro teste di inferenza parallele — traffico sospetto, classificazione malware, identificazione del tipo di attacco, fingerprinting applicativo — sulla GPU dell'apparato, addestrato su miliardi di sequenze PCAP, segnalando quel comportamento di C2 o esfiltrazione mentre accade invece che nel digest del SIEM dell'indomani, e a prescindere dalla build di Chrome sul portatile.

La seconda domanda che un RCE da browser impone è il raggio d'azione: se un endpoint cade, cosa può raggiungere? L'autonomous AI red team di Zero Hunt — dieci agenti coordinati che girano on-premise sui modelli privati dell'apparato, con un human in the loop per ogni azione intrusiva — lo verifica dall'interno, testando se un punto d'appoggio su una workstation può pivotare verso le applicazioni interne e i sistemi di identità che contano, così che un drive-by non diventi la compromissione del dominio. Affiancare una validazione continua e automatizzata alla detection a velocità di rete copre i giorni che una patch impiega ad attecchire. Vedi anche la nostra analisi di un agente AI che costruisce una catena completa per Chrome in sei giorni e di come un red team AI on-premise tenga quel test dentro le tue mura. Parlane con noi.