When Bug Bounty Programs Stop Being Fair
When Bug Bounty Programs Stop Being Fair
I have been active in the bug bounty scene for quite some time now. Over the years, I’ve seen excellent programs that truly value and motivate their researchers, but I’ve also encountered programs that are poorly managed, ignore reports, or fail to treat researchers fairly. What makes my perspective somewhat unique is that I have seen both sides of the process. I have worked as a security researcher, but I also previously worked in triage for one of the major bug bounty platforms. That experience gave me insight into how programs operate internally and how reports are handled behind the scenes. In this post, I want to share some concerns I have regarding the current state of certain bug bounty programs, based on both my personal experience as a researcher and what I witnessed from the triage side.
Disclaimer
Due to NDA obligations, I will not mention the platform or company involved, nor will I disclose technical details about the vulnerabilities that were reported. The purpose of this post is not to publicly shame a specific company, but rather to highlight structural problems that increasingly affect researchers across multiple programs.
The Reality Behind Some Programs
There are four major bug bounty platforms, and I previously worked for one of them. During that time, I interacted with many different programs and program owners. One thing that surprised me was how often companies would ignore reports for months, sometimes even years. In some situations, this was understandable. Some teams were clearly understaffed or overwhelmed by the volume of incoming reports. However, there is an important principle that should always apply to bug bounty programs:
If a researcher submits a valid report that is in scope, contains a legitimate vulnerability, and includes a valid proof of concept, the researcher deserves compensation.
From the triage perspective, many reports were validated long before the company even reviewed them. When companies attempted to ignore or unfairly dismiss reports, triagers and mediation teams would usually step in and negotiate to ensure the researcher received a fair outcome. In some rare situations, when a company completely refused to cooperate, the platform itself would pay the bounty out of its own pocket to ensure the researcher was treated fairly. That is how the process should work.
A One-Sided Relationship
When companies join a bug bounty platform, they agree to follow the platform’s policies and disclosure rules. Researchers are also expected to follow strict guidelines: respecting scope, avoiding disruption, providing clear reports, and behaving professionally. But lately, it increasingly feels like those rules only apply to researchers. Large companies are often treated differently because they are valuable customers to the platform. Researchers, on the other hand, have very little leverage when disputes occur. This creates a frustrating imbalance in the ecosystem. Researchers are expected to invest time, knowledge, and effort into responsibly disclosing vulnerabilities, often spending hours or days validating issues and writing high-quality reports. Yet in some cases, companies can simply change scope, delay responses indefinitely, or close reports without meaningful justification.
My Experience as a Researcher
Recently, I experienced this firsthand while hunting on a public program that I will refer to as the “Bad Company” program. I submitted several findings related to subdomain takeovers. The reports were successfully triaged and validated, then forwarded to the company for payout. At the time of submission, the vulnerability class was explicitly listed as in-scope within the program policy. Then, nearly two years later, the company suddenly decided to remove the entire vulnerability class from scope. As a result, my reports were closed as Informative.
No proper explanation was provided.
No payout was issued.
And despite the reports being fully valid at the time of submission, the outcome was retroactively changed.
When I contacted mediation, I was essentially told that nothing could be done because the company had the final decision. As a researcher, this is incredibly discouraging. You spend time investigating, validating findings, building proof of concepts, documenting impact, and following every platform rule, only to discover that a company can retroactively change the rules years later without consequences. That damages trust not only in the specific program, but in the bug bounty ecosystem as a whole.
Why This Matters
Bug bounty programs rely heavily on trust. Researchers trust that if they follow the rules and submit valid findings, they will be treated fairly. Companies trust researchers to disclose vulnerabilities responsibly instead of exploiting them. The moment platforms allow companies to ignore validated reports or retroactively invalidate submissions, that trust starts to disappear. And once researchers lose confidence in the ecosystem, everyone loses.
Good researchers move on.
Report quality decreases.
Responsible disclosure becomes less attractive.
Over time, that hurts both the platforms and the companies that depend on the security community.
Final Thoughts
I still strongly believe that bug bounty programs provide value. They help secure products, improve communication between researchers and companies, and create opportunities for independent security researchers around the world. But platforms also need to protect the researchers who keep these programs alive. Fair mediation, transparency, and accountability should apply to both sides — not only to researchers. A company should not be able to retroactively invalidate a report simply because policies changed years later. If bug bounty platforms want to maintain trust within the community, they need to ensure that validated findings remain protected under the rules that existed at the time of submission. Without that protection, bug bounty programs risk becoming one-sided systems where researchers carry all the responsibility while companies avoid theirs. And that is not sustainable for the future of the community.
Timeline
- June 14 2024 — Multiple Vulnerabilitys reported
- June 17 2024 — Triaged and validated
- July 2024 — Update request 1
- October 2024 — Update request 2
- May 2025 — Update request 3
- March 2026 - Closed as informative