Introduction

We would like to express our sincere thanks in advance for your submissions of a potential security vulnerability in our systems. Your efforts in contributing to a more secure digital environment are highly valued by our team here at Brainframe.

At Brainframe, we take the security of our systems seriously, and we value the security community. The responsible disclosure of security vulnerabilities helps us ensure the security and privacy of our users.

Guidelines

• We require that all researchers: Make every effort to avoid privacy violations, degradation of user experience, disruption to production systems, and destruction or manipulation of data.
• Only use exploits to the extent necessary to confirm a vulnerability’s presence. Do not use an exploit to compromise or exfiltrate data, establish persistent access, or use the exploit for any nefarious purposes.
• Provide us with a reasonable amount of time to fix the issue before publishing it elsewhere.
• Follow the laws applicable in their location and the location of Brainframe.

Scope

Our responsible disclosure policy applies to the following types of security vulnerabilities:

• Authentication and Authorization Bypasses (resulting in unauthorized access or privilege escalation)
• Insecure Direct Object References (IDOR) allowing unauthorized access to user data or systems
• Business Logic Flaws with a direct, demonstrable impact on user security or data integrity
• Code Injections (SQLi, RCE) that allow direct control over system processes or unauthorized data manipulation
• Local and Remote File Access and Manipulation (LFI, RFI, XXE, SSRF, XSPA) with clear proof of exploitation
• CORS Misconfigurations that pose a significant security risk (i.e., beyond theoretical concerns)
• Sensitive Data Exposure (personal or confidential data with a clear privacy impact)

Reporting a Vulnerability

All reports must include the following to be eligible for consideration and reward:

• Detailed Steps to Reproduce: Clear, step-by-step instructions with accompanying screenshots or video.
• Impact Assessment: Explanation of how the issue affects user security, privacy, or system integrity.
• Proof of Concept (PoC): A working example showing exploitation (not just theoretical) that demonstrates real-world risk.

Submissions that do not meet these criteria may be deemed ineligible for a reward.

We accept vulnerability reports using the following form:

Rewards

Our rewards for eligible vulnerabilities are based on severity, which we will determine based on the information you provide and our assessment. The reward applies only to the first reporter of a vulnerability and duplicate reports will not be rewarded.

We aim to respond to all security reports within 30 days. In some exceptional cases, it may take up to 90 days for you to receive a detailed response and any corresponding reward. This timeline allows us to ensure a thorough investigation and resolution of more complex issues. We appreciate your patience and understanding in this matter. Please note that rewards are granted only when vulnerability reporting complies with this Responsible Disclosure Policy.

In the interim, we kindly request that you maintain the confidentiality of the details of the reported vulnerability. This precautionary measure is vital to prevent potential misuse and provides us with adequate time to implement necessary fixes.

Exclusions

While we encourage any submissions that describe security vulnerabilities in our services, the following types of submissions are excluded from eligibility for a reward:

• Double reports: Anything that has already been reported or identified, for which we will show proof if you send in a duplicate.
• Non-impactful Reports: Missing HTTP security headers, lack of rate limiting without evidence of actual abuse, weak password policies not tied to real-world compromise scenarios.
• Content and Visual Issues: Clickjacking on pages with minimal impact (e.g., static pages), or issues affecting only the user interface without a security impact.
• Vulnerabilities in Development-Only Environments: Issues that do not impact production or result in an actual threat to user data.
• Low-Risk Misconfigurations: Outdated security policies or reports on "best practices" without demonstrable security risks.
• Outdated Libraries or Dependencies: Reports of outdated libraries, frameworks, or dependencies without proof of an exploit path or direct impact on system security.
  

Legal

By participating in Brainframe’s bug bounty program, you acknowledge that you have read and agreed to our policy. As long as your research complies with this policy, we won’t initiate legal action against you in relation to your research.

Acknowledgements

We recognise the importance of the security community and appreciate your interest in helping us keep Brainframe safe for everyone and we want to express our gratitude for your contribution. Your diligence in discovering and reporting this potential vulnerability underscores a level of professionalism and commitment to the security community that we deeply respect.

While we greatly value all efforts to improve our security, we ask researchers to prioritize vulnerabilities that pose significant risk to our users and systems. Your diligence and focus on impactful discoveries are invaluable to us.