La catena zero-day del «patch gap» — vulnerabilità già corrette in Chromium e non ancora corrette in Chrome, condivise da più gruppi di spionaggio in 1 settimana
È emerso che la catena di attacco BlueMoon, che concatena l'uscita dalla sandbox V8 di Chrome e l'abuso di ALPC di Windows, era condivisa, nell'osservazione di Volexity, almeno da più cluster di origine cinese. Si riassume il pericolo del «patch gap»: la correzione è entrata in Chromium ma non è ancora riflessa nella versione stabile di Chrome.
Questo articolo è stato tradotto automaticamente.
Il 15 settembre 2026, Volexity ha riferito che un cluster di minacce ritenuto di origine cinese (UTA0560) ha usato, in un attacco di posta mirato contro più ONG il 1 settembre, una catena di attacco (denominata BlueMoon) che concatena vulnerabilità di Google Chrome e di Microsoft Windows. Il link nell'e-mail sfrutta un XSS riflesso di un sito universitario statunitense per condurre verso un'infrastruttura controllata dall'attaccante, dove si svolge un exploit in 3 fasi. Con CVE-2026-85046 si ottiene lettura e scrittura arbitrarie all'interno della sandbox V8, con CVE-2026-87491 si esce dalla sandbox del browser e, infine, con CVE-2026-85880 si abusa di Advanced Local Procedure Call (ALPC) di Windows fino all'iniezione di codice nel processo Chrome e all'esecuzione di codice arbitrario. Volexity segnala anche che l'attaccante applicava un filtro di esclusione a tutto ciò che non fosse Chrome su Windows (secondo le cronache di Volexity / The Hacker News).
Analisi (separata dai fatti): ciò che merita nota è la «condivisione» della stessa catena di exploit. Nell'osservazione di Volexity, in prossimità del momento in cui UTA0560 ha distribuito un backdoor di tipo JavaScript chiamato GRIMWEDGE (un punto d'appoggio iniziale di capacità media che riceve comandi da C2 tramite eval), anche JungleBamboo (APT31) ha distribuito con la stessa catena il loader SUPERSTOMP e, alla fine, ha introdotto l'estensione Chrome di furto di informazioni LONGTALE, che si presenta come l'estensione legittima di Google Gemini. I titoli dei media riportano che «4 gruppi di spionaggio hanno usato lo stesso kit in 1 settimana» (The Hacker News), e viene suggerita la possibilità che gli sviluppatori abbiano ricostruito l'exploit a partire dalle differenze del codice sorgente di Chromium e lo abbiano fornito a più cluster. Una struttura in cui gli exploit circolano come «prodotti» significa che la generalizzazione della superficie di attacco è rapida.
Dal punto di vista tecnico, ciò che è più interessante è il patch gap. Le correzioni di 2 vulnerabilità di Chrome (CVE-2026-85046 / CVE-2026-87491) erano state sottoposte a commit in anticipo nel codice open source di Chromium, ma non erano ancora incluse nel rilascio della versione stabile di Chrome. Nel software la cui cronologia dei commit è pubblica, il rischio di ricostruire il codice di attacco a partire dalle differenze della correzione è sempre presente, ma questo caso è un esempio reale in cui uno stato diverso sia da un normale N-day sia da uno zero-day — «corretto a monte, non ancora corretto a valle» — è stato usato in un attacco reale. Anche il fatto che il ciclo di major release di Chrome sia stato di 4 settimane fino a poco tempo fa (ora è di 2 settimane) si può considerare uno dei fattori per cui la finestra era più facile da prendere di mira per gli attaccanti, ma non è possibile affermarlo in modo definitivo. Volexity segnala che, quanto più gli LLM accelerano la ricerca sulle vulnerabilità e lo sviluppo di exploit, tanto più aumenta il pericolo del patch gap.
Implicazioni per la difesa: (1) Il primo punto di contatto dell'attacco mirato è stato «l'XSS riflesso di un sito legittimo». Prima della difesa di perimetro, diventa importante non lasciare che l'XSS del proprio sito diventi un trampolino della catena. (2) Contro una catena che attraversa sia il browser sia l'OS, hanno senso sia l'isolamento del browser (site isolation e sandbox forzata) sia il rilevamento sull'endpoint. (3) Il patch gap non si previene con «la rapidità di applicazione delle patch». È un ambito in cui hanno effetto, per la prima volta, un team che segue i commit a monte e l'attenzione, dal lato del vendor, al rischio di rendere pubblica una correzione prima del rilascio. (4) Contro il camuffamento di estensioni come LONGTALE, l'inventario delle estensioni installate è una contromisura realistica. I fatti di questo articolo si basano sul rapporto di Volexity e sulle cronache di The Hacker News e di BleepingComputer; la parte di analisi è scritta separata dai fatti.