HOW TO SUBMIT BUG REPORT?

A bug report must have:

• Highly detailed description of the discovered vulnerability

• Steps to reproduce

• A working proof-of-concept:

• Exploit code

• Video

• Screenshots

• Traffic logs

• Web/API requests and responses

• Email address or user ID involved in PoC

• IP address used during testing

• CVSS if applicable

• Possible impact - It should briefly describe the REAL impact of vulnerability that may affect our users and company funds or reputation

In case of RCE, SQLi, LFI

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 destructive 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

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

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 enumeration/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)

• 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 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.