Duplicate reports in bug bounty: how to detect and communicate them correctly
By Kike Gandia · Co-Founder & CEO, OSCP
A duplicate report in a bug bounty program is a finding that has already been reported by another researcher and is being resolved. Handling duplicates well — with transparency and fairness — is essential for maintaining researcher trust and the program's integrity.
Why duplicates are inevitable in bug bounty
In an active bug bounty program, especially a public one, it's completely normal for several researchers to find the same vulnerability at the same time or within hours of each other. Some vulnerability types are much easier to find — XSS in public forms, IDOR in obvious parameters — and attract many researchers at once.
The duplicate rate ranges from 10% to 40% of total reports in mature public programs. In private programs, the rate is lower because there are fewer researchers.
How to detect a duplicate during triage
Detecting duplicates requires a systematic process:
1. Search the history of active and closed reports: by vulnerability type, affected URL, vulnerable parameter, and payload type.
2. Compare the impact: two reports may describe different vulnerabilities on the same endpoint.
3. Check the date: the first report to arrive takes priority, regardless of report quality.
4. Consider report quality: if the first report was too poor to allow validation and the second clarifies it, evaluate whether it deserves recognition.
In high-volume programs, tools like those offered by HackerOne and Bugcrowd automatically flag potential duplicates using semantic similarity.
How to communicate a duplicate to the researcher
Communicating a duplicate is one of the most delicate moments in managing a program. Researchers know duplicates happen, but they need to feel the process is fair.
Elements of good duplicate communication:
• Confirm the report has been received and reviewed.
• Explain that the vulnerability was already being investigated or resolved.
• Give as much context as possible about the status of the original report: is it already patched? In progress?
• Thank the researcher for their work even though they won't receive a bounty.
• If the program has a duplicate-recognition policy, apply it.
What you should never do: close a report as a duplicate without giving the researcher any context.
Duplicate policy: how to define it in your program rules
Include a clear section on duplicates in your program rules:
- Define what counts as a duplicate: the same vulnerability on the same endpoint, not just the same vulnerability type.
- State whether there's partial recognition for the second reporter: some programs award a percentage of the bounty or Hall of Fame recognition to the second reporter if their report contributes to the resolution.
- Define the window in which a report is considered "new" even if it's the same vulnerability: if it's already patched and someone reports it again, is that a duplicate or a patch bypass?
This clarity in the rules prevents conflicts and sets the right expectations.
FAQ
Do I have to pay the second researcher who reports the same vulnerability?
Standard practice is that only the first report receives the full bounty. However, some programs award partial recognition (10-25% of the bounty) to the second reporter if the report is high-quality and contributes to the resolution. This is a program policy decision.
What if the second report has more detail or a better PoC than the first?
The second report doesn't displace the first in bounty priority, but it can still contribute to the resolution. In that case, the fairest approach is to credit it in the changelog or Hall of Fame, and consider a symbolic payment if the program has budget for it.
How long should I keep a report marked "active duplicate" before closing it?
A report marked as a duplicate should be closed when the original report is closed: once the vulnerability is patched and verified. Keeping reporters informed about the status of the original (generically, without revealing details of another researcher's report) is good practice.