Chrome VRP: Google rialza i compensi, ma solo in parte

Google ha alzato i compensi del Chrome Vulnerability Reward Program (Chrome VRP), il programma che paga chi segnala vulnerabilità nel browser. L’annuncio è di martedì 13 ottobre 2026 e lo riportano SecurityWeek e Help Net Security. Le novità riguardano soprattutto i difetti di corruzione della memoria e le fughe dalla sandbox.

È il secondo intervento di Google sui suoi programmi di ricompensa in poche settimane: all’inizio di ottobre ARX News aveva raccontato la sospensione delle ricompense per le vulnerabilità di prodotto dell’OSS VRP, sommerso da report automatici non validi. Non ci sono CVE né aggiornamenti legati a questa notizia.

Cosa è successo

Secondo SecurityWeek, ad aprile 2026 Google aveva ridotto in modo consistente i compensi standard per alcune vulnerabilità di Chrome, per concentrare il programma sui report utili a intervenire; alcuni ricercatori avevano notato ricompense diventate dieci volte più basse. La base per i problemi di sicurezza della memoria era scesa a 500 dollari, con moltiplicatori legati alla raggiungibilità del difetto e al grado di sfruttabilità. La testata collega questi aggiustamenti al modo in cui l’intelligenza artificiale sta cambiando ritmo e profilo della scoperta di vulnerabilità.

Ora la base sale a 2.000 dollari, quattro volte tanto: lo confermano entrambe le fonti. SecurityWeek precisa che, nonostante l’aumento, le nuove tariffe restano molto al di sotto di quelle in vigore prima della revisione di aprile; Help Net Security non cita i tagli e presenta la notizia solo come un aggiornamento del programma.

Le nuove tariffe

Per la corruzione della memoria (dati concordi tra le due fonti, salvo dove indicato):

• processi browser, rete e GPU: fino a 20.000 dollari. Solo Help Net Security dettaglia la scala: fino a 4.000 dollari per letture e crash, fino a 10.000 per scritture, use-after-free e letture controllate, fino a 20.000 per scritture controllate dimostrate a partire da contenuti web;
• processo renderer, quello che elabora le pagine: fino a 8.000 dollari per scritture in memoria e use-after-free;
• sandbox di V8: compenso fisso di 5.000 dollari;
• errori logici di V8: 4.000 dollari.

Fuori dalla sicurezza della memoria:

• 2.000 dollari fissi per le vulnerabilità di gravità media, se il report contiene una correzione o porta direttamente a individuarla;
• fino a 20.000 dollari per le fughe dalla sandbox che non sfruttano bug di memoria (quelle ad alto impatto, secondo Help Net Security).

Torna inoltre il bonus di 2.000 dollari per i fuzzer, destinato a chi sviluppa e contribuisce fuzzer nuovi. Secondo Help Net Security le modalità di invio saranno pubblicate nelle FAQ del Chrome VRP insieme al team Chrome Fuzzing, e Google prevede premi discrezionali di fine anno (più segnalazioni, miglior report, miglior bug).

Le regole si applicano subito: i report inviati dopo il 30 aprile 2026 e ancora in valutazione saranno pagati con le nuove tariffe, come riportano entrambe le fonti.

Perché contano processo e sandbox

La scala dei compensi segue l’architettura di Chrome. Il renderer esegue i contenuti web in un processo isolato e con pochi privilegi: un bug di memoria lì è grave, ma da solo resta confinato. I processi browser, rete e GPU lavorano con più privilegi, quindi un difetto sfruttabile da una pagina web è più vicino alla compromissione del sistema. La sandbox di V8 è una barriera ulteriore dentro il renderer, pensata per contenere gli effetti dei bug del motore JavaScript.

Le fonti non descrivono attacchi in corso. Nelle catene reali, però, queste classi di difetti sono quelle che servono alla compromissione durante la navigazione (MITRE ATT&CK T1189, Drive-by Compromise) e all’esecuzione di codice sul client (T1203): pagare di più chi le trova, e chi porta anche la correzione, serve a farle chiudere prima.

Impatto per le aziende europee e italiane

Per chi gestisce postazioni non cambia nulla nell’immediato: non ci sono patch nuove. Conta la direzione: Google premia di più i bug che aggirano l’isolamento e i report che arrivano con la correzione, cioè ciò che accorcia il tempo tra scoperta e aggiornamento. Il browser resta uno dei software più esposti in azienda, e il suo ciclo di aggiornamento va gestito come quello del sistema operativo.

Per i soggetti NIS2 la gestione delle vulnerabilità e degli aggiornamenti fa parte delle misure di gestione del rischio; chi produce software soggetto al Cyber Resilience Act dovrà inoltre avere una politica di divulgazione coordinata delle vulnerabilità. Le scelte di Google sono un riferimento utile anche per chi gestisce un proprio canale di segnalazione.

Cosa fare subito

1. Lascia attivo l’aggiornamento automatico di Chrome e degli altri browser basati su Chromium, e controlla con le policy di gestione che nessuna postazione lo abbia disattivato.
2. Verifica in inventario la versione installata e le macchine con il riavvio del browser in sospeso: l’aggiornamento si applica solo alla riapertura.
3. Non disattivare la sandbox (per esempio con l’opzione --no-sandbox in chioschi, automazioni o applicazioni incorporate): è la barriera che rende più costose le catene di attacco.
4. Se gestisci un programma di segnalazione, premia i report con prove riproducibili e una correzione proposta, come ora fa Google, e misura il tempo che serve a verificarli.

Come aiuta ARXDOME

ARX Shield mostra le vulnerabilità aperte per macchina e per pacchetto, con la loro età e quelle già sfruttate dagli attaccanti in evidenza: aiuta a trovare le postazioni con un browser rimasto indietro. ARX Sentry raccoglie l’inventario di computer e server, per sapere quali versioni sono davvero installate.

Ultimo aggiornamento: 14 ottobre 2026