Self-reporting Bugs and Closing Reports with Known Issues

What should I do if I find a bug or issue?

Projects are highly encouraged to list previously known bugs or issues to their bug bounty page as out of scope. Additionally, we recommend that projects quickly self-report these known bugs or issues for tracking purposes. Doing so is important because it helps to avoid situations where a duplicate report is submitted by a whitehat and a project team member at the same time (see here for an example of such a situation).

To self-report, simply submit a bug report to your own bug bounty program. The details of this report will only be shared with members of the Immunefi triaging team and will not be made public record. Please include '[INTERNAL REPORT]' in the title of the report and indicate that you are a team member. For the wallet address, you should manually enter a null address (for example '0x0000000000000000000000000000000000000000'). Do not use a real wallet address.

By design, the admin initiating an [INTERNAL REPORT] won't be able to close or access it once escalated. Kindly request assistance from another team member with an Admin role to handle the closure.

How do I prove that a bug/issue is already known?

If the bug or issue is already known to you prior to the submission of the report, then you can close the bug report without providing a reward to the whitehat. However, you must prove prior knowledge of the issue to do so. You 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 you close a report because of a known issue.

You do not have SLAs for defining a known issue except for those mentioned here.