Audits & known issues

Summary

Projects will often go through code audits as a part of their security strategy. Issues or vulnerabilities may be unearthed during this process, which can sometimes present challenges for security researchers who are looking for unique bugs. 

Known issues will also sometimes surface independently of audits, where your reported bug was already known to and documented by the project team prior to reading your report. In those cases, a fix may be underway, or held in the team’s backlog, or it may be something the team has decided not to fix.

Additionally, some issues may also become publicly disclosed via public security advisories, CVEs, or otherwise. When a bug is acknowledged (internally or publicly) by a project, it becomes a known issue. Read on to see what rules apply to these types of situations.

Situations

What to do when my report is flagged as a known issue?

If a project flags your bug report as a known issue and closes it, you have the right to ask for verification that the issue was, in fact, already known to the project prior to receiving your bug report. Immunefi requires that projects MUST provide evidence when closing a bug report as a known issue.

You can ask for evidence when your report is closed as a known issue with this template:

“Hello [Project Team],

Would you please share the evidence or documentation regarding this previously known issue? 

This is consistent with Immunefi’s rules for closing reports as known issues: https://immunefisupport.zendesk.com/hc/en-us/articles/10644746170897-Report-Closed-for-Known-Issues

If the evidence is sensitive and there are privacy or security concerns, please provide it privately to Immunefi for verification.

Thank you in advance.

Best regards,

[Your Name]”

What counts as evidence of a known issue? 

Types of acceptable evidence for known issues include: a previous bug report, GitHub or GitLab reported issue, pull request, or some other form of clearly documented evidence. Here is a full list of acceptable types of evidence. 

If Immunefi’s help is needed with verification (due to the project providing it privately), or if the project is completely refusing to provide evidence: use the request help option in the bug report dashboard without further delay.

I found a bug that was uncovered in a project’s audit in the past, but wasn’t fixed. Can I report it?

Yes. You can report it. However, there is a high likelihood that your report will be closed as a known issue by the project, leading to no payout. 

Immunefi may recommend that the project fix the bug and provide a goodwill payout, but the final decision rests with the project.

Am I allowed to report issues found in audits on a different project with similar code?

Yes. If a bug was found in an audit of project A, but you noticed that project B, C, and D share a similar codebase and you discovered that the same bug exists on those codebases, then it is valid for you to report those bugs as findings and be paid separately by each of the projects.

How long after my report is closed as a known issue can I report it again if it isn’t fixed? 

Do not re-report the same issue again if it was closed, as this can be seen as spammy behavior, which is a bannable offense. Instead, if you have found new evidence or disagree with the reasoning of an existing bug report, you can request mediation and respond to the original bug report.

I reported a bug that was closed as a known issue. The project later fixed it. Am I owed a reward?

If the issue you reported was reasonably demonstrated to be a known issue (meaning it was known by the project prior to your report), then the project is not required to pay you a bounty reward.

Can I report bugs that are mentioned in public disclosures, public security advisories, or CVEs?

The shortest possible answer is, don’t submit bugs mentioned in public disclosures until the out-of-scope waiting period is over. For the full explanation, read the article on CVEs. 

For bugs that are publicly disclosed, such as by public security advisories, CVEs, or otherwise, Immunefi considers these vulnerabilities temporarily out-of-scope in order to give projects time to respond.

Once the following timelines are over, the publicly disclosed vulnerabilities become in-scope once again and bug reports referencing them are to be rewarded as normal. If a project has not fixed a publicly disclosed vulnerability in the following timelines, then it’s assumed that the project is not aware of the impactful threat that the vulnerability is poses:

• Critical & High severity vulnerabilities are out-of-scope for 30 days after the public vulnerability disclosure is made. These types of vulnerabilities pose a significant risk to the security of the system and require immediate attention to prevent potential attacks.
  
  
• Medium severity vulnerabilities are out-of-scope for 60 days after the public vulnerability disclosure is made.
  
  
• Low severity vulnerabilities are out-of-scope for 120 days after the public vulnerability disclosure is made.

The out-of-scope period begins from the date when the relevant public vulnerability disclosure was made. 

It is very important NOT to submit your report of a publicly-disclosed issue until AFTER the out-of-scope period has been completed.

If you submit a bug report before it has completed its temporary out-of-scope period, then this bug report will be closed without payment. Additionally, any further bug reports on the same vulnerability after the period has ended may then be closed without payment as known issues.

Additional notes

Although evidence must be provided by a project for known issues, there are cases where this evidence may be shared privately and only with Immunefi due to privacy or security reasons.

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. Projects are expected to resolve reports with known issues within a reasonable timeframe, which includes providing evidence that the bug was a known issue, but no formal timeline for doing so has yet been established.