Feedback types and tiers
After users submit feedback, they should wait for the review results. When the users approve the review results, they will get the reward for the corresponding tier. Note: this reward program is only available for users on the whitelist.
Vulnerability submission template
Vulnerability request pack or URL (text, no screen caps) or operation steps (e.g. Settings -> Personal Information -> Image uploading issue).
Loophole payload.
Proof of Vulnerability Risk (rate is given according to risk level).
Defects & suggestions
Severe errors (100 USDT)
Can't complete important functions (e.g. transactions aren't completed, orders can't be placed).
The error spreads and affects the normal operations of other important functions.
App crashes, freezes, and infinite loops caused by unconventional operations (e.g. operations that users won't perform when using the software).
Defects that are unacceptable in appearance (e.g. distortion, compression or deformation of a picture).
Security issues that cause data leakage (e.g. account private info leakage caused by malicious attacks).
General errors (30 USDT)
Defects that don't affect the product operations or cause failure, but have a rather great impact on the product appearance or the next processes.
The secondary functions can't be performed normally.
Interface errors (e.g. The meanings of column names and descriptions in the data window are inconsistent).
Inquiry error or data display error.
Simple input restrictions aren't placed in the front-end for control; (e.g. format display judgment in login and registration should be enabled at the front-end).
Display errors (10 USDT)
Displays aren't decent and don't conform to user behavior:
The interface isn't properly designed.
The description or instruction for a particular function isn't clear.
Language
Language issues (10 USDT)
The grammar of the UI copy is incorrect.
Incorrect use of punctuation.
Typos.
Confusing contents.
Security bugs rules and eligibility
Our bug-bounty program offers five security risk tiers, namely extreme, critical, high, medium, and low. A white hat will be rewarded with up to 1,000,000 USDT 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
Vulnerabilities are classified in five levels depending on possible dangers, namely extreme, critical, high, medium, and low. OKX will evaluate the severity of a reported vulnerability with the following criteria:
Extreme (Web3 only)
Criteria: Affects all users, >60 min downtime, or >$500K potential loss.
Zero-interaction mass compromise of funds/private keys or large-scale data breaches.
Critical
Web2
Remote Code Execution (RCE): Executing arbitrary code on OKX servers
SQL Injection (Core DB): Large-scale data access/modification in OKX’s core production database
Admin Backend Takeover: Gaining critical admin privileges
Mass Account Takeover: Systemic takeover of a large portion of user accounts, typically affecting >50% of users
System Command Execution: Running OS commands on servers
Mobile
Remote Exploits: Remote compromise of app integrity or execution of code on OKX infrastructure.
Mass Data Breach: Unauthorized access to large volumes of user data through application flaws.
Admin Privilege Takeover: Gaining backend administrative access via mobile vectors.
System Command Execution: Executing operating system commands on application servers.
SQL/NoSQL Injection : Exploiting mobile API endpoints to manipulate backend database queries, leading to mass exfiltration/modification of sensitive data (PII, financial info, credentials) or backend system compromise.
Desktop clients
Remote Code Execution (RCE): Execution of arbitrary code on the client or connected server via the desktop application.
Admin Privilege Takeover: Gaining backend administrative control through the client (e.g., server-side SSRF).
System Command Execution: Execution of operating system commands on the client or backend server via misconfigurations or unsafe input handling.
Web3
Criteria: Affects >50% of users, >15 min downtime, or >$100K potential loss.
Remote exploits on validators/contracts or admin takeovers.
High
Web2
Stored XSS Worms: Self-replicating cross-site scripting on critical user-facing pages.
CSRF (Critical Actions): CSRF that leads to account compromise or unauthorized asset actions.
Account Access at Scale: Unauthorized access to multiple user accounts due to flaws in authentication or authorization logic.
SQL Injection (Limited): Extracting specific sensitive data
Source Code Leakage: Exposure of significant backend or internal source code
SSRF (Contextual Impact): SSRF that reaches internal services (SSRF severity is dependent on the impact of the internal access achieved.)
Mobile
CSRF (Critical Actions): CSRF that leads to account compromise or unauthorized asset actions.
SSRF (Contextual Impact): SSRF accessing internal systems or services via mobile endpoints.
Sensitive Data Exposure: Leaking encrypted or sensitive information stored or processed by the app.
Transaction Disruptions: Application flaws that interfere with trade, deposit, or withdrawal flows.
Logic Flaws (Fund Impact): Exploiting application logic to manipulate balances or perform unauthorized transactions.
Source Code Leakage: Exposure of significant application source code.
Unauthorized Operations: Performing unauthorized transactions or financial operations through app exploits.
Desktop clients
CSRF (Account Takeover or Fund Transfers): Forged client requests that result in critical authenticated actions.
SSRF (Contextual Impact): Forged requests from the app to internal services.
Sensitive Data Exposure: Exposure of encrypted seeds or local sensitive data via app functionality.
Transaction Disruptions: Client-side bugs that prevent valid trading, deposits, or withdrawals.
Logic Flaws (Fund Impact): Exploiting client-side logic to manipulate account balances or transfer behaviors.
Web3
Criteria: Affects >30% of users, >10 min downtime, or >$50K potential loss.
Validator issues, fund logic flaws, or code leaks.
Medium
Web2
Stored XSS (Interaction): Persistent cross-site scripting requiring user interaction to trigger.
CSRF (Core Business): CSRF targeting non-critical business actions.
Auth Bypass (Limited): Unauthorized access to backend or user data without financial impact.
Subdomain Takeover: Control of unused subdomains with reputational or phishing risk.
Verification Code Flaws: Weaknesses in login or password reset verification logic.
Sensitive Data Exposure: Disclosure of encrypted or internal user data through accessible interfaces.
Cleartext Credentials: Hardcoded credentials in source code or configuration files, excluding API keys.
Mobile
Stored XSS (Interaction): Persistent cross-site scripting within mobile app components that requires user interaction.
CSRF (Core Business): Cross-site request forgery targeting non-critical business logic.
Auth Bypass (Limited): Unauthorized access to user data or configurations without financial impact.
Local Storage Leaks: Disclosure of sensitive app-stored data, such as session tokens or encrypted credentials.
Verification Flaws: Weaknesses in OTP, login, or reset mechanisms due to insufficient validation or rate limiting.
Cleartext Credentials: Hardcoded secrets in app files, excluding API keys.
Desktop clients
CSRF (Core Business): Forging non-sensitive client actions, such as settings changes.
Auth Bypass (Limited): Gaining unauthorized access to user-level configurations or restricted client views.
Local Storage Leaks: Exposure of exploitable data stored by the client, such as session tokens or authentication secrets, without adequate protection or access control.
Cleartext Credentials: Hardcoded secrets (excluding API keys) embedded in client configurations or binaries.
Web3
Criteria: Requires interaction or limited scope.
Interaction-based wallet exploits or transaction disruptions.
Low
Web2
Reflected XSS: Non-persistent cross-site scripting in URLs or parameters.
DOM/Flash XSS: Client-side cross-site scripting with no backend interaction.
Open Redirects: Redirecting users to external domains without validation.
General Info Leaks: Exposure of internal paths, directories, or debug interfaces.
Common CSRF: CSRF targeting non-sensitive user actions.
HTTP Header Manipulation: Modifying headers with low impact, such as cache behavior or redirects.
Mobile
Component Exposure: Unintended exposure of app components, such as exported Android activities or iOS services.
Open Redirects: Unvalidated redirects in app flows.
HTTP Header Issues: Minor header manipulation with negligible impact.
Desktop clients
Local DoS: Crashing the desktop app via malformed files or inputs.
Minor Misconfigurations: Exposure of temporary or local files with no sensitive data or direct exploitability.
Web3
Criteria: Minimal impact or exploitability.
Node stability issues or minor leaks.
Additional guidelines
IDOR: Must demonstrate ID discovery path, not brute force only.
Mobile: Report once per vulnerability across platforms (iOS/Android).
Duplicates: Same issue in multiple assets = one report.
False positives, low business impact, or non-exploitable bugs will not be rewarded but may be acknowledged.
Out of scope
Reports from automated tools or scanners
False positive SQL Injection without a working PoC demonstrating DB/user name extraction
Spam vulnerabilities, mail spoofing, mail bomb, etc.
Self-XSS
Use of known-vulnerable libraries/components without a working PoC
Clickjacking on pages with no sensitive actions
Cross-Site Request Forgery (CSRF) on unauthenticated or low-impact forms
Attacks requiring MITM, root/jailbreak, or physical access to a user’s device
Previously known vulnerable libraries without a working PoC
CSV injection without demonstrating exploitation
Missing SSL/TLS best practices (e.g. weak ciphers, protocol versions)
Denial of Service (DoS) or service disruption attempts
Content spoofing or text injection without HTML/CSS modification or attack vector
Rate limiting or brute-force issues on non-authentication endpoints
Missing Content Security Policy best practices
Missing HttpOnly or Secure cookie flags
Missing or invalid SPF/DKIM/DMARC records
Vulnerabilities affecting only outdated/unpatched browsers (older than 2 stable versions)
Software version disclosure, banner info, stack traces, or verbose errors
Public 0-days with patches released less than 1 month ago (case-by-case)
Tabnabbing
Vulnerabilities requiring unlikely user interaction
Vulnerabilities already known to internal teams
Best practice recommendations (e.g. hardening suggestions)
WordPress-related vulnerabilities
DLL hijacking without demonstrating privilege escalation
Rate-limit bypass by simply changing IP address or device ID
Address bar, URL, or domain spoofing within mobile in-app browsers (e.g., dApp or WebView-based browsers)
Sensitive data exposure on social media
Internal domain takeovers outside okx.com, okg.com, or oklink.com
Clients (desktop/mobile) not downloaded from official sources in scope
Proof of Reserves being reported as “sensitive document” leak
Reports based only on static analysis of binaries without PoC affecting business logic
Lack of obfuscation, binary protection, or jailbreak/root detection
Certificate pinning bypass on rooted/jailbroken devices
Missing exploit mitigations (e.g., PIE, ARC, Stack Canaries)
Sensitive data in URLs or request bodies when protected by TLS
Path disclosure in binaries
Hardcoded/recoverable app secrets in IPA/APK without business impact
Sensitive data stored in private app directory
App crashes from malformed URL schemes or exported components
Runtime exploits that are only possible in a rooted/jailbroken environment (e.g., via Frida)
Leaked shared links via clipboard
URI leaks caused by malicious apps with permissions
Exposure of API keys without demonstrated security impact (e.g., Google Maps API keys or keys found in our public GitHub repositories)
Third-party services (unless explicitly allowed)
Services not owned by OKX (e.g., cloud provider vulnerabilities)
General rules
Be the first to report the vulnerability.
Provide a clear PoC with reproduction steps.
Avoid testing that affects real user accounts.
Do not perform denial-of-service, spam, or social engineering.
Do not attempt to access or modify user data without permission.
Dispute resolution
If you have any feedback on the reporting process, risk levels, and risk rating, reach out to our customer support team for immediate help.