What is the Bybit Bug Bounty program methodology and how can you participate in the program?

The Bybit Bug Bounty program is designed to reward individuals who identify vulnerabilities in Bybit's platform. If you notice any potential vulnerability or bug, you can participate in the program by following these steps:

 

Step 1: Consolidate all your findings in a neat and organized format. Providing GIFs or video recordings of the bug will be most appreciated. 

 

Step 2: Submit your security report and findings via this form and select the option “API Trading / Report a Security Vulnerability”.

 

For video recordings, please upload it to Google Drive and send us the shareable link. For more information on how to do so, please visit here.

 

 

 

Are the LazarusBounty Program and Bybit Bug Bounty Program the same?

No, they are not the same bounty program. The LazarusBounty Program is designed for those who assist in identifying and freezing illicit funds, whereas the Bybit Bug Bounty Program is designed for those who notice and submit reports of vulnerabilities on Bybit. 

For more detailed information on LazarusBounty Program, please refer to this article.

 

 

• Program Rules
• Details on Vulnerability Levels
• Prohibited Behaviors
• Out of scope vulnerabilities
• Disclosure Policy

 

 

 

Program Rules

1. Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.

2. Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.

3. When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).

4. Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.

5. Social engineering (e.g. phishing, vishing, smishing) is prohibited.

6. Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.

7. Avoid employing automated scanning tools, as submissions identified through such means cannot be accepted.

8. Avoid negatively impacting or disruptive actions that may affect the availability of our services (e.g. DoS/DDoS)

9. Test Plan

• If you are interested in testing our asset-related features but lack the necessary assets to conduct testing, you can register accounts and apply test tokens in the asset dashboard via https://testnet.bybit.com. (*Please note that Testnet utilizes test coins that hold no real value. To ensure our users enjoy an optimal experience with our products, we've opted not to impose stringent 2FA restrictions. Consequently, reports of bypassing 2FA on the Testnet will not be accepted).

• Web3-related assets, please refer to https://www.bybit.com/web3/home.

 

 

 

 

 

Details on Vulnerability Levels

What is the bug bounty given out when a vulnerability is approved?

Please refer to the table below for the bug bounty available based on the level of the vulnerability detected.

 

 

 

 

How are the various levels of bugs/vulnerabilities defined?

Please refer to the list below for more information:

 

Critical Vulnerabilities

A critical vulnerability refers to one that occurs in the core business system (the core control system, field control, business distribution system, fortress machine or other locus of control that can manage a large number of systems). It can cause a severe impact, gain business system control access (depending on the actual situation) or core system management staff access, and even control the core system.

 

A critical vulnerability includes, but is not limited to:

• Multiple devices access the internal network

• Gaining core back-end super administrator access, leaking enterprise core data, and causing severe impact

• Smart contract overflow and conditional competition vulnerability

 

 

High-Risk Vulnerabilities

• Gain system access (getshell, command execution, etc.)

• System SQL injection (back-end vulnerability degradation, prioritization of package submission as appropriate)

• Gaining unauthorized access to sensitive information, including but not limited to direct access to the management background by bypassing authentication, brute force attackable back-end passwords, or obtaining SSRF of sensitive information in the internal network, etc.

• Arbitrary document reading

• XXE vulnerability that can access any information

• Unauthorized operation that involves money or payment logic bypassing (needs to be successfully utilized)

• Serious logical design defects and process defects. This includes, but is not limited to, any user login vulnerability, vulnerability of batch account password modification, logic vulnerability involving enterprise core business, etc., except for verification code explosion

• Other vulnerabilities that affect users on a large scale. These include but are not limited to the storage XSS that can be automatically propagated on the important pages, and the storage XSS that can access administrator authentication information and be successfully utilized

• Leakage of source code

• Permission control defects in the smart contract

 

 

Medium-Risk Vulnerabilities

• A vulnerability that can affect users by interaction, including but not limited to storage XSS on general pages, CSRF involving core business, etc.

• General unauthorized operation, not limited to modifying user data and performing user operation by bypassing restrictions

• Denial-of-service vulnerabilities, including but not limited to remote denial-of-service vulnerabilities caused by denial-of-service of web applications

• Vulnerabilities caused by a successful explosion with the system-sensitive operation, such as any account login and password access, etc., due to verification code logic defects

• Leakage of locally stored, sensitive authentication key information, which needs to be available for effective use

Low-Risk Vulnerabilities

• Local denial-of-service vulnerabilities include but are not limited to, client local denial-of-service (parsing file formats, crashes generated by network protocols), problems caused by Android component permission exposure, general application access, etc.

• General information leakage is not limited to Web path traversal, system path traversal, directory browsing, etc.

• XSS (including DOM XSS/Reflected XSS)

• General CSRF

• URL skip vulnerability

• SMS bombs, mail bombs (each system only accepts one type of this vulnerability).

• Other vulnerabilities that are less harmful (and cannot be proven to be, such as CORS vulnerability that cannot access sensitive information) 

• No return value and no in-depth utilization of successful SSRF

 

Prohibited Behaviors

• Conducting social engineering and/or engaging in phishing

• Leaking details of a vulnerability

• Vulnerability testing is limited to PoC (proof of concept), and destructive testing is strictly prohibited. If harm is caused inadvertently during the testing, it should be reported in time. Meanwhile, sensitive operations performed during the test, such as deletion, modification, and other operations, must be explained in the report

• Using a scanner for large-scale scanning. If the business system or network becomes unavailable, it will be handled according to relevant laws

• Those who test the vulnerability should try to avoid modifying the page directly, continuing to pop up the message box (DNSLog is recommended for xss verification), stealing cookies, and/or obtaining an aggressive payload such as user information (for blind xss testing, please use dnslog). If you accidentally use a more aggressive payload, please delete it immediately. Otherwise, we have the right to pursue related legal liabilities.

 

 

 

 

 

Out of scope vulnerabilities

When reporting vulnerabilities, please consider (1) the attack scenario/exploitability, and (2) the security impact of the bug. The following issues are considered out of scope:

• Any activity that could lead to the disruption of our service (DoS, DDoS).

• Social engineering of our employees or contractors, unless explicitly authorized.

• Attacks against our physical facilities, unless explicitly authorized.

• Attacks requiring physical access to a user’s device, unless the device is in-scope and explicitly hardened against physical access.

• Attacks requiring disabling Man In The Middle (MITM) protections.

• Attacks only affect obsolete browsers or operating systems.

• Missing best practices (SSL/TLS configuration, Content Security Policies, cookie flags, tabnabbing, autocomplete attribute, email SPF/DKIM/DMARC records), unless a significant impact can be demonstrated.

• Clickjacking or Cross-Site Request Forgery (CSRF) on unauthenticated pages/forms with no sensitive actions.

• Open redirects, unless a significant impact can be demonstrated.

• Self-exploitation (self XSS, self-denial-of-service, etc.), unless a method to attack a different user can be demonstrated.

• Content spoofing, text injection, and CSV injection, unless a significant impact can be demonstrated.

• Software version disclosure / Banner identification issues / Descriptive error messages or stack traces.

• Issues that require unlikely user interaction by the victim.

• Any attack that requires a user to interact with a contract from an attacker controlled website

• Chain specific vulnerabilities are excluded, (e.g. EVM or Solana runtime issues)

• Integrated Dapp vulnerabilities are excluded (e.g. Uniswap, Curve, GMX, 1inch)

 

 

 

 

 

Disclosure Policy

Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization.