Bug bounties are changing faster right now than at any point in their thirty-year history. On one side, the rise of AI-assisted research has flooded many programs with low-signal ‘slop.' On the other, frontier models are starting to produce validated, reproducible, exploitable vulnerabilities at machine speed. Both trends are accelerating, and neither is going to reverse.
That shift reframes what a bug bounty program is for. It’s no longer just a channel for receiving external findings. It’s a live test of whether your triage, engineering, and response machinery can keep up with a vulnerability discovery process that has changed shape underneath everyone running one.
This piece is about how we see that change playing out, what it demands of bug bounty programs, and how ours has evolved to meet it. We’ll also cover our 2025 results — because 2025 happens to mark thirty years since the first recognizable bug bounty scheme, when Netscape invited researchers to find vulnerabilities in an early browser beta, and eight years since we launched our own public program.
AI is changing the shape of bug bounties
The signal you’re probably hearing right now is slop, a surge in low-effort, AI-assisted submissions clogging triage queues across the industry. That’s real, and it’s painful. But it’s also the smaller half of what’s happening. Underneath the noise, AI is starting to produce validated, exploitable findings at machine speed, and that capability is improving fast.
Two things can be true at once:
- Slop will grow (more automation, more submissions, more triage burden).
- Capabilities will improve (models will get better at reasoning across codebases, building exploit hypotheses, and finding non-obvious chains).
Both trajectories are accelerating, and neither is going to reverse. Before we get into how programs need to evolve, it’s worth grounding the conversation in what eight years of running ours has actually looked like, because the muscle memory programs build over time is a big part of what makes them resilient to a shift like this one.
How our program has evolved
We didn’t design our bug bounty program with the Mythos era in mind; nobody did. But eight years of running it, tuning it, and learning from it have left us better positioned for what’s coming than a program designed today and launched cold.
In the buginning…
We ran private bug bounty programs in 2015 and 2016, but launched our public program on Bugcrowd on December 14, 2017, alongside our vulnerability disclosure policy.
Since then, we’ve paid out for 1,343 vulnerabilities as of this writing (not quite 1,337!), out of 7,091 total submissions, with the rewards totalling $599,695.
Our reasons for launching the program were simple, and tie back directly to Secure by Design outcomes:
- We’ll never catch everything internally. Incentivizing external research increases coverage across products, configurations, and threat models we can’t fully replicate in-house.
- Safe harbor matters. Security improves faster when researchers can report in good faith, with clear rules of engagement. (Here is more on why that framing matters in practice.)
- Continuous, diverse evaluation. Bug bounties provide year-round scrutiny rather than ‘snapshot’ assessments.
- We learn faster. Dialogue with researchers is a form of applied training for engineers — especially when findings reveal systemic design lessons, not just one-off bugs.
From the outset, we knew the program would have drawbacks:
- Some hunters gravitate toward high-volume, low-hanging fruit. That can skew results toward lower-severity issues. Useful, but not always aligned to the risks we most want to eliminate.
- Disagreements happen (reproducibility, severity, scope). That’s part of the territory, and one reason we chose to run the program through a trusted third-party platform.
- Validation overhead is real. Duplicates, out-of-scope entries, false positives, and already-disclosed vulnerabilities all need filtering. The valid-to-invalid ratio has always been fairly low, something that has historically affected many programs, and AI has intensified that challenge dramatically. Daniel Stenberg’s frustration with AI slop at cURL is a useful reference point; he terminated that program’s monetary rewards completely in January 2026.
Recent results
In 2025, our bug bounty program continued with its reward structure of up to $80,000 (USD). Our special targets and corresponding rewards were as follows:
- Intercept X Endpoint (Windows): up to $80,000
- Sophos Central: up to $50,000
- Sophos Firewall: up to $50,000
- Premium Bounty Eligible targets: up to $8,000
- Catch-all targets: up to $5,000
Here’s a brief breakdown of our 2025 numbers:
- We awarded $59,400 for over 52 reports
- Approximately 420 researchers participated, from countries around the globe
- The average monthly reward was $6,000–$7,000, consistent with 2024
We also made a series of changes and improvements to our vulnerability reward programs and related initiatives:
- Updated the threshold for meeting the Firewall special target reward to improve transparency
- Completed a private Bugcrowd program on our Firewall Early Access Program introducing a new control plane architecture
- Started another private Bugcrowd program for the next major milestone of Sophos Taegis (XDR), which is running successfully
And here are some more detailed updates on selected targets:
Intercept X Endpoint (Windows) Special Target
Intercept X Endpoint (Windows) has continued with updated reward amounts and structure to incentivize deeper research. For example, the maximum reward for a single issue is $80,000 for demonstrating zero-click remote code execution (RCE).
We received seven reports of unique, valid security bugs in Intercept X Endpoint during 2025 and awarded $9,600 in total. The highest rewards of 2025 went to one researcher for three reports, with each report receiving $2,000. These reports were related to out-of-bounds read attacks.
Sophos Central Special Target
We have continued with this target, and each vulnerability category listed in the Sophos Central Special Target can be awarded a maximum payout of $50,000.
We received 13 reports of unique, valid security bugs in Sophos Central during 2025 and awarded $11,650 in total. The highest reward of 2025 was $5,500 for a report related to HTTP request smuggling.
Sophos Firewall Special Target
This target has existed for more than a year, and we continue to receive many interesting reports. We appreciate the researcher community for their support in making this product even more secure, as our teams are also learning from the confirmed reports. In 2025, we made some changes to this special target’s requirements — for details, please refer to the Sophos Firewall Special Target page.
We received 13 reports of unique, valid security bugs in Sophos Firewall during 2025 and awarded $21,500 in total. The highest reward of 2025 was $8,000 for a report related to pre-authentication SQL injection (SQLi).
The introduction of private programs deserves a note. Something we do, and we’d encourage any bug bounty participant to consider doing the same, is continually assess the scope and scale of our initiatives. We add new products, change parameters, and adjust rewards to reflect developments not just in our products and infrastructure, but also the context of our wider internal security efforts. This continual re-tuning is exactly the muscle programs need to exercise as the AI shift accelerates. One ‘health indicator’ we watch closely: over time, Firewall vulnerabilities have become increasingly complex to exploit, more niche issues, more chaining, suggesting baseline hardening is working and researchers have to work harder for meaningful impact.
Secure by Design in practice: lessons under pressure
One of the most important lessons we’ve learned is that you get the best outcomes when bug bounty is treated as part of a system, not a standalone inbox. The two Pacific Rim-adjacent stories below illustrate why — and why that discipline will matter more, not less, as AI changes the tempo of vulnerability research.
A ‘friends’ story: when collaboration works exactly as intended
Our Pacific Rim reporting tracked adversaries targeting our products and infrastructure, including the Asnarök attacks that exploited a previously unknown SQLi (CVE-2020-12271) leading to RCE on some firewall products. Shortly after we published related materials, we received a bug bounty submission from researchers at Code White, a Germany-based security company.
Their work is a great example of the best kind of ‘friend’ dynamic — researchers approaching a target with an attacker’s mindset, but choosing to operate transparently and responsibly. They were initially trying to build an RCE exploit for red team assessments, but instead found another SQLi (CVE-2020-15504) that could have been leveraged for RCE, and reported it through our program.
Their disclosure timeline (on their blog) highlights something we consider part of Secure by Design in practice — speed and clarity of response:
- 04.05.2020 – 22:48 UTC: Vulnerability reported to Sophos via Bugcrowd
- 04.05.2020 – 23:56 UTC: Sophos confirmed report receipt (just over one hour)
- 05.05.2020 – 12:23 UTC: Sophos reproduced the issue and began working on a fix
- 05.05.2020: First automatic hotfix rolled out by Sophos (same day)
- 16.05.2020: Researcher reported a possible bypass for the hotfix’s security measures
- 21.05.2020: Second hotfix released, disabling the pre-auth email quarantine release feature
- June 2020: Firmware 18.0 MR1-1 released with a built-in fix
- July 2020: Firmware 17.5 MR13 released with a built-in fix
- 13.07.2020: Blog post published in coordination with the vendor
From initial report to confirmed reproduction in under 13 hours, and a first hotfix the same day. That’s the kind of response cycle that reduces risk to customers and the ecosystem quickly and measurably. That is exactly the tempo the Mythos era will demand as table stakes.
A ‘frenemies’ story: when the ecosystem gets complicated
Pacific Rim also provided a harder lesson. On two occasions — Asnarök (2020) and Personal Panda (2022) — threat actors exploited zero-days in Sophos products, and we then received external bug bounty reports about those same vulnerabilities shortly afterward.
With Asnarök, the disclosed vulnerability was distinct from the one used in the attack, and the researcher had previously contributed (and continued to contribute) to our program and others, so we had low confidence of any direct connection. However, the submission was suspiciously timed (one day before the attack) and the location of the researcher’s device was also suspect: Chengdu, a city in China that we later identified as the epicenter of Pacific Rim activity.
Personal Panda (CVE-2022-1040) was a similar story. A pseudonymous researcher, who did not wish to be credited, reported a zero-day to our bug bounty program and received a $20,000 bounty. The researcher claimed they were based in Japan, but the IP of the device they were using was geolocated to China. Retrospective threat hunts revealed active exploitation of CVE-2022-1040 predating the bug bounty submission. While limited in prevalence, victimology and timing showed a targeting pattern consistent with PRC-based foreign policy objectives.
We don’t have enough evidence to definitively tie those attacks to the corresponding submissions. But the timing, context, and certain indicators raised the possibility of a perverse incentive: an actor exploiting a vulnerability and also attempting to monetize disclosure, leaning on the ‘good faith’ assumption that makes bug bounty ecosystems work.
Importantly, this does not change our view of the researcher community at large. The vast majority of submissions are made in good faith, and our program depends on continuing to treat good-faith researchers with respect. We continue to receive valuable submissions from China-based researchers who demonstrate deep familiarity with our firewall internals, and their contributions make our products more secure — the same goal the program was designed to serve. But the Pacific Rim experience does reinforce a Secure by Design reality: bug bounty programs should be run with mature operational guardrails — strong triage, validation discipline, and awareness that adversaries may try to game any system that involves money and trust. That discipline becomes more important, not less, as AI widens the set of actors who can plausibly produce high-quality submissions.
Back to AI: Where this is going, and what it demands
With eight years of program context in mind, let's return to the AI question. The slop and capability trajectories sketched at the top of this piece are no longer abstract, they’re reshaping what the queue looks like for everyone running a program. Three voices help frame what we’re seeing.
The industry is converging on this view. The Cloud Security Alliance’s recent Mythos-ready paper, a multi-author position paper led by Knostic’s Gadi Evron with co-authors from CSA and SANS, and reviewed by more than 250 CISOs (including this author), frames the same shift bluntly: the window between vulnerability discovery and weaponization has collapsed to hours, and security programs built on weeks-long patch cycles weren’t designed for that speed. Bug bounty programs sit at the front edge of that pressure.
Michael Skelton, SVP of Operations at Bugcrowd, has shared observations from their queues that illustrate each side of the shift. On the slop side, the crowd has expanded quickly to larger cohorts using AI in a somewhat uninformed way, producing a rising volume of low-effort, low-tier submissions. This is the most visible change. But, Skelton notes, not the most important one. The more consequential shift is in what skilled researchers are doing with AI. Bugcrowd is seeing a notable rise in coverage of authorization-based vulnerabilities. In many programs, hackers are identifying a single vector for an authorization bypass, then using AI to scale it across a customer’s tenant, in some cases, across multiple apex and subdomains within the program’s scope. Authorization bugs that previously took years to work their way out of a program can now surface in hours to days. Skelton anticipates this becoming one of the most significant ways we talk about AI’s impact on security, both offensively and defensively.
That’s the near-term picture. The medium-term picture is sharper still. As we argued in our recent piece on the vulnerability flood, frontier models are moving beyond plausible-sounding nonsense towards validated, exploitable, high-severity vulnerabilities at scale. Anthropic’s Claude Mythos Preview has already discovered thousands of zero-days across major operating systems and browsers. Our own OpenClaw red-team exercise, using pre-Mythos models on one of our internal networks, compressed days of reconnaissance into hours and surfaced critical escalation paths from a single unprivileged account.
Put those two trajectories together and the implication for bug bounty programs is stark: the challenge is flipping from filtering out noise to keeping up with a steady feed of real findings, while the noise itself continues to scale.
What this means for program design
The question isn’t 'how do we stop, or reduce, AI submissions?' It’s 'how do we preserve trust and signal in a world where both good research and noise can be produced at machine speed?'
Here’s the direction we think programs will need to move in — ours included:
- Stronger evidence requirements by default. Clear PoCs, logs, traces, impacted versions, and reproducible steps. If a claim can’t be reproduced, it doesn’t belong in the pipeline.
- Better pre-triage filtering and automated validation. Both platform-side and vendor-side. Reputation signals and slop-detection reduce incoming noise, but the bigger opportunity is automating the assessment itself: spinning up a clean instance of the affected product, replaying the submitted PoC, and confirming or refuting the claim before a human ever looks at it. That’s the kind of infrastructure investment that scales with the submission volume AI is about to generate.
- Incentives tuned toward depth. Chaining, realistic exploitability, novel classes — not just ‘bug counts.’ The economics of the program need to reward the work AI can’t yet do cheaply.
- Program design that anticipates adversarial behavior. Rate limits, structured submissions, and clear policies for suspicious patterns. One technique worth considering is seeding your program with honey-token vulnerabilities, plausible-looking but fabricated issues that shouldn’t appear in legitimate research. Submissions matching those patterns are a useful signal for flagging bad-faith or AI-slop pipelines at the source. Any system that involves money and trust will be probed. Gadi Evron originally floated this idea half-jokingly, but in the slop era it might genuinely have legs. Any system that involves money and trust will be probed
- Raise the burden of proof, and accept the uncomfortable trade-off. Historically, bug bounty programs ask researchers to stop as soon as they have vague proof of a finding, you don’t want them pivoting deeper into your infrastructure or touching customer data. But the Mythos era changes that calculus. If a submission is genuinely exploitable, that’s not slop; the ability to go further and prove real impact is exactly what separates real research from confident-sounding fiction. We recently had a submission vivid enough that Sophos engineers spent part of a weekend on a call trying to reproduce and resolve it — only to find the entire thing was fabricated. As proof thresholds rise, programs will need to revisit their rules of engagement and contracts: granting trusted researchers controlled paths to demonstrate impact more thoroughly, without putting real customer data at risk. That’s a genuine tension, but one the community will need to work through.
- Closer partnership with platforms. Bugcrowd has already begun moving in this direction, recently updating submission policies, rate controls, and detection mechanisms to combat what it calls ‘sloptimism’ — high-volume, speculative AI-generated reports submitted with minimal validation — and permanently banning accounts engaged in submission farming.
AI will also accelerate the ‘unification’ work many security teams are already pursuing: merging findings from pentests, scanners, internal testing, and bug bounty submissions into a single prioritization system with consistent scoring and context. But there’s one more shift worth naming, and it’s the one defenders shouldn’t sleep on. The same AI capabilities that let attackers and researchers find bugs faster give vendors of closed-source software an asymmetric advantage — if we’re willing to use it. External researchers are working from the outside in, against binaries and black-box behavior. We’re working from the inside out, with full access to the source, the build system, and the test infrastructure. Pointing AI at our own code to hunt bugs ahead of the people hunting us isn’t a nice-to-have in the Mythos era. It’s one of the most meaningful advantages defenders have, and the programs that invest in it will be the ones that stay ahead of the curve rather than chasing it.
Tips for operating well in the Mythos era
For hunters
- Reproducibility beats volume. Clear steps, evidence, and validation matter more than ever. Especially when triage teams are drowning in noise.
- Use AI like a co-pilot, not a substitute. AI can help with clarity and organization, but humans still need to validate claims and test assumptions. If you claim RCE without validating it, everyone loses, especially you.
- Be creative: ‘zig’ when everyone else ‘zags.’ Duplicates happen. Novelty often comes from unusual paths, overlooked configs, or deeper chaining. The places automated submission pipelines don’t reach.
- Appreciate companies that appreciate researchers. Programs that value your work are the ones worth investing your time in.
For organizations
- Treat bug bounty as part of Secure by Design, not a PR initiative. Integrate it with secure development practices, pentesting, internal assessments, and response workflows.
- Reward impact — and the work required to prove impact. If a report shows credible risk (even if only DoS is demonstrated), value it appropriately when exploitation plausibility is high.
- Measure ‘health,’ not just volume. Are low-effort issues decreasing over time? Are researchers returning? Are bugs trending toward harder-to-find classes? These are signs that you’re doing something right, both with your products and with your program.
- Continuously tune scope and incentives. Your program should evolve with architecture changes, product maturity, and active threat context — and now, with the changing shape of AI-assisted research.
- Use submissions to tune incident response. You should be able to ‘spot the researcher’ in your telemetry — and identify any previously unknown attempts to exploit the bug.
- Build explicit defenses against low-quality automation. Structured submission requirements, evidence gates, and reputation signals reduce the cost of noise without penalizing good-faith hunters.
- Appreciate researchers. This sounds simple, but it matters. Researchers who feel valued come back. Programs that treat submissions as an inconvenience get what they deserve.
Conclusion
Thirty years in, bug bounties are here to stay, but the programs that thrive will be the ones that evolve. The core mechanics of external incentives, responsible disclosure, and collaborative hardening still work. What’s changing is the scale, the tooling, and the threat environment around them.
For Sophos, the bottom line remains the same: bug bounty is one of the ways we deliver Secure by Design outcomes in practice — through continuous external validation, fast response, and long-term engineering improvements that raise the baseline for everyone. The Mythos moment doesn’t change that mission. It raises the stakes of getting it right.
Bug bounty programs will always come with challenges, and therefore need to be carefully managed. They’re neither a cure-all, nor a fire-and-forget. But when integrated into other security efforts, and when both organizations and researchers are working in good faith together, the bounty can be plentiful.


