- Top reward
- $15,000
- Top severity paid
- Critical
- Assets in scope
- 14
- Public CVEs
- 0
- Last change
- No changes yet
At a glance
What to know before you start testing.
- Pays up to $15,000
- for critical bugs.
- Report on HackerOne
- Submit through the program page.
- Replies within 2 days
- As the policy promises.
- Publish after a fix
- Coordinate the timing with the company.
Rewards
What HackerOne lists as the payout for each severity.
| Severity | Relative size | Reward |
|---|---|---|
| Critical |
|
$15,000 from $7,500 |
| High |
|
$7,500 from $3,000 |
| Medium |
|
$3,000 from $1,000 |
| Low |
|
$1,000 from $100 |
- Response
-
Within 2 days
Time to first response (from report submit) - 2 business day
Summarised with AI from the program policy on HackerOne, read 12 Nov 2026, and checked word for word against it. Read the original
Scope
14 assets you may test, 1 excluded.
Web 8
- api.excalls.mobi Critical
- exnessaffiliates.com Critical
- exness.com Medium
- https://my.exness.com/pa/pim/manager High
- https://my.exness.com/webtrading Critical
- my.exness.com Critical
- pay.ibex.exchange Critical
- pwapi.ex2b.com Critical
iOS apps 2
- Exness Investor Critical
- Exness Trade: Online Trading Critical
Android apps 1
- com.exness.android.pa Critical
Products and areas 3
- Any subdomain application issue Critical No bounty
- Any subdomain infrastructure issue Critical No bounty
- External service data leakage Critical No bounty
Out of scope (1)
- stat.* (e.g. stat.exnessaffiliates.com)
Rules
What the policy asks of you, and the bug types it won't reward, quoted from EXNESS (via HackerOne)'s policy.
While testing
-
Please use your own accounts to conduct your research.
-
Do not try to gain access to others' accounts or any confidential information.
-
Uploading files that allow arbitrary commands (i.e. a webshell)
-
Modifying any files or data, including permissions
-
Deleting any files or data
-
Interrupting normal operations (e.g. triggering a reboot)
-
Creating and maintaining a persistent connection to the server
-
Intentionally viewing any files or data beyond what is needed to prove the vulnerability
-
Social engineering directed at the company's employees
-
DoS on EXNESS infrastructure
Not accepted
-
Reports from automatic security scanners without real impact
-
Attacks requiring physical access to a user's device
-
Password and account recovery policies, such as reset link expiration or password complexity
-
Invalid or missing SPF / DKIM records
-
Content spoofing / text injection
-
Login/Logout CSRF
-
Open redirects (except cases with additional impact, e.g. token hijacking)
-
Client DOS (regexp/cookie/..)
-
Same site scripting and similar attacks with questionable impact
-
Any kind of self attacks (self-xss, self-takeover..)
-
Clickjacking
-
Reverse Tabnabbing without XSS
-
API key leaks with no security impact (e.g. Google Maps API key disclosure such as AIza*)
-
Customer’s username bruteforce
-
Email verification skip, using legit functionality
-
Host header injection with no security consequences
-
Wordpress vulnerabilities without PoC
-
Deeplink hijacking
-
Vulnerabilities requiring a rooted, jailbroken, or otherwise modified device
-
Exposure of non-sensitive data on the device
Summarised with AI from the program policy on HackerOne, read 12 Nov 2026, and checked word for word against it. Read the original
Changes
Tracked since 11 Nov 2026. Last checked 4 minutes ago.
No changes yet. When the rewards or scope move, you will see it here and in the RSS feed.
Public CVEs
Published vulnerabilities in this vendor's products, from the NVD.
No CVEs matched yet. We match NVD records by vendor name, so products sold under another name can be missing.
Original policy
Copied from hackerone.com on 12 Nov 2026. The summaries on this page are made from it; the live page may have changed since.
HOW TO SUBMIT BUG REPORT?
A bug report must have the following (including mobile reports):
- Impact - it should describe the REAL impact of vulnerability that may affect our users and company funds or reputation
- Highly detailed description of the discovered vulnerability
- Steps to reproduce
- A working proof-of-concept:
- Exploit code
- Video
- Screenshots
- Web/API requests and responses / traffic logs
- Email address or user ID involved in PoC
- IP address used during testing
- CVSS if applicable
Note: We can close submission as Informative or N/A in cases where we cannot confirm the existence of reported issues (including financial reports).
In case of RCE, SQLi, LFI
Allowed Actions:
- Directly injecting benign commands via the web application or interface (e.g. whoami, hostname, ifconfig)
- Uploading a file that outputs the result of a hard-coded benign command
Please provide the following information:
- Source IP address
- Timestamp, including time zone
- Full server request and responses
- Filenames of any uploaded files, which must include “bugbounty” and the timestamp
- Callback IP and port, if applicable
- Any data that was accessed, either deliberately or inadvertently
Avoid any harmful actions and post-exploitation:
- Uploading files that allow arbitrary commands (i.e. a webshell)
- Modifying any files or data, including permissions
- Deleting any files or data
- Interrupting normal operations (e.g. triggering a reboot)
- Creating and maintaining a persistent connection to the server
- Intentionally viewing any files or data beyond what is needed to prove the vulnerability
- Failing to disclose any actions taken or applicable required information
CVSS Score
When reporting a vulnerability, you can either choose a severity level based on your own judgment of the vulnerability, or you can use the CVSS calculator to give more information about the vulnerability and calculate an exact CVSS score. However, the final severity level will depend on business impact which is defined by Exness.
OUT OF SCOPE VULNERABILITIES:
We do not accept/review reports with/from*:
- Reports from automatic security scanners without real impact
- Attacks requiring physical access to a user's device
- Any physical attacks against Exness property or data centers
- Password and account recovery policies, such as reset link expiration or password complexity
- Invalid or missing SPF / DKIM records
- Content spoofing / text injection
- Issues related to software or protocols not under Exness control
- Reports based on product/protocol version without demonstration of real vulnerability presence
- Reports of missed protection mechanism / best current practice (e.g. no CSRF token, framing/clickjacking protection) without demonstration or explanation of real security impact for user or system
- Login/Logout CSRF
- Using components with known vulnerabilities without an exploit or impact
- Vulnerabilities of partner products or services if EXNESS users / accounts are not affected directly
- Open redirects (except cases with additional impact, e.g. token hijacking)
- Client DOS (regexp/cookie/..)
- Same site scripting and similar attacks with questionable impact
- Any kind of self attacks (self-xss, self-takeover..)
- Clickjacking
- Reverse Tabnabbing without XSS
- Any theoretical vulnerabilities and design principles without real provided impact
- API key leaks with no security impact (e.g. Google Maps API key disclosure such as AIza*)
- Customer’s username bruteforce
- Email verification skip, using legit functionality
- Host header injection with no security consequences
- Wordpress vulnerabilities without PoC
- External service interaction / DNS Lookup to the domain in the Host header - it's standard behavior of Imperva WAF (former Incapsula)
- ###Email enumeration in registration endpoints (only there)
-
Client passwords are not accepted for leaks; only employee passwords are allowed.
Out of scope mobile vulnerabilities:
- Deeplink hijacking
- Vulnerabilities requiring a rooted, jailbroken, or otherwise modified device
- Exposure of non-sensitive data on the device
- Vulnerabilities on third party libraries without showing specific impact to the target application (e.g. a CVE with no exploit)
- Mobile applications’ authentication credentials storage scheme
- Mobile applications’ local authentication flow implementation
* other vulnerabilities may be added in this section later
Public 0-day/1-day vulnerabilities
Public 0-day/1-day vulnerabilities may be considered as Informative within a few days after vulnerability details or exploit publication, if the vulnerability is known to our team from public sources and we are working to mitigate or patch it.
PLEASE DO NOT EVER USE THESE TECHNIQUES WHEN CONDUCTING YOUR TESTS:
- Physical tampering with EXNESS data centers or offices
- Social engineering directed at the company's employees
- Breaking into the company's infrastructure and using the information obtained to report vulnerabilities
- DoS on EXNESS infrastructure
- Brute Forcing or social engineering directed to our clients
VULNERABILITY DISCLOSURE
Vulnerability must be disclosed only in accordance with HackerOne disclosure policy. Request for vulnerability disclosure must be filed via HackerOne report interface. No vulnerability disclosure, including partial, is allowed before vulnerability is disclosed on HackerOne. If any sensitive information including (but not limited to) infrastructure and implementation details, internal documentation procedures and interfaces, source code, user and employees data accidentally obtained during vulnerability research or demonstration must not be disclosed. Intentional access to this information is strongly prohibited.
PROGRAM SCOPE
The program's scope is strictly limited to technical and logical vulnerabilities and issues in the company's services. We are currently offering a reward for finding vulnerabilities in services according to an asset table.
Bugs that are common to all of these domains are always accepted as one bug. If multiple attack scenarios are caused by a single vulnerability, we will review report, but can decline it due to duplication. What if I found vulnerability in EXNESS services that is not within the scope? If you find a vulnerability that does not concern one of the projects listed below, we will be glad to accept and investigate it, but only if it is related to EXNESS. In this case, a reward is granted on a case by case basis for most critical vulnerabilities only. Exness employees, the employees in any of Exness companies group can’t participate in the Exness Bug Bounty Program.
RESPONSE TARGETS
Time to first response (from report submit) - 2 business day Time to triage (from report submit) - 5 business days Time to bounty (from triage) - 1 to 15 business days
HOW ARE BUG REPORTS EXAMINED?
Reports about vulnerabilities are examined by our security analysts. Our analysis is always based on worst case exploitation of the vulnerability, as is the reward we pay. If you prefer to remain anonymous, we recommend using an alias when submitting bug reports. Please remain patient after you submit the report and do not ask for bounties before we investigate the report and resolve bug described in it.
BE ETHICAL WHEN HACKING
Please use your own accounts to conduct your research. Do not try to gain access to others' accounts or any confidential information.