A Chrome bug hunter was wrongly given edit rights on her own Chromium bug report and, as a joke, raised the reward field from $1,000 to $1,333,337. Google never awarded or paid that sum, but within a day AI search summaries were telling people she had become a millionaire.
What happened
Lyra Rebane is a browser security researcher credited with 14 Chrome CVEs. On 7 November 2026 she changed the vrp-reward value on one of her old Chromium bug reports from 1000 to 1333337 and marked the issue as fixed. She then posted on X that her vulnerability had earned the biggest award in the history of Google’s Vulnerability Reward Program (VRP). A follow-up video of her making the edit was the punchline.
Shortly after midnight she added a clarification. The screenshot was genuine, she had been given edit access by mistake, and Google had neither assigned nor agreed to pay the money. The issue history she later published shows a Google account removing her as verifier and putting the reward back to $1,000 in the early hours of 8 November.
The bounty itself was never real. What happened next is the interesting part. In a blog post on 11 November titled “How I accidentally became a millionaire”, Rebane describes how the joke turned into “fact”. An AI-written Community Note on X got the details wrong, claiming she had doctored the screenshot. After she complained, the note vanished. An automated AI news roundup, Daily Vibe Casting, then reported the payout as a genuine record. Google’s AI Overview went further and told searchers she had become a millionaire. Rebane says ChatGPT and Kagi Assistant repeated the story too. Her own verdict is blunt: “I am not a millionaire. I have never been one.”
The error is still spreading. On 12 November, a day after her blog went up, the aggregator LavX News ran a story describing the $1,333,337 as a payment Google had made, and it cited her debunking post as its source.
The technical picture
Two things failed: access control in a bounty programme’s own tooling, and automated systems trusting one unverified post.
The underlying report dates from 2022. Rebane found a logic bug in Chromium’s Background Fetch handling that could let a malicious page keep code running and turn visitors’ browsers into a botnet. As BleepingComputer reported in May, Google accepted the bug in December 2022, marked it fixed through the Chrome VRP in February 2026 and paid an automated $1,000 award. Its tracker then automatically lifted the access restrictions on 20 May, after the issue had been closed for more than 14 weeks. Rebane found the exploit still worked, so the report was made private again for a proper fix.
During that second round of verification, Rebane was assigned as the verifier on the issue, a role she says external reporters are not meant to hold. In Google’s issue tracker, a reporter can view and comment on an issue. Status, severity and the reward field are normally edited only by assignees, verifiers and collaborators. Setting the reward is the job of Google’s VRP panel. Being made verifier gave an outside researcher staff-level edit rights, including on the field that records her own payout. Before she touched the reward, a stray click briefly reassigned the issue to a bot account, showing how easily such a role changes workflow state by accident.
Rebane says Google did not assign the reward and will not pay it, and nothing in her account suggests any money moved. The reward field is still the public record of the award, though, and anyone reading the ticket or a screenshot of it treats that value as authoritative.
Why it matters for UK organisations
Many UK organisations now run vulnerability disclosure programmes, from government departments on HackerOne to banks and SaaS firms. Most share one ticketing workflow between external reporters, triagers, engineers and finance. If a status flag or reward value in that workflow drives a real decision, it is a control and needs least-privilege treatment.
The second lesson applies to everyone. AI systems turned one viral post into confident fact within hours and kept repeating it after the author corrected it. Attackers can use the same pattern, pushing a fake advisory or invented vendor breach into AI summaries that staff and even security teams then quote back.
Expert view
In my experience, tracker permissions are among the least reviewed parts of any security programme. When we test service management platforms, we often find that a third party pulled into a workflow role keeps it long after the task is done. Roles like “verifier” sound harmless but can carry edit rights nobody meant to hand to outsiders. Here, at least, the person who got the access showed it off openly instead of quietly abusing it.
The disclosure angle matters too. Rebane’s original bug was reported in 2022, closed too early and briefly exposed by automation. Shaky processes like that push good-faith researchers towards public disclosure. The UK government has promised, but not yet enacted, a statutory defence for such research under the Computer Misuse Act, so a well-run programme is one of the few assurances organisations can offer.
As for the AI angle, I would treat any AI summary of a security event as unverified until it is traced to a primary source. Here the primary source says the opposite of what several AI tools reported.
What to do now
- Audit roles on your VDP and bug bounty tickets. List every field an external reporter can edit, directly or through an assigned role such as verifier, reviewer or collaborator. Remove the access once each task is complete. This maps to the Cyber Essentials user access control requirement for least privilege.
- Separate the record from the payment. Rewards, severity and closure should be confirmed through a step that the reporter cannot reach, with an audit trail. Make sure payment systems never read a reward value directly from a ticket field that has not been approved.
- Check automated visibility rules. Rules that publish or unrestrict issues after a set period should check that a fix has actually shipped, not just that a ticket says “fixed”.
- Alert on sensitive field changes. Send changes to reward, severity and disclosure-status fields made by non-staff accounts to your security team in real time.
- Set a verification rule for AI summaries. Brief comms, threat intelligence and incident teams that AI overviews and auto-generated news are leads, not facts. Before acting on or repeating a claim, confirm it against the vendor, the researcher or an official body such as the NCSC.
- Correct false claims quickly. If a false claim about your organisation spreads, publish a dated, sourced correction where automated systems will find it. In Rebane’s case, a later, accurate Community Note is what search results eventually picked up.
Bottom line
Google did not pay a $1,333,337 bounty. A researcher was given edit access she should never have had, used it for a joke and owned up straight away. The access-control fix is cheap. The harder problem is that AI systems turned a correctable tweet into “fact” within a day, and organisations should plan for false claims about them spreading the same way.
Sources
- Lyra Rebane: How I accidentally became a millionaire
- BleepingComputer: Google accidentally exposed details of unfixed Chromium flaw
- LavX News: Lyra Rebane reports $1.33 million Google Chrome bounty (an example of the false claim)
- Daily Vibe Casting: Google awarded a record Chrome bug bounty (an example of the false claim)
