"Duplicate" and "Informative" are the two closures every bug bounty hunter dreads. You found something real, spent hours documenting it, and the triager closed it without a payout. Sometimes the closure is fair. Sometimes your report failed to communicate the issue clearly enough for triage to see its value. Understanding why these closures happen — and how triage teams think — helps you write submissions that survive first review.
This guide focuses specifically on duplicate and informative resolutions. For the full picture including missing reproduction, impact failures, and scope issues, read how to write a bug bounty report that does not get rejected.
How triage actually works
Triage engineers review reports in volume. On popular programs, they may process dozens of submissions per day. Their job is to validate the vulnerability, assess impact against the program's severity rubric, check for duplicates, and route valid findings to engineering.
They are not trying to reject your report — they are trying to process a queue efficiently. Reports that are clear, well-structured, and demonstrate impact get accepted faster. Reports that require three rounds of "can you provide more details?" slow the queue and often end up closed as Informative when the triager cannot confirm exploitability within their time budget.
Why reports get marked Duplicate
A duplicate closure means someone else reported the same vulnerability first, or the program already knew about it internally. The original reporter (or internal ticket) gets credit; your submission is linked and closed.
Same root cause, different endpoint
The most common duplicate scenario: you find XSS on /profile and report it, but another researcher already reported the same unsanitized output function on /settings. The program treats it as one vulnerability with multiple instances. You should have searched disclosed reports and consolidated all instances into a single submission.
Internal knowledge
Large companies often have internal security teams who found the issue before the bug bounty program launched. Your report is technically a duplicate of an internal ticket you cannot see. This is frustrating but not something you can prevent — submit quickly and move on.
Scanner-detected issues
Automated scanners continuously monitor many programs. A CVE in a JavaScript library may be flagged internally before you submit. Check the program's known issues and changelog before filing component vulnerabilities.
How to reduce duplicate risk
- Search HackerOne/Bugcrowd disclosed reports for similar titles and endpoints
- Submit immediately after validation — hours matter on competitive programs
- File one report per root cause, listing all affected endpoints
- Check if the program has a "known issues" or "won't fix" list
Why reports get marked Informative
Informative (or "Not Applicable" / "Won't Fix" on some platforms) means the program acknowledges your finding but does not consider it a security vulnerability worth rewarding. This is the closure that generates the most researcher frustration because the underlying issue is often real — just not impactful enough for the program.
No demonstrated attacker impact
The most common informative reason. You found something technically interesting but did not show what an attacker gains:
- Self-XSS without a delivery mechanism to affect other users
- Missing security headers without a specific exploit chain on that application
- Version disclosure revealing an internal framework name
- CSRF on a non-sensitive action (changing theme preference)
The fix: always demonstrate concrete impact. If you cannot show harm to another user or the organization, the finding may be real but not bounty-worthy. See our guide on writing impact sections that survive triage.
Known accepted risk
Programs explicitly list accepted risks in their policy: missing DMARC, verbose server headers, autocomplete on password fields. Filing these generates informative closures regardless of report quality.
Theoretical or impractical attack
"An attacker with physical access to the server room could..." — physical access assumptions, attacks requiring social engineering of C-level executives, or scenarios needing millions of requests without rate-limit bypass. Triage assesses practical exploitability, not theoretical possibility.
Low-severity by program rubric
Some programs do not reward below a certain threshold. A CVSS 2.0 informational finding may be valid but below the payout floor. Check the program's severity rubric before investing hours in the report.
Structure reports that triage accepts
PoCcraft formats impact, reproduction steps, and severity into report-ready sections — reducing the back-and-forth that leads to Informative closures.
Open GeneratorDuplicate vs Informative: key differences
Duplicate: The vulnerability is valid and worth fixing — someone else got there first. You do not get paid, but the issue is real. Some programs offer partial credit or bonus points for valid duplicates.
Informative: The program does not consider it a security issue (or not one they will fix/reward). No one gets paid. The issue may still be real from a pure security perspective but falls below the program's bar.
Knowing which closure you received matters for your response strategy. Duplicates are about timing and coverage. Informative closures are about impact demonstration and program policy alignment.
How to respond professionally
For duplicates: Ask which report yours duplicates. Study that report's structure. Request duplicate credit if the program offers it. Do not argue unless you can demonstrate your finding is a distinct root cause — and provide evidence, not assertions.
For informative: Politely ask for the specific reason. If the issue is impact, offer additional PoC showing attacker harm. If the program cites policy, accept it and add the accepted risk to your pre-submission checklist. Arguing without new evidence burns reputation with triage teams.
Never: Threaten public disclosure, spam multiple reports for the same issue, or argue emotionally. Triage teams remember difficult researchers and it affects future submissions.
Pre-submission checklist
Before hitting submit, verify:
- Impact is demonstrated, not just claimed — show what the attacker gains
- Reproduction steps work on a fresh session (see bug bounty report template)
- The finding is in scope per the program policy
- You searched for duplicates in disclosed reports
- Severity aligns with the program's rubric — use our CVSS calculator
- The finding is not on the program's known accepted-risk list
Classify the vulnerability correctly using OWASP Top 10 categories so triage can route it to the right team on first review.
The bottom line
Duplicate closures mean someone got there first — submit faster and consolidate instances. Informative closures mean triage does not see sufficient impact or the finding falls below program policy — demonstrate concrete attacker harm and read the policy before filing. Write structured reports with our template, generate sections with PoCcraft, and treat every closure as feedback that makes your next submission stronger.