Chrome's bounty base is up 4x to $2,000, and Google's blog and rules page disagree on renderer rewards

Four times April's base, and still below February's baselines

On 13 October 2026 Google said it was "increasing the base reward amount for memory corruption vulnerabilities to $2,000 (a 4x increase)" in the Chrome Vulnerability Reward Program. Against April the 4x is exact: the rules page after the 30 April cuts gave a base of $500 (SecurityWeek reported the same figure on 1 May), and $2,000 divided by $500 is 4.0 (derived). Against February it is a different picture. Google's Chrome rules page, as archived on 14 February 2026, had no base amount at all. Its memory-corruption table had a column called Baseline, with ceilings of up to $7,000 for a sandboxed renderer, up to $10,000 for the GPU and network processes and up to $25,000 for a non-sandboxed process. A $2,000 base is 28.6, 20.0 and 8.0 per cent of those ceilings (derived).

That comparison reads the old Baseline column and the new base as the nearest equivalents. That is this briefing's inference, not Google's statement, and it is the only like-for-like reading the pages allow, because Google rebuilt the table in April. It also tests a number the press has used. SecurityWeek wrote on 1 May and again on 13 October that researchers noted some rewards became "10 times smaller". A 10 times cut from an earlier base of $5,000 would make $2,000 exactly 40 per cent of it, but no cell on the February page is $5,000. On Google's own pages the April cuts to the base-like cells were 14.0 to 50.0 times (derived).

The change took effect on 13 October, 166 days after the 30 April post that cut Chrome rewards (derived). Google says reports submitted after 30 April that are still in its evaluation queue "will be evaluated and rewarded under the new payout rules".

What none of this establishes: how many reports Google receives, how many are AI-generated, how many are accepted, what it pays on average, whether researchers moved to other buyers, what Google pays against what outside buyers pay, or whether the new prices change when and how people disclose. Google's pages give no figure for any of them. The nearest thing to a volume statement is one sentence in a 30 July post: by March 2026 Google had received more bug reports than in the whole of 2025, with no count for either year. Google's interest, in one sentence: it sets the price of reports about its own product, decides each reward at its panel's sole discretion, and publishes only the numbers it chooses to publish.

This briefing reads Google's announcement, its Chrome rules page in three states (14 February and 16 September from the Internet Archive, and live on 14 October), the FAQ, the 30 April post and the 1 October open-source notice. SecurityWeek (13 October) and Help Net Security (14 October) were read as pointers only. Both match Google's post on every dollar figure they give. Neither says that Google's rules page, read at about 06:35 BST on 14 October, disagrees with the post on several rows. All times are BST and the first fetch was at 06:33.

Three rate cards, cell by cell, each cited to a Google page

The sources are lettered. A is Google's Chrome rules page as archived on 14 February 2026, before the April change. B is the same page archived on 16 September 2026; the 16 August copy has the same reward tables, and the page's own changelog dates the change to April. The Internet Archive index lists no capture of the page's content between 14 February and 16 August, so the April figures are read from August and September, not from May. C is Google's 13 October post. D is the live rules page, read at about 06:35 BST on 14 October.

Table 1. Chrome VRP memory-safety rewards on three dates. A, B, C and D are defined in the text above. February cells are ceilings (Up to). Not published means the page read gives no such row or figure.

Memory-safety category	14 Feb, before April (A)	April (B)	13 Oct (C, and D where it differs)
Base amount	No base. Lowest column, Baseline: up to $7,000 renderer, $10,000 GPU and network, $25,000 browser	$500	$2,000
Browser, network, GPU, from web contents: reads and crashes	Not published as a row	$1,000	Up to $4,000
Same: writes and use-after-free	Not published as a row. Nearest, memory corruption: up to $15,000 GPU and network, $35,000 browser	$2,500	Up to $10,000
Same: controlled read, special flag	Not published	$2,500	Up to $10,000
Same: controlled write, special flag	Controlled write: up to $70,000 GPU and network, $90,000 browser	$5,000	Up to $20,000
Renderer: reads and crashes	Baseline: up to $7,000	$500	$3,000 (C). $2,000 (D)
Renderer: writes and use-after-free	Nearest, memory corruption: up to $10,000. Controlled write: up to $50,000	$1,000	$8,000 (C). $4,000 (D)
V8 logic bugs	Not a row. A V8 report without a write or code execution gets Baseline only	$500	$4,000 (C). $2,000 (D)
V8 sandbox bypass	$5,000, or $20,000 for a controlled write outside the sandbox	$1,000, or $2,500 for a controlled write	Flat $5,000 (C). $4,000 (D)
Other sandboxed processes: reads, writes	Not published	$500, $500	$2,000, $3,000 (C). $2,000, $2,000 (D)

Table 2. Everything else Google prices in the Chrome VRP, on the same three dates. Rows the 13 October post does not mention are marked so, and their figure is read from the rules page (D).

Category	14 Feb (A)	April (B)	13 Oct (C, D)
Medium severity, not memory safety, with an identified fix	Not published as a rate. Scope: any security bug	Not published. Scope sentence: High or Critical	Flat $2,000
Sandbox escape, not memory safety	Not a separate row. Inside the top memory row: up to $25,000 to $250,000 by report quality	Not published	Up to $20,000 (C). Up to $10,000 (D)
Fuzzer bonus	Plus $2,000 renderer, plus $3,000 GPU, up to plus $5,000 browser	A multiplier, plus 1 or plus 2: $500 or $1,000 at the $500 base (derived)	$2,000 for any memory-safety bug a submitted fuzzer finds
Full chain exploit bonus	Not on the page (removed in 2024)	$250,000 from web contents, $200,000 with MojoJS, four awards in 2026	Unchanged. Three of four awarded by 13 Oct (D)
UXSS or site isolation bypass	Up to $30,000	Up to $10,000	Not in C. Up to $10,000 (D)
User information disclosure	Up to $25,000	Up to $5,000	Not in C. Up to $5,000 (D)
Local privilege escalation	Up to $15,000	Up to $5,000	Not in C. Up to $5,000 (D)
Web platform privilege escalation	Up to $7,000	Up to $5,000	Not in C. Up to $5,000 (D)
Security UI spoofing (April: omnibox URL spoofing)	Up to $10,000	Up to $5,000	Not in C. Up to $5,000 (D)
Report below the baseline standard	Reduced reward, no figure (March changelog: $5,000 ceiling)	Limited to the base: $500	$1,000 at the panel's discretion (D only)

The ratios, and what they do and do not say

Table 3 divides Google's figures by one another. The pairs are the nearest like-for-like by Google's own wording and are this briefing's inference. February figures are ceilings and April and October figures are table amounts, so no ratio here is a ratio of payments.

Table 3. Ratios between the figures in Tables 1 and 2 (derived). Lower means the later figure is smaller. Share is the 13 October figure as a percentage of the February cap.

Pair compared	February cap to April	April to 13 Oct	13 Oct share of February
Base against renderer Baseline cap ($7,000)	14.0x lower	4.0x higher	28.6%
Base against GPU and network Baseline cap ($10,000)	20.0x lower	4.0x higher	20.0%
Base against browser Baseline cap ($25,000)	50.0x lower	4.0x higher	8.0%
Controlled write, browser, web contents ($90,000 cap)	18.0x lower	4.0x higher	22.2%
Controlled write, GPU or network ($70,000 cap)	14.0x lower	4.0x higher	28.6%
Writes and use-after-free, browser (memory corruption cap $35,000)	14.0x lower	4.0x higher	28.6%
V8 sandbox, memory corruption outside it ($5,000)	5.0x lower	5.0x higher (C). 4.0x (D)	100.0% (C). 80.0% (D)
V8 sandbox, controlled write outside it ($20,000)	8.0x lower	2.0x higher (C)	25.0%
Renderer writes and use-after-free (memory corruption cap $10,000)	10.0x lower	8.0x higher (C). 4.0x (D)	80.0% (C). 40.0% (D)

Three things stand out. First, every browser, network and GPU cell moved by exactly 4.0, so October scaled the ladder and did not re-price it. The spread from the cheapest to the dearest memory-safety cell is 10.0 now ($20,000 against $2,000) and was 10.0 in April ($5,000 against $500), against 35.7 for the February ceilings ($250,000 against $7,000), all derived. April compressed the ladder from 35.7 to 10.0 and October kept it there (the first figure compares ceilings, the others table amounts).

Second, the renderer cells in Google's blog table are not a uniform 4.0 times April. They are 6.0, 8.0, 8.0 and 5.0 times (derived), whereas on the rules page every renderer cell is 4.0 times April. Third, the one place the blog's figure meets February is the lowest V8 sandbox tier at $5,000. The top V8 sandbox tier is a quarter of its old value. At the very top the $250,000 full chain bonus is unchanged, is capped at four awards in 2026, and the rules page says three had been made by 13 October (a September copy said one, as of 1 September). It is 125 times the new base and 12.5 times the dearest single cell (derived).

The rows October leaves alone were cut in April and stay cut. UXSS or site isolation bypass is up to $10,000 against $30,000 in February, user information disclosure up to $5,000 against $25,000, and local privilege escalation up to $5,000 against $15,000. The old caps are 3.0, 5.0 and 3.0 times the current ones (derived). So "partially reverses" describes the memory-safety table and the new medium-severity rate, not the whole programme.

Google's blog and rules page give different numbers for the renderer

Google's post says: "The new categories and rule changes will be updated on our VRP Rules page." At about 06:35 BST on 14 October the rules page's changelog already carried a 2026-10 entry, its base was $2,000, and its browser, network and GPU row matched the post. Other rows did not. The page was read twice, in a browser and from the site's own content feed, with the same result.

Table 4. Rows where Google's 13 October post (C) and its rules page as read on 14 October (D) differ. The browser, network and GPU row from web contents matches in all four columns: $4,000, $10,000, $10,000 and $20,000.

Row	Blog post, 13 Oct (C)	Rules page, 14 Oct (D)
Renderer: reads and crashes	$3,000	$2,000
Renderer: writes and use-after-free	$8,000	$4,000
Renderer: V8 logic	$4,000	$2,000
Renderer: V8 sandbox	Flat $5,000	$4,000
Other sandboxed: writes	$3,000	$2,000
Sandbox escape, not memory safety	Up to $20,000	Up to $10,000

The rules page also says the decision whether to grant a reward, and its amount, "is always determined at the sole discretion of the reward panel", so neither table is a promise of payment. SecurityWeek and Help Net Security follow the post, and Help Net Security's headline gives "up to $20,000 for sandbox escapes", a figure the rules page did not carry. Which page is right is not stated. A researcher, or a UK organisation estimating what its suppliers' researchers can earn, should treat the post as the intent, the rules page as the working text, and the gap as open until Google changes a page. The rules page was read again at 06:58 BST on 14 October and was unchanged.

Names doing the work of a price

A price is a number somebody pays. Several labels in this story stand in for one, and each hides a narrower fact.

Table 5. Labels in the announcement and the coverage, what a reader hears, and what the pages say. Quotes are from Google's post and rules page unless marked.

Label	What a reader hears	What the pages say
Quadrupling base rates (Google's heading)	Rewards are four times higher	The multiplicand moved from $500 to $2,000. Browser, network and GPU cells moved 4.0 times each. Renderer cells moved 4.0 times on the rules page and 5.0 to 8.0 times on the blog table (derived). February had no base.
Partially reverses (SecurityWeek's headline)	The cuts are being undone	The base is 8.0 to 28.6 per cent of the February Baseline caps. Only the lowest V8 sandbox tier is back at its February figure. The other classes are unchanged from April.
Up to $20,000	Chrome pays $20,000 for a bug	One cell: a controlled write shown from web contents in the browser, network or GPU process with the special flag mode. Reads and crashes in those rows are up to $4,000, and the cheapest cells are $2,000.
Base, and Baseline	The same floor	February's Baseline was a report-quality column with ceilings. Today's base is the multiplicand. Moderately mitigated issues are "limited to the base reward amount".
Fuzzer bonus returns	A bonus restored	The April page still had a fuzzer bonus, as a multiplier worth $500 or $1,000 (derived), and was not accepting ClusterFuzz fuzzers. Now it is $2,000 and ClusterFuzz fuzzers are accepted.
Reward programme	An entitlement	"An experimental and discretionary rewards program" that Google "can cancel ... at any time".
Year-end awards	More money	No amount and no criteria. Google gives three example titles.
Medium severity: $2,000	Any medium bug pays	Only non-memory-safety medium issues, "provided the report includes or directly leads to an identified fix".

The fuzzer row has a condition worth reading. The FAQ asks a fuzzer's author to first submit three valid security reports that "did not dupe against our internal fuzzers or AI tools". The same FAQ says a bug found by Google's internal tools within seven days of a report counts as already known and earns nothing. So a report can lose to Google's own tooling within seven days of submission. The pages do not say how many have.

Stated and not stated: what the record gives, line by line

Not stated means not found in any Google page read, in full, for this briefing. It does not mean the information does not exist.

Table 6. What Google's pages state and what they do not, on the questions that decide whether a price is sensible.

The question	Stated	Not stated
Why was the base cut in April?	The 30 April post: AI "has made it effortless to produce lengthy, detailed write-ups". The most effective report is "concise, containing only a reproducer and the necessary artifacts". Special bonuses retired because AI "has made demonstrating these techniques almost routine".	Any count of reports, any share by source, any measure of the triage load.
How big was the volume?	The 30 July post: "by March, the shift was apparent: we received more bug reports than we had in the entirety of 2025". Triage once took "5 to 30 or more minutes" a report.	The number of reports in 2025 or 2026, and how many were AI-generated, valid, duplicates or accepted.
Why change again in October?	To "reward more types of deep security research" and "recognize high-value fixes across more severity tiers". Google is "looking to learn where these efforts can be further strengthened".	Whether volume fell, what was learned, any figure.
What does Google pay in total?	Chrome VRP 2025: $3,716,750 to "over 100 different reporters" ([11 March 2026 review](https://bughunters.google.com/blog/google-vrps-in-review-2025)). 2026 aggregate rewards "expected to increase" (30 April).	2026 to date, the number of rewards, the average, the median, the share under $2,000.
What was paid lately?	Chrome 155's notes of 6 October print 16 dollar amounts totalling $33,000 (below).	What TBD and N/A mean, and which table cell each amount came from.
What do other buyers pay?	The FAQ says reports privately disclosed to third parties for purposes other than fixing the bug "will not qualify for a reward".	Any outside price. This briefing read none and makes no comparison.
Did researchers leave?	Nothing.	Whether any left, or whether disclosure behaviour changed. No source read says.
Has October worked?	It took effect on 13 October.	Any measure of effect. The change is a day old.

The only payments Google prints beside its fixes are in the bounty field of the release notes. The 6 October notes for Chrome 155 list 247 fixes. Sixteen carry a dollar amount: nine of $2,000, four of $1,000, two of $3,000 and one of $5,000, a total of $33,000 with a mean of $2,062.50 and a median of $2,000 (derived). Forty-one say TBD and 190 say N/A, of which 185 are credited to Google, 74.9 per cent of the 247 (derived). The notes define neither marker. Of the 41 TBD entries, 37 were reported after 30 April, so up to 37 may be priced under the new rules, if TBD means a decision is pending (inference). The 13 October notes for 155.0.8059.79 and .80 list 37 fixes: 7 Critical, 29 High and 1 Medium, 12 credited to Google, one dollar amount ($1,000), 8 TBD, all reported after 30 April, and 28 N/A (derived). The earlier briefing on Chrome 155's 247 fixes goes through that list in detail.

Five changes in 208 days, in both directions

Google's reward rules moved five times between 19 March and 13 October 2026, a span of 208 days, one of the five without a day given (derived). The Chrome cut and the Chrome rise are 166 days apart. The open-source closure of 1 October is covered in an earlier briefing; the table puts it beside the Chrome changes.

Table 7. Dated changes to Google reward rules, from Google's own posts and rules pages. SecurityWeek's description of the 1 October reason is AI-generated reports; Google's own wording is automated submissions.

Date, 2026	Programme and change	Reason Google gives
19 March	Open-source VRP: stricter proof and project tiers	"A massive surge in AI-generated reports"
April, no day	Open-source VRP: no rewards or credit for product vulnerabilities and other security issues on the two lower tiers	The same post, updated
30 April	Chrome: base cut to $500, two bonuses retired. Android: top ceilings listed at $1,500,000 and $750,000	AI "has made demonstrating these techniques almost routine"; reports should be "concise"
1 October	Open-source VRP: no new product-vulnerability reports; update promised in Q1 2027	"A significant rise in automated submissions, the vast majority of which are not valid" (X post)
13 October	Chrome: base to $2,000, new medium-severity and sandbox-escape rates, fuzzer bonus	"Reward more types of deep security research"

The direction depends on the product. The same 30 April post that cut Chrome's base listed Android's top ceilings at $1,500,000 and $750,000, which SecurityWeek reports were rises. It also says Google will "continue to evaluate and refine our VRPs to ensure they remain the industry standard for security research". That reads as notice that prices will keep moving (inference).

UK: what the NCSC, the Home Office and Cyber Essentials say

Nothing below is about Google's prices. It is what the UK pages read for this briefing say about running a disclosure programme, about the law that surrounds security research, and about how fast a browser update has to land. Each row is what the page says and what it does not.

Table 8. UK sources read on 14 October 2026. Page dates are as shown on each page.

Source	What the page says	What it does not say
[NCSC Vulnerability Disclosure Toolkit](https://www.ncsc.gov.uk/information/vulnerability-disclosure-toolkit) (reviewed 7 Nov 2024) and [v2 PDF](https://www.ncsc.gov.uk/files/NCSC-Vulnerability-disclosure-Toolkit-v2.pdf)	A process needs a contact route, a policy and security.txt. Respond promptly, avoid forcing a non-disclosure agreement, validate first, triage consistently. The example policy says "we do not offer monetary rewards" and promises a response in 5 working days and a triage aim of 10.	Whether or how to pay, any price, anything on AI-generated reports.
[NCSC annual review 2023, Technology](https://www.ncsc.gov.uk/collection/annual-review-2023/technology)	Some vendors "operate a bug bounty programme"; NCSC bounty payments go to charity. A Chrome disclosure with CVE-2023-1530 was awarded $7,000 that Google doubled to $14,000 when donated. (The 14 February rules page offered to double donated rewards; the later copies read do not.)	What an organisation running a programme should pay.
[NCSC blog on AI safeguard programmes](https://www.ncsc.gov.uk/blog-post/from-bugs-to-bypasses-adapting-vulnerability-disclosure-for-ai-safeguards), 2 Sep 2025	"There are significant overheads associated with triaging and managing reports." "Companies don't necessarily need to provide a financial incentive to get many of the benefits." Launch after internal reviews "to avoid swamping developers with low impact reports". Beware "perverse incentives".	It is about AI safeguard bypasses, not software flaws. Reading it across to a bounty is this briefing's inference.
[Computer Misuse Act 1990, section 1](https://www.legislation.gov.uk/ukpga/1990/18/section/1)	An offence to cause a computer to perform a function with intent to secure access to a program or data, where the access is unauthorised and the person knows it. Up to two years on indictment.	No defence for research or reporting appears in the section.
[Home Office, Review of the Computer Misuse Act](https://www.gov.uk/government/consultations/review-of-the-computer-misuse-act-1990), response of 14 Nov 2023 ([PDF](https://assets.publishing.service.gov.uk/media/655390ca50475b000dc5b5b9/CMA_Consultation_Response.pdf))	"A number of respondents expressed a view that the Computer Misuse Act (CMA) currently prevents consumer groups, cyber security professionals and researchers from undertaking legitimate public interest activity". Defences are listed under areas for further consideration.	That a defence will be legislated. Its next-steps section covers three other proposals. No later gov.uk page on a defence was found; whether anything has changed since is not established.
[Cyber Essentials requirements v3.3](https://www.ncsc.gov.uk/files/cyber-essentials-requirements-for-it-infrastructure-v3-3.pdf) (April 2026)	Software updated "within 14 days" of release where the vendor calls the fixes critical or high risk, the CVSS v3 base score is 7 or above, or no detail is given. A mixed update with any critical or high fix "must be installed within 14 days". Automatic updates where possible.	Anything on browsers specifically, or on bounty prices.
[NCSC update by default](https://www.ncsc.gov.uk/collection/vulnerability-management/guidance/policy-update-by-default) (v2.1, reviewed 1 May 2026)	Best practice: operating system and applications updated automatically as soon as published, within 7 days; internet-facing software within 5; internal or air-gapped within 14. When exploitation is rife the timelines "are too long".	These are best-practice timescales, not Cyber Essentials conditions.
[NCSC on a vulnerability patch wave](https://www.ncsc.gov.uk/blogs/prepare-for-vulnerability-patch-wave) (1 May 2026)	Prepare "to deploy software security updates quickly, more frequently, and at scale" and enable automatic updates where available.	Any view on Chrome or on Google's bounty.

Chrome's pace. Chrome has shipped a milestone every two weeks since Chrome 153 on 8 September, as Google announced. Google's 30 July post adds weekly security updates and a pilot of two security releases a week. The 6 October stable build 155.0.8059.39 and .40 lists 247 fixes, 4 of them Critical. The 13 October build 155.0.8059.79 and .80 lists 37, 7 Critical and 29 High. The Extended Stable build of 13 October, 152.0.7977.167, lists 28 fixes: 5 Critical and 23 High (derived counts). Neither October stable post read carries a sentence saying an exploit exists in the wild. Counting from 13 October, the NCSC's 7 days ends on 20 October and Cyber Essentials' 14 days on 27 October (derived). Google's schedule plans Chrome 156 stable for 20 October and a security refresh on 27 October; planned dates can move.

The law. Section 1 asks whether access was unauthorised. A written scope in a disclosure policy is the owner's statement of what it authorises, and the NCSC toolkit's policy elements include what is in and out of scope. That is an inference. The Home Office page does not say a policy protects a tester and no defence appears in the section, so a programme should not promise one. Google's own rule is the plain version: "your testing must not violate any law".

What a UK organisation running a programme should take from Google's changes. There are three lessons, each tied to a page above.

First, triage capacity before price. Google's 30 July post says its VRP change was meant to focus researchers on reports "additive to what we are finding internally, and easily ingestible by our newly automated processing pipelines". That post describes automated triage that filters, reproduces, enriches and assigns reports, and estimates it saves "hundreds of hours of developer time per month". A smaller organisation has no such pipeline, the NCSC's example promises a triage aim of 10 working days, and the NCSC's blog warns of "significant overheads". Price sets how many reports arrive. Capacity sets how many you can read.

Second, a policy for AI-generated and agent-assisted reports. Google's rules page now opens with "Reporters using agents should include Security For Agents and take account of security.md files", values "brief reports", and treats "over-long reports that make spurious claims about impact" as below baseline. Until the 1 October closure its open-source rules asked for an OSS-Fuzz reproduction or a merged patch for some tiers. None of these rules tests who or what wrote the report. They ask for a reproducer, versions and a minimised proof of concept. Write evidence rules, not authorship rules.

Third, fix-linked rewards. The new $2,000 medium-severity rate is paid only if the report "includes or directly leads to an identified fix", and memory-safety bugs are "rewarded only if they reproduce on our infrastructure". Money follows evidence the owner can check.

What to do, in order

The question to answer before the next price change

Google cut its Chrome base to $500 on 30 April and raised it to $2,000 on 13 October. Between those dates, in the pages read for this briefing, it published no count of reports received, reports valid or reports accepted. If your own programme's price moved tomorrow, which numbers would you point to as the reason?

Key facts