Duplicate Report Avoidance Tips for Bug Bounty Hunters
Duplicates feel personal. They are usually process failures. Someone else—or you last year—already showed the same root cause. Triage closes your writeup and you lose the hours.
You cannot eliminate duplicates. You can lower the hit rate.
Search before you dig deep
Read the program's known issues, previous disclosures, and any "won't fix" notes. Search public writeups for the brand plus the endpoint family you are touching. If ten blogs already describe the same password-reset host header trick on that product, assume triage has seen it.
Internal notes help too. Keep a private log of bugs you filed and bugs you abandoned. Reopening the same IDOR pattern on a sibling route without checking prior tickets is how self-duplicates happen.
When a report is marked informative, ask whether the root cause was already tracked. Sometimes the answer saves your next week. Platform search across your own submissions is underrated—filter by asset hostname before you invest in a long proof.
Differentiate root cause from symptom
"Missing rate limit on login" is a class. "OTP endpoint accepts unlimited attempts for account X and returns distinguishable errors" is a finding. Triage duplicates on root cause more often than on URL path.
Before filing, write one sentence that names the broken check. If that sentence matches a public FAQ item or a prior report title you found, stop or expand the impact.
Good differentiators:
- A new trust boundary (mobile client vs web API)
- A different role that bypasses the previous fix
- A chained effect the earlier report never proved
- A regression after a claimed patch
Same XSS sink on a new parameter can still be a duplicate if the sanitizer gap is identical. Prove why the fix did not cover your vector. A one-line "still works on q after the search patch" with dates beats a vague claim of novelty.
Prefer fresh surface over famous bugs
New features, beta flags, partner portals, and recently acquired products have fewer prior reports. Old marketing domains have more. Spend early recon time on what shipped last quarter.
Also avoid filing five micro-reports that share one misconfiguration. Bundle them or pick the strongest proof. Five duplicates of the same CSP gap help nobody. If you find the same missing authz check on twelve CRUD routes, one report with a representative sample and a note that the helper is shared is usually stronger—and less annoying—than twelve tickets.
Write the report so triage can dedupe honestly
Include the earliest known related report if you found one, and explain the delta in two bullets. Attach exact requests, not screenshots of a generic scanner. If you are unsure whether it is new, say so—honesty beats a forced novelty claim.
Duplicates still happen on busy programs. Treat them as data: your recon missed a public trail, or the program is saturated on that class. Adjust the shortlist instead of arguing every close. A short polite clarification is fine when triage misread the delta; a five-page appeal on a true duplicate is not.