In-Scope and Public Disclosure

Dear fellow hackers,
a question came in mind which I am not sure I’ve read an answer to before. It’s about Bug Crowd and other Bounty websites alike.

If I find a vulnerability in a target which is valid and can be exploited for malicious purposes, but the bounty lists it as out of scope, do I have the right to publicly disclose it (let’s say in my blog) as a 0day? What if I fist report it and they mark it as “won’t fix” / “out of scope” (since it truly is out of scope)? Do I then have the right to report it?

This is a question that has been asked before in the forums yet it got no replies. With the current state of things, chances are you won’t get paid or receive Kudos points and you may even lose reputation / points like the researcher above.

I will try to limit this topic to this specific situation and not broad it with questions like “What should be in scope?” or “Should everything be in scope?”.

What do you fellow researchers think about that?

P.S.: Yes, I’m asking this because it just happened to me… :smile:

Hi DaKnOb,

The disclosure policies on each program brief apply to all submissions made through the Bugcrowd platform, including Duplicates, Out of Scope, and Not Applicable submissions. If you want to retain disclosure rights for vulnerabilities that are out of scope for a bounty program, I would recommend that you report the issue to the vendor directly. Bugcrowd can assist in identifying the appropriate email address to contact if you email

I know it is frustrating when you find a critical vulnerability that is out of scope, and feel like the customer really NEEDS to know about it so they can remediate the problem. Bugcrowd encourages all customers when they are defining their in and out of scope targets to ensure their program includes all critical components they want to receive vulnerability reports for. In the case where a P1 or P2 out of scope issue is submitted to a Bugcrowd managed program we make sure to notify the customer and get their review before we validate the submission, asking not only if they want to accept the OOS bug but if they would like to expand their scope to include additional findings in this area. Ultimately the final scope decision is theirs to make.