Bug Bounty Program
Thank you for your interest in helping us improve the security of our open source products, websites and other properties.
We have created this Bug Bounty program to appreciate and reward your efforts.
Reward Guidelines:
We base all payouts on impact and will reward accordingly. Please emphasize the impact as part of your submission. We are particularly interested and will consider extraordinary submissions for issues that result in full compromise of a system.
The table above outlines the nominal rewards for in-scope assets. Brainstorm Force, at its own discretion, will make the final decision on the bounties and rewards for qualifying vulnerabilities. Bounties will only be awarded to the first reporter of a vulnerability.
The amounts may vary depending on the severity of the issue and the quality of the report. Brainstorm Force holds the right to make the final decision at its own discretion.
If you believe you have found a bug in our property that is not mentioned in the scope above, and would like to report it: please send us an email on [email protected] and we’re happy to confirm.
As we’re a growing organization, we might have a property that was built recently and is missed out from the list above.
General Guidelines:
- We kindly request that vulnerability reports meet certain criteria for consideration. Reports that solely rely on automated tools, scanners, or theoretical attack descriptions without accompanying proof of exploitability will unfortunately not be accepted.
- To enhance the quality of your submission, please include step-by-step instructions that allow us to replicate and validate the reported vulnerability. A functional proof of concept should be demonstrated to showcase the exploit.
- Please ensure that your submission contains sufficient and pertinent details to facilitate a comprehensive understanding of the vulnerability. Submissions lacking in this regard will regrettably be declined.
- Given that our websites share a common stack, vulnerabilities that affect multiple websites will be treated as a single report when determining bounty eligibility.
- IMPORTANT: We kindly request that communication occurs solely via email. Attempts to contact Brainstorm Force team members via personal phone numbers for updates or inquiries regarding your report may result in a ban and disqualification of your report.
- IMPORTANT: For all communication, please use the designated email address provided above. Contacting other Brainstorm Force team members in an attempt to escalate the bug bounty report may lead to a ban and the disqualification of your report. Your adherence to these guidelines is greatly appreciated.
Qualifying Vulnerabilities:
Any reproducible vulnerability that affects the security of our users is likely to be in scope for the program. Common examples include:
- Cross Site Scripting (XSS)
- Cross Site Request Forgery (CSRF)
- Server Side Request Forgery (SSRF)
- Remote Code Execution (RCE)
- SQL Injection (SQLi)
- Privilege Escalation
Exclusion List:
- We are generally not interested in DoS vulnerabilities that are perceived by a lack of rate-limiting or captcha. As a web-scale service, our threshold for rate limiting is higher than you would probably expect. Of course, if you think you have found an exception to this rule, please let us know.
- Any contact or support forms
- Anything SSL (related attacks, insecure cipher suites, etc.)
- Weak Captcha / Captcha Bypass
- Username / Email Enumeration
- Brute Force attacks on our Login or Forgot Password pages
- Account lockout enforcement and related attacks
- HTTP security headers and Cookies related Issues
- Weak password policies
- CSRF on forms that are available to anonymous users (e.g. login or contact forms)
- Clickjacking
- Anything related to Mail Server Domain Misconfiguration (Email spoofing, missing DMARC, SPF/DKIM, etc.)
- Vulnerabilities impacting only old or end-of-life platforms, browsers and plugins
- Cross Site Scripting (XSS) is out of scope for all impactless domains.
- Missing Best Practices that don’t pose a direct security threat will most likely not be accepted.
- We are generally not looking for any reports for our marketing/product websites and would rather prefer reports for the actual products. That being said, If you believe some vulnerability is serious do report it to us, although our security team will review and decide the severity of the report for websites from our prespective.
Crafting a Report:
If our team cannot reproduce and verify an issue, a bounty cannot be awarded. To help streamline our intake process, we ask that submissions include:
- Description of the vulnerability
- Steps to reproduce the reported vulnerability
- Proof of exploitability (e.g. screenshot, video)
- Perceived impact to another user or the organization
- Proposed CVSSv3 Vector & Score (without environmental and temporal modifiers)
- List of URLs and affected parameters
- Other vulnerable URLs, additional payloads, Proof-of-Concept code
- Browser, OS and/or app version used during testing
- Impact of the bug
Security reports should be sent to [email protected]
Once again, thank you for helping us improve security. We really appreciate it.
Vulnerability Disclosure Policy:
Brainstorm Force follows a 90+30 disclosure deadline policy similar to Google’s Project Zero.
This means that we have 90 days after being notified about a security vulnerability to make a patch available to our users. If we make a patch available within 90 days, you can disclose the details of the vulnerability 30 days after the patch has been made available to our users.
For example:
- If we patch a security issue 5 days after being notified about the vulnerability, the details can be made public on day 35.
- If we patch a security issue 8 days after the reporter notified us about the vulnerability, the details can be made public on day 38.
- If we patch a security issue 47 days after being notified about the vulnerability, details can be made public on day 77.
- If we patch a security issue 83 days after being notified about the vulnerability, details would be made public on day 113.
Essentially, we request a 30-day window before publishing the security advisory article, allowing our users enough time to make updates.
If we are unable to patch an issue within the initial 90 days, you can make the details of the vulnerability public at the end of the 90-day period.