Notifications
Clear all
Topic starter
19/08/2026 4:03 pm
TL;DR: Duplicate and repeat bug bounty submissions are usually a signal that a vulnerability was either not fully fixed or later reintroduced, and Intigriti reports that an average of 3% of reported issues have resurfaced, with some instances reaching 8%. The governance problem is not just payout duplication but weak retesting discipline and release validation that allow the same flaw to reappear.
NHIMG editorial — based on content published by INTIGRITI: Preventing the growing costs of repeat and duplicate bug bounty submissions
By the numbers:
- Intigriti reports that an average of 3% of a program's reported vulnerabilities had been previously addressed but have since resurfaced.
- In some instances, 8% of submissions were on vulnerabilities that had reappeared, according to Intigriti's analysis.
Questions worth separating out
Q: What breaks when bug bounty programs do not separate duplicate from repeat submissions?
A: Teams lose visibility into whether a vulnerability was already fixed, was never fully fixed, or was reintroduced later.
Q: Why do repeated vulnerability reports matter more than simple duplicates?
A: Repeated reports show that a fix did not survive the software lifecycle.
Q: How do security teams know whether retesting is working?
A: Retesting is working when reopened findings drop, closure quality improves, and the same issue does not reappear after deployment.
Practitioner guidance
- Build a duplicate-versus-repeat decision rule Classify findings by root cause and fix durability, not by report text alone.
- Track recurrence as a security metric Report the percentage of reopened or resurfaced vulnerabilities separately from raw volume, so leadership can see whether the programme is reducing exposure or merely finding the same flaws again.
- Add retesting to release validation Request retests for high-impact findings after remediation, especially in high-change applications, so a reopened issue is caught before it becomes a pattern.
What's in the full article
INTIGRITI's full article covers the operational detail this post intentionally leaves for the source:
- How the platform distinguishes duplicate, accepted duplicate, and repeat submissions in live triage
- The retesting workflow used to validate whether a previously fixed issue is still reproducible
- The practical impact of recurring reports on bug bounty payouts and researcher engagement
- How Dedupe AI is used to identify resurfacing vulnerabilities and support programme efficiency
👉 Read INTIGRITI's analysis of duplicate and repeat bug bounty submissions →
Duplicate bug bounty reports: what recurring findings mean for teams?
Explore further
19/08/2026 4:38 pm
Recurring findings are a release-governance signal, not just a bounty-management issue. When the same vulnerability reappears, the failure is often downstream of code fix quality, deployment validation, or change control. That makes recurrence a control assurance problem rather than a researcher behaviour problem. Teams should read duplicates and repeats as evidence that remediation is not surviving the software lifecycle.
A question worth separating out:
Q: Who is accountable when a fixed vulnerability reappears in production?
A: Accountability usually sits across engineering, security, and release ownership, because recurrence often means the fix was not preserved during build, test, or deployment. The important governance question is who owns verification after the fix. Without that ownership, reopened exposure can be treated as a new issue instead of a failed control.
👉 Read our full editorial: Duplicate bug bounty submissions reveal recurring security gaps
