Report Closed for Known Issues

If the bug or issue is already known to the project prior to the submission of the report, then they can close the bug report without providing a reward to the whitehat. The project can prove prior knowledge by providing:

• Self-reports on Immunefi
• A reference to a previous bug report
• A GitHub pull request
• A Gitlab pull request
• A Github reported issue
• A Gitlab reported issue
• A Screenshot from Github that shows the known issue (the commit hash, the URL, the date of the pull request, the repository name, and the owner of the repository must be visible in the screenshot)
• An audit report
• A blog post (the publication date must be verifiable using either Google cache or the Wayback Machine) and it must:
  • Be written by the project.
  • Reported internally by the project.
  • Describe the vulnerability dependency.
  • Show time stamp that this happened before the escalation of the report.
• An email with dates that clearly states the vulnerability and its impacts (this should either be forwarded to [e-mail], or a PDF of the email should be attached in the bug thread)

This evidence must be provided in the dashboard when a project closes a report because of a known issue.

All bug reports that meet report requirements are first escalated to projects, so they can review them and decide whether they are a known issue for them. The project does not have SLAs for defining a known issue except for those mentioned here.

Bug Reports on Previously Discovered Issues

Bug reports that cover previously discovered vulnerabilities are not eligible for rewards under the bug bounty program. For a report to be considered a known issue, the project must provide clear proof that the issue was already identified before the whitehat’s submission and escalated via Immunefi.

Key Considerations for Known Issues:

• Proof Requirement: The project must demonstrate that the issue was documented, acknowledged, and understood before the report.
• Understanding the Issue: Simply recognizing an attack vector or a general risk does not qualify as knowing the issue; both the exploit method and its impact must be fully understood.
• Action Taken: If the issue was known but not acted upon, and the project only addressed it after the whitehat’s report, the submission may still be eligible for a reward.
• Timing & Variations: Even if the vulnerability was present before submission, different execution methods or new insights can make it a distinct issue rather than a previously known one.

If a report is rejected due to being a known issue, the project must provide concrete evidence supporting this claim. Otherwise, the submission remains valid for reassessment in the mediation.