Is my bug really out-of-scope?

Summary

If you’re here, you probably just had a bug report that was closed as “out-of-scope”. Every project has a list of assets and impacts that are listed as “in-scope”, so a report being closed in this manner generally means that the project doesn’t think the report matched the eligibility conditions of their bug bounty program.

Though this may seem plain and straightforward, the project’s reasoning may not seem clear enough, or you might still have questions on your mind about your bug submission.

Are only the assets listed in the “assets in scope” section of the project’s BBP valid for bug submissions?

This is true for projects using Primacy of Rules (if a project doesn’t say that it is using “Primacy of Impact”, it is using Primacy of rules).

But for projects using “Primacy of Impact”, different rules apply. For those projects that use “Primacy of Impact”, any vulnerability that causes direct loss of funds to the project can be reported. More information about Primacy of Impact is available here.

BBPs using “Primacy of Impact” may use wording such as this:

“Hackers are encouraged to submit issues outside of the outlined Impacts and Assets in Scope.

If whitehats can demonstrate a critical impact on code in production for an asset not in scope, [project name] encourages you to submit your bug report using the “primacy of impact exception” asset.”

The project closed a bug because the asset is out of scope, but I still think the bug negatively affects users. What should I do? 

When projects create bug bounties with Immunefi, they make very careful and conscious decisions about what assets are in scope and which are not. If the asset you’re reporting about is not in scope, it’s because the project has decided to opt out of receiving reports about that asset, regardless of the potential impact. 

However, if the impact could result in direct funds at risk (with no additional user interaction required for the exploit to be successful), then check to see if the project has Primacy of Impact in their bug bounty program. If they do not have Primacy of Impact, but there are still direct funds at risk, you should contact Immunefi. Our team will contact the project to see if the project wants to add that asset to their assets in scope table. 

If no direct funds are at risk, it is likely that the project is not interested in your report. You can submit it to the project anyway, but they are under no obligation to provide a reward, even if they fix the bug. In those cases, we recommend that the project provide a goodwill payout, but they are not required to. 

Can I also hunt bugs on assets not listed in the “assets in scope” section, for example, Telegram, Discord, web servers that are not listed?

It depends on the wording of the BBP. Some BBPs encourage further exploration, while others discourage or may explicitly forbid it. Read the BBP carefully to ensure that you understand and are operating within the right parameters for that particular project.

I reported a bug on an asset listed in the “assets in scope” section of the project’s BBP. Why was my report still closed as out-of-scope?

You are correct that assets listed in the asset-in-scope section are indeed valid targets for reporting bugs. However, the impact of the bug must also fall within the “impacts in scope” listed on the BBP:

Some examples of impacts that could be listed as in-scope here are:

• Any governance voting result manipulation
• Direct theft of any user funds or assets, whether at-rest or in-motion
• Permanent freezing of funds or assets
• Protocol insolvency
• Theft of unclaimed yield
• Temporary freezing of funds or assets for at least [specified amount of time]
• Miner-extractable value (MEV)
• Unauthorized minting of NFTs
• Predictable or manipulable RNG
• Unintended alteration of what the NFT represents (e.g. token URI, payload, artistic content)

I reported a bug that both affects an asset that is listed as “in-scope”, and has an impact that is listed as “in-scope”. Why was my report still closed as out-of-scope?

It’s possible that the information you have submitted was not enough to determine that the bug is in scope. If so, do submit additional details about the bug to show that the impact and assets are indeed in scope. 

If the project still closes the report as out-of-scope, and you believe that it should be in scope, please request help.

Can I report a bug that is not listed in the “assets-in-scope” or “impacts-in-scope”, or both?

Although it is ideal for an asset or impact to be listed, if you already found a bug that is not listed, you may:

1. Report the bug anyways, but don’t expect a reward — As a whitehat, we don’t expect you to work for kudos alone. But there are times when you may make a personal decision to submit a bug anyway for the good of the users, or to boost your rep. Sometimes, projects may even make a goodwill payment for your positive action.
2. Hang on to the bug — Store it in a secure location privately. There’s always a chance that the situation changes, and the bug eventually becomes in-scope. You can report it when it does. Even if the impact or asset is not in-scope, it could still cause real damage to the protocol. Avoid discussing the details of the bug with any other parties. 

I want to report a bug that would theoretically be in scope, and depends on a code change, value setting, or deployment to become in scope. Can I do it?

Submitting a bug that is theoretically in-scope will not guarantee you a payout, even if you make a good argument, as the outcome can differ greatly depending on circumstance. For example, it is possible that a product launch is being canceled internally due to some other reason, such as budget or priority changes.

Your next steps could be the following:

1. If you believe the changes are very likely (e.g. based on a series of public tweets/product announcements/launch schedule that has been shared by the project) and will happen soon — you can submit the bug, and be prepared to make your reasoning very clear based on those public materials. However, the project may claim that this is improbable based on some reason (e.g. internal decision-making, lack of incentive, changes in roadmap). If you are unsure of the veracity of these claims, request for Immunefi’s help to verify that this is true.
2. Wait until the code is actually shipped and the asset is listed in the project’s assets in scope table on their bug bounty program page. If you report immediately once the code is shipped and the relevant asset is in the in-scope table, it is unlikely that it will be exploited before the project has a chance to fix the vulnerability. Additionally, your bug report is now definitively in-scope if both the impact AND asset are listed as in-scope.