CEX.IO Web & Mobile: Program info

IN SCOPE VULNERABILITIES: WEB & MOBILE VULNERABILITIES

We are interested in the following vulnerabilities:

• Business logic issues
• Payments manipulation
• Remote code execution (RCE)
• Injection vulnerabilities (SQL)
• File inclusions (Local & Remote)
• Access Control Issues (IDOR, Privilege Escalation, etc)
• Leakage of sensitive information
• Server-Side Request Forgery (SSRF)
• Cross-Site Request Forgery (CSRF)
• Cross-Site Scripting (XSS)
• Directory traversal
• Other vulnerabilities with a clear potential loss

OUT OF SCOPE: WEB VULNERABILITIES

Vulnerabilities found in out of scope resources are unlikely to be rewarded unless they present a serious business risk (at our sole discretion). In general, the following vulnerabilities do not correspond to the severity threshold:

• Assets that do not belong to the company

• Best practices concerns

• Recently (less than 30 days) disclosed 0day vulnerabilities

• Vulnerabilities affecting users of outdated browsers or platforms

• No social engineering, phishing, spamming, any brute force attacks, password spraying, or physical security testing

• No Email verification code flaws, expired password reset links, and issues with password complexity policies

• No Clickjacking and UI redirection with only minor security impact

• No Vulnerabilities in third-party applications

• No Denial of service (DOS and DDOS) attacks

• No Email/phone number information enumeration (e.g. resetting passwords to verify emails or phone numbers)

• No Attacks requiring physical access to the user’s device or CEX.IO offices.

• If you have found a security issue that directly affects a cryptocurrency and/or its components (e.g., layer-1 blockchain protocols, nodes, wallet structures not controlled by CEX.IO), please report it directly to the respective project team.

• Publicly accessible login panels without proof of exploitation

• Reports that state that software is out of date/vulnerable without a proof of concept

• Reports generated by scanners or any automated or active exploit tools

• Vulnerabilities involving active content such as web browser add-ons

• Most brute-forcing issues without clear impact

• Theoretical issues

• Moderately Sensitive Information Disclosure

• Spam (sms, email, etc)

• Missing HTTP security headers

• Infrastructure vulnerabilities, including:

  • Certificates/TLS/SSL-related issues;
  • DNS issues (i.e. MX records, SPF records, DMARC records etc.);
  • Server configuration issues (i.e., open ports, TLS, etc.)

• Open redirects

• Session fixation

• User account enumeration

• Clickjacking/Tapjacking and issues only exploitable through clickjacking/tapjacking

• Descriptive error messages (e.g. Stack Traces, application or server errors)

• Self-XSS that cannot be used to exploit other users

• Login & Logout CSRF

• Weak Captcha/Captcha Bypass

• Lack of Secure and HTTPOnly cookie flags

• Username/email enumeration via Login/Forgot Password Page error messages

• CSRF in forms that are available to anonymous users (e.g. the contact form)

• OPTIONS/TRACE HTTP method enabled

• Host header issues without proof-of-concept demonstrating clear security impact

• Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS

• Content Spoofing without embedded links/HTML

• Reflected File Download (RFD)

• Mixed HTTP Content

• HTTPS Mixed Content Scripts

• Manipulation with Password Reset Token

• MitM and local attacks

• Response manipulations without demonstration of system state change

OUT OF SCOPE: MOBILE VULNERABILITIES

• Attacks requiring physical access to a user's device
• Vulnerabilities that require root/jailbreak
• Vulnerabilities requiring extensive user interaction
• Exposure of non-sensitive data on the device
• Reports from static analysis of the binary without PoC that impacts business logic
• Lack of obfuscation/binary protection/root (jailbreak) detection
• Bypass certificate pinning on rooted devices
• Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries
• Sensitive data in URLs/request bodies when protected by TLS
• Path disclosure in binary
• OAuth & app secret hard-coded/recoverable in IPA, APK
• Sensitive information retained as plaintext in the device’s memory
• Crashes due to malformed URL Schemes or Intents sent to exported Activity/Service/Broadcast Receiver
• Any kind of sensitive data stored in-app private directory
• Runtime hacking exploits using tools like but not limited to Frida/Appmon (exploits only possible in a jailbroken environment)
• Shared links leaked through the system clipboard
• Any URIs leaked because a malicious app has permission to view URIs opened.
• Exposure of API keys with no security impact (Google Maps API keys etc.)
• Reports that bypass rate limiting through changing of IP addresses/Device IDs
• Address bar/URL/domain spoofing in dApp browser
• Reports with mobile versions not downloaded from official sites listed in our scope

General Requirements:

• Avoid using web application scanners for automatic vulnerability searching which generates massive traffic
• In case you find chain vulnerabilities we’ll pay only for vulnerability with the highest severity.
• Don’t break any law and stay in the defined scope
• Any details of found vulnerabilities must not be communicated to anyone who is not a HackenProof Team or an authorized employee of this Company without appropriate permission
• Submit a working proof of concept (PoC) that safely demonstrates the issue without impacting real users or data. Include exact reproduction steps, affected endpoints/parameters, sample requests/responses, and any prerequisites.
• Do not access customer or employee personal information. If you accidentally access any of these, please stop testing and submit the vulnerability.
• Stop testing and report the issue immediately if you gain access to any non-public application or credentials.
• Do not disrupt production systems, or destroy, or alter data during security testing.
• Collect only the information necessary to demonstrate the vulnerability.
• Submit any necessary screenshots, screen captures, network requests, reproduction steps(do not use third party file sharing sites).
• When investigating a vulnerability, please only target your own account and do not attempt to access data from anyone else’s account as this will contradict the CEX.IO Terms of Use.
• When investigating a vulnerability, please avoid the destruction of data.
• You are not allowed to exploit a security vulnerability for any other way than prescribed in this Policy.
• Only the first verified vulnerability report can receive the reward.

Testing Requirements:

• Only non-intrusive testing is permitted. Researchers must avoid any testing that could negatively impact the availability, performance, or integrity of systems in scope.
• Remote code execution (RCE). Please limit PoC to safe commands (e.g., id, whoami). Do not attempt persistence, data exfiltration, or destructive actions.
• Limit your work to proof-of-concept validation for the following classes: XSS, Open Redirect, CSRF, and Improper Access Control.
• Do not perform destructive actions, including mass enumeration of any authorization data, data exfiltration, or service degradation.
• Use only accounts and data you own. Do not target third-party services, production customer records, or employees. If you encounter sensitive data, stop, do not access further, and report only a redacted sample.
• Respect rate limits: manual testing preferred; automated tools must stay below 1 request/second and 200 requests total per test.
• For XSS, provide a harmless PoC (e.g., alert('XSS')) and the exact payload, sink, and context; no credential theft or scanning.
• For Open Redirect, show a redirect to https://cex.io and include the affected parameter and validation bypass.
• For CSRF, demonstrate a state-changing action on your account only with token handling details.
• For Access Control, show the minimal request that bypasses authorization and limit access to your resources; no bulk access. Include clear repro steps, affected endpoints, parameters, evidence, and impact.

To help streamline our intake process, we ask that submissions include:

• Vulnerability Types and Description of the vulnerability
• Steps to reproduce the vulnerability
• Proof of use (e.g. any necessary screenshots, screen captures, network requests,)
• Vulnerability Exploitation Probability
• List of URLs and affected payload parameters
• Other additional payloads, Evidence of Vulnerability, Solutions
• Browser version, OS and/or app version used for testing

Note: Failure to comply with these requirements or the provision of knowingly false information may result in ineligibility for a bounty and/or removal from the program.

• Do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization
• No vulnerability disclosure, including partial is allowed for the moment.
• Platform-Only Disclosure: Disclosure is only possible through the HackenProof Disclosure function.
• Researchers may request disclosure (Limited or Full) within the report ticket;
• We reserve the right to approve, redact, or deny disclosure requests at our sole discretion.
• Mutual Required: Any publication requires explicit mutual agreement. Reports must remain Private until the status is officially changed to "Public" on the HackenProof platform by the team.

We are happy to thank everyone who submits valid reports which help us improve the security. However, only those that meet the following eligibility requirements may receive a monetary reward:

• You must be the first reporter of a vulnerability.
• The vulnerability must be a qualifying vulnerability
• Any vulnerability found must be reported no later than 24 hours after discovery and exclusively through hackenproof.com
• You must send a clear textual description of the report along with steps to reproduce the issue, include attachments such as screenshots or proof of concept code as necessary.
• You must not be a former or current employee of us or one of its contractor.
• ONLY USE the EMAIL under which you registered your HackenProof account (in case of violation, no bounty can be awarded)
• Provide detailed but to-the point reproduction steps
• AI-generated reports without runable PoC are not accepted under this program.