Chrome VRP: Google raises rewards, but only partly

Google has raised the rewards of the Chrome Vulnerability Reward Program (Chrome VRP), the programme that pays researchers who report vulnerabilities in the browser. The announcement came on Tuesday 13 October 2026 and was reported by SecurityWeek and Help Net Security. The changes mainly concern memory corruption flaws and sandbox escapes.

This is Google’s second change to its reward programmes in a few weeks: in early October ARX News covered the suspension of rewards for product vulnerabilities in the OSS VRP, which had been flooded with invalid automated reports. There are no CVEs or updates tied to this news.

What happened

According to SecurityWeek, in April 2026 Google significantly lowered standard payouts for some Chrome vulnerabilities, to focus the programme on actionable reports; some researchers noted that rewards had become ten times smaller. The base for memory safety issues dropped to $500, with multipliers based on how reachable the flaw is and how exploitable. The outlet links these adjustments to the way artificial intelligence is changing the pace and profile of vulnerability discovery.

The base now rises to $2,000, four times as much: both sources confirm this. SecurityWeek notes that, despite the increase, the new rates remain well below those in force before the April overhaul; Help Net Security does not mention the cuts and presents the news simply as a programme update.

The new rates

For memory corruption (figures agree across both sources unless stated otherwise):

• browser, network and GPU processes: up to $20,000. Only Help Net Security details the scale: up to $4,000 for reads and crashes, up to $10,000 for writes, use-after-free and controlled reads, up to $20,000 for controlled memory writes demonstrated from web content;
• renderer process, the one that handles web pages: up to $8,000 for memory writes and use-after-free;
• V8 sandbox: a flat $5,000;
• V8 logic bugs: $4,000.

Outside memory safety:

• a flat $2,000 for medium-severity vulnerabilities, if the report includes a fix or directly leads to one;
• up to $20,000 for sandbox escapes that do not rely on memory bugs (high-impact ones, according to Help Net Security).

The $2,000 fuzzer bonus is also back, for researchers who develop and contribute novel fuzzers. According to Help Net Security, submission guidelines will be published in the Chrome VRP FAQ together with the Chrome Fuzzing team, and Google plans discretionary year-end awards (most findings, best report, best bug).

The rules apply immediately: reports submitted after 30 April 2026 and still under evaluation will be paid under the new rates, as both sources report.

Why process and sandbox matter

The reward scale follows Chrome’s architecture. The renderer runs web content in an isolated, low-privilege process: a memory bug there is serious, but on its own it stays contained. The browser, network and GPU processes run with more privileges, so a flaw exploitable from a web page is closer to compromising the system. The V8 sandbox is an additional barrier inside the renderer, designed to contain the effects of bugs in the JavaScript engine.

The sources do not describe any ongoing attacks. In real attack chains, however, these classes of flaws are the ones used for compromise while browsing (MITRE ATT&CK T1189, Drive-by Compromise) and for code execution on the client (T1203): paying more to those who find them, and to those who also bring the fix, is meant to get them closed sooner.

Impact for European and Italian companies

For those managing workstations nothing changes right away: there are no new patches. What matters is the direction: Google rewards bugs that bypass isolation and reports that come with a fix more generously, in other words what shortens the time between discovery and update. The browser remains one of the most exposed pieces of software in a company, and its update cycle should be managed like that of the operating system.

For NIS2 entities, vulnerability and update management is part of the required risk management measures; manufacturers of software covered by the Cyber Resilience Act will also need a coordinated vulnerability disclosure policy. Google’s choices are a useful reference for anyone running their own reporting channel.

What to do now

1. Keep automatic updates on for Chrome and other Chromium-based browsers, and use management policies to check that no workstation has disabled them.
2. Check the installed version in your inventory and the machines with a pending browser restart: the update only applies when the browser is relaunched.
3. Do not disable the sandbox (for example with the --no-sandbox option in kiosks, automation or embedded applications): it is the barrier that makes attack chains more expensive.
4. If you run a reporting programme, reward reports with reproducible evidence and a proposed fix, as Google now does, and measure how long it takes to verify them.

How ARXDOME helps

ARX Shield shows open vulnerabilities by machine and by package, with their age and with those already exploited by attackers highlighted: it helps find workstations whose browser has fallen behind. ARX Sentry collects the inventory of computers and servers, so you know which versions are actually installed.

Last updated: 14 October 2026