Duplicate bug bounty submissions reveal recurring security gaps

At a glance

What this is: This article explains how to distinguish duplicate from repeat bug bounty submissions and shows that recurring vulnerabilities often point to incomplete remediation rather than researcher noise.

Why it matters: It matters because recurring findings change how security, engineering, and assurance teams measure fix quality, retesting discipline, and programme efficiency across application and platform risk.

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.
• 95% of all retest requests have been completed, mpleted, according to Intigriti.

👉 Read INTIGRITI's analysis of duplicate and repeat bug bounty submissions

Context

Duplicate bug bounty submissions are not just a workflow nuisance. They are a sign that the same security issue is being discovered multiple times, which can mean the underlying defect was not fully removed, was reintroduced in a later release, or remains easy to find because its attack path is obvious.

For security and engineering teams, this is a governance problem as much as an offensive security one. In application security terms, recurrence shows where fix validation, release controls, and retesting discipline are not keeping pace with delivery pressure. That makes the topic relevant to programmes that rely on bug bounty, pentest follow-up, and vulnerability lifecycle management.

The article’s starting point is typical for mature bug bounty programmes: once volume rises, so does the need to separate duplicate reporting from true recurrence. The operational challenge is not unique to Intigriti, but the lesson is broadly applicable across crowdsourced security models.

Key questions

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. That leads to wasted payouts, repeated triage, and false confidence in remediation quality. The result is not just operational friction. It is a weaker assurance model because the same security flaw can keep resurfacing without being measured as recurrence.

Q: Why do repeated vulnerability reports matter more than simple duplicates?

A: Repeated reports show that a fix did not survive the software lifecycle. That can point to incomplete remediation, regression in a later release, or an unsafe deployment process. Duplicates are mostly a coordination issue. Repeats are a control issue because they reveal whether release management and validation are actually preventing the flaw from returning.

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. The signal is not just completion of the retest request. The signal is whether the vulnerability remains unreproducible across later releases and whether the team can prove that the fix held in the real environment.

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.

Technical breakdown

Duplicate versus repeat submissions in bug bounty workflows

A duplicate submission is a second report of the same underlying vulnerability while the first valid report is still active in triage or remediation. A repeat submission is different: the issue was supposedly fixed, then rediscovered because the fix did not hold or the flaw returned in a later release. The distinction matters because duplicates measure researcher overlap, while repeats measure control failure in the remediation lifecycle. In mature programmes, the root-cause test is whether one corrective action would have prevented both reports. If not, the findings may be related, but they are not the same vulnerability.

Practical implication: align triage rules to root cause, not report wording, so repeated defects trigger remediation review rather than duplicate closure.

Why recurring vulnerabilities distort security ROI

Recurring bugs create hidden cost because the same issue can trigger multiple payouts, multiple tickets, and repeated triage effort. That does not mean the programme is failing at discovery. It means the organisation is spending twice on detection while still leaving exposure open. The practical risk is that security teams mistake high report volume for better coverage when the real problem is poor closure quality. In that sense, recurrence is an assurance metric: it tells you whether the fix was durable, whether the release process preserved the fix, and whether the programme can prove operational reduction in risk.

Practical implication: treat resurfacing defects as a control-quality metric and report them alongside payout and closure metrics.

Retesting as a validation control for application security

Retesting is the process of asking a researcher to verify whether a previously reported vulnerability still exists after remediation. It is not a guarantee, but it closes the loop between fix implementation and security assurance. In practice, retesting works best when a programme can quickly identify the affected asset, preserve the original proof of concept, and confirm whether the vulnerability remains reproducible. This is especially useful in environments with frequent releases, where a correct fix may be overwritten or a dependency change may reintroduce the flaw. Retesting is therefore a control validation step, not just a courtesy to researchers.

Practical implication: make retesting part of release validation for high-risk findings, especially where deployment frequency is high.

NHI Mgmt Group analysis

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.

Bug bounty recurrence exposes a lifecycle gap that conventional vulnerability metrics miss. Counting closed tickets can overstate security progress if reopened exposure is not tracked separately. The more meaningful question is whether a fix remains effective after subsequent releases, dependency changes, and environment drift. Practitioners should track recurrence as a distinct metric tied to software delivery quality.

Clear duplicate handling is part of trust management with researchers. A report marked as duplicate without explanation can reduce researcher engagement and lower the quality of future submissions. That matters because crowdsourced security depends on sustained participation, not just one-off findings. Treating researchers fairly is therefore a programme-resilience issue, not merely a communication preference.

Retesting should be viewed as a control validation layer within application security governance. It provides evidence that remediation was durable and that the underlying exposure did not return. In framework terms, this aligns with vulnerability management and change validation expectations under NIST CSF and NIST SP 800-53, and the same logic applies wherever fixes are deployed at speed. The practitioner takeaway is to measure repeat findings as evidence of operational weakness, then close the loop with retest and release controls.

What this signals

Recurring findings should push security leaders to separate detection volume from remediation quality. A programme can look active while still allowing the same defects to return, which means the better governance metric is recurrence rate rather than raw submission count.

Recurrence debt: when fixes are not preserved across releases, teams accumulate a quiet backlog of security issues that look closed on paper but remain operationally alive. That is where release assurance, retesting, and accountability need to converge.

For identity-heavy applications and partner integrations, the lesson extends beyond code defects. Weak control over OAuth-linked access and other delegated trust paths can make repeat exposure harder to detect, so validation must cover both the application fix and the access boundary around it.

For practitioners

• Build a duplicate-versus-repeat decision rule Classify findings by root cause and fix durability, not by report text alone. Use the question, would one fix have prevented both reports, to separate duplicates from repeat vulnerabilities.
• 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.
• Explain duplicate closures to researchers When a report is closed as duplicate, include the root-cause rationale and the link to the original fix path so researcher trust is not lost through opaque triage.

Key takeaways

• Duplicate submissions are a workflow issue, but repeat submissions reveal that a vulnerability has survived or returned after remediation.
• Intigriti’s analysis shows that recurring findings are not rare enough to ignore, with resurfaced issues appearing in a measurable share of reports.
• Security teams should measure recurrence, validate fixes through retesting, and treat opaque duplicate handling as a trust and governance problem.

Key terms

• Duplicate Submission: A duplicate submission is a bug bounty report for a vulnerability that has already been reported and is still being triaged or remediated. It is usually treated as the same underlying issue, so the key question is whether one fix would have addressed both reports.
• Repeat Submission: A repeat submission is a new report for a vulnerability that was previously fixed but later reappeared or was still present after supposed remediation. It is a sign that the security control or release process did not preserve the fix across the application lifecycle.
• Retesting: A follow-up verification step that confirms a remediation really closed the finding and did not introduce a new weakness. Retesting matters because auditors and defenders need evidence that risk was reduced, not just that a ticket was closed.
• Return On Security Investment: Return on Security Investment is the value a programme gets from security spend relative to the risk reduced. In bug bounty and vulnerability management, it is improved when teams stop paying repeatedly for the same flaw and can prove that fixes persist.

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

👉 The full INTIGRITI article covers retesting, researcher handling, and recurring vulnerability economics in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management in a way that strengthens access oversight and remediation discipline. It is useful for practitioners who need to connect identity control to broader security operations.