OKEx website
We have noticed that there are scammers imitating OKExs website address for phishing scams. Please make sure you enter the correct address when visiting OKEx:

How to Report Vulnerabilities

  • Reward System

    We designed four risk and reward levels, serious, high, medium, and low, to incentivize white-hats to help us discover possible vulnerabilities. With this system, we hope to build a more stable and reliable trading environment for all users.

    Risk Level Proposed Reward
    Serious 8-10 ETH
    High 5-7 ETH
    Medium 2-4 ETH
    Low 0-1 ETH
  • Risk Level

    Vulnerabilities are classified in four levels depending on possible dangers, namely serious, high, medium, and low. OKEx will evaluate the severity of a reported vulnerability with the following criteria:

    • Serious Vulnerability

      Serious vulnerabilities refer to those occurring in the core system business system (i.e. core control system, domain control, business distribution system, and fortress machine, which can manage a large number of systems) that can cause a large-scale impact, obtain a large number of (depending on the actual situation) business system authorities, access to the administrator rights and control the core system.

      • Manipulation of multiple machines in the Intranet
      • Capture of core backend super administrator rights, which may cause major impacts, such as large-scale leakage of core business data.
    • High-risk Vulnerability
      • Capture of system permission (getshell, command execution, etc)
      • SQL injection to system (backend loophole reports would be downrated, while submission in pack uprated if appropriate)
      • Unauthorized access to sensitive data, including but not limited to bypassing authentication to access the backend, weak backend password, and SSRF that obtains considerable sensitive information from the intranet
      • Random file access
      • XXE loophole that can capture random information
      • Unauthorized operation with fund, bypassing payment logic (successfully exploited)
      • Serious logical design and process loopholes, including but not limited to loopholes that allow random user login and mass modification of account password, as well as logical loopholes that compromise the companys key business, except for verification code blasting
      • Other vulnerabilities that can cause large-scale impact to users, including but not limited to self-propagating stored XSS on important webpages, stored XSS that can obtain and successfully use administrator authentication information
      • Substantial leakage of source codes
    • Medium-risk Vulnerability
      • Vulnerabilities that affect users through interactions, including stored XSS on normal webpages and CSRF in core businesses.
      • Unauthorized operations, including but not limited to bypassing authentication to modify users’ information and modifying users’ configurations.
      • Logical loopholes in verification code that may make blasting through sensitive operations possible, such as random account login and random password retrieval
      • Leakage of locally-stored sensitive encryption data (with effective use)
    • Low-risk Vulnerability
      • Local denial-of-service vulnerabilities, including but not limited to local denial-of-service vulnerabilities on the client (caused by parsing of file formats and network protocols), and issues related to Android component access exposure and general application access
      • General information leakage, including but not limited to web path traversal, system path traversal, and directory browsing, etc.
      • Reflected XSS (including DOM XSS / Flash XSS)
      • Normal CSRF
      • URL redirection vulnerabilities
      • SMS bomb
      • Other low-risk vulnerabilities without proof of harm, such as CORS loopholes that cannot obtain sensitive information
      • SSRF with no echo nor successful use
    • Vulnerabilities Not Accepted Currently
      • SPF email forgery vulnerabilities
      • Vulnerabilities of exhaustive blasting registered user name classes with API
      • Self-XSS / POST reflected XSS
      • Email bomb
      • CSRF issues with non-sensitive operations
      • Other low-risk vulnerabilities
  • Vulnerability Submission Template

    1. Vulnerability request pack or URL (text, no screen caps) or operation steps (e.g. Settings -> Personal Information -> Image uploading issue)
    2. Loophole payload
    3. Proof of Vulnerability Risk (rate is given according to risk level).
  • General Rules of Rating

    1. Multiple loopholes created from the same source are counted as one vulnerability.
      For example, multiple security flaws caused by the same API, multiple webpage loopholes caused by the same publishing system, security vulnerabilities of the entire site caused by the framework, multiple security loopholes caused by pan-domain name resolution, multiple CSRF vulnerabilities caused by multiple APIs overridden in the same system due to failed authentication or token verification, wrong allocation of parameters, documents, and directories, etc.
    2. Reward for a vulnerability report will be given only to the first reporting person.
      Regarding the same vulnerability, if a late reporting person can demonstrate a much larger impact than that done by the first person, both of their reports will be accepted. The first person will share a part of the reward given to the late person.
    3. Details of any vulnerability must not be disclosed, except for those already released on the internet.
    4. Taking advantage of vulnerability testing to harm our users’ interest, business operations, and data security will not be tolerated. OKEx will take legal action against such behaviors.
    5. For any unclear report, OKEx will contact the reporting person to request details, such as URL of the loophole, detailed description in text, as well as screencaps.
    6. Reporting SQL injection requires proof of code injection. A mere error report will not be proceeded.
    7. Weak password issues (except for externally registrable systems):
      • Weak passwords in the same system found by the same person will be merged and treated as one report. (If the vendor has resolved the previous weak password, the subsequent reports will be downrated and merged.)
      • For the default initial password, it will be proceeded as one vulnerability. (For example, if the initial passwords of mailboxes are the same, it will be considered as one vulnerability.)
      • For non-key systems, only the first weak password will be processed. other weak passwords submitted subsequently will be skipped as appropriate.
      • For key system or core businesses, only the first two weak passwords will be rated, and the subsequent weak password issue is degraded or ignored as appropriate.
    8. For vulnerabilities in marginal/abandoned business systems, the risk rating may be downrated as appropriate.
    9. For multiple vulnerabilities that entail contextual relationships, such as accessing the backend with a weak password to carry out SQL injection, one can merge them in one report to increase the overall risk rating. Please do not split the vulnerabilities in multiple reports. Users who performs malicious behaviors, such as splitting or exploiting vulnerabilities, will be penalized with account freeze or even termination.
    10. Vulnerabilities of information leakage, such as information leakage on Github, authorized access to Memcache and Redis, will be rated depending on the effectiveness and sensitivity of information. Leakage of low-harm information, such as paths and phpinfo data, will not be handled.
    11. For vulnerabilities caused by using lower versions of CMS, only the first security issue submitted will be accepted for each vulnerability type.
    12. Do not perform tests on vulnerabilities that may cause business interruption, such as IIS denial of service and slow_http_dos vulnerability tests.
    13. Reports of frontend enumeration and blasting loopholes require evidence of successful cases. For backend blasting loopholes, only reports of successful cases will be accepted. Vulnerability reports of successful blasting but failing to enter the backend will be rejected.
    14. In case a person submits two vulnerabilities found on PC end and app end with the same API and code (even if with different domains), we will merge the two reports as one. We would consider raising the reward to the person who reports a merged case of this kind. If the vulnerabilities are reported by two different persons, they would be counted as repeated reports.
    15. Information leakage-related vulnerabilities (including Github, please indicate in the report why you think they are related to OKEx) that could cause considerable harm would be classified as serious or high risk. Information leakage of online core application service configuration and codes are generally of medium risk. Those which cannot be effectively utilized and are related to non-core businesses are deemed as low risk.
  • Reward Distribution

    Once a vulnerability is confirmed, our customer support will follow up with the reporting person for details. After the vulnerability is corrected, the reward will be distributed to the reporting person’s OKEx account in 1 – 2 working days.

  • Dispute Resolution

    If you have any opinion on the reporting process, risk levels, and risk rating, please contact our customer support for immediate communication.

OKEx uses cookies to improve its website. If you continue to browse our website, you agree with our use of cookies. For more details and how to manage cookies, please see ourPrivacy Policy
Agree, continue
According to the European Unions regulations, all OKEX users have to agree to the following User Agreement to continue to use the website. Thank you.