Scope rules

=====

The program's scope is limited to technical vulnerabilities in the company's critical web services or mobile apps. To report problems accessing your account or non-security issues, please contact customers support.

A list of the projects can be found here:

Mail.Ru: https://mail.ru/all

My.Com: https://my.com/

We will not pay a reward (and we will be really upset) if we detect:

• Physical tampering with Mail.Ru Group's 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

• Attempt to access arbitrary user's account or data or another vulnerability post-exploitation not required to demonstrate the bug presence

• Distributed network/request flooding and another resources exhaustion attacks. Automated scanning tools must be limited to 5 request per second (300 requests per minute) to one target host summing up all tools and threads running in parallel and must not exceed 5 parallel requests at the same time (5 threads).

Please use your own accounts, phone numbers, etc to conduct your research. Do not try to gain access to others' accounts or any confidential information.

Re-active protection

=====

Remember you are testing production environment which is being used, supported and monitored. To prevent negative reaction, conduct your research in responsible, less intrusive way and reasonably limit impact from your tests for users, moderators and administrators.

Aggressive security scans and tests may trigger alerts and result in re-active measures being enforced, e.g. account, phone number or IP may be blocked. Automated abuse reporting tools are not used by Mail.ru, but in some cases, if attack resembles the real intrusion attempt manual abuse report may be sent by administrator.

We believe moderation and monitoring processes must not be impacted by bug bounty and security team does not interfere with moderation and abuse reporting decisions for individual cases.

How do I submit a bug report?

=====

A bug report must give a detailed description of the discovered vulnerability and brief steps to reproduce it, or a working proof-of-concept. Video and screenshots can illustrate bug report, but can not replace it.

If you do not describe the vulnerability in sufficient detail, the discovery process is significantly prolonged and that doesn't help anybody. It's also very desirable if researcher can explain how exactly he or she found a given vulnerability.

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.

Reports are reviewed within 15 days (this is a maximum period - we'll probably respond sooner).

If you prefer to remain anonymous, we recommend using an alias when submitting bug reports.

Participating reports

=====

Only reports reported via bug bounty platform interface may be considered for a bounty. A date/time of report on bug bounty platform is considered as a date/time of the report.

Duplicate reports

=====

Different exploitation vectors for the same bug or similar bugs may be considered duplicating if security team believes information provided for a single vector/bug is enough to fix all vectors or bugs reported.

Report for known or duplicating vulnerability is considered as Duplicate. Duplicate report is not eligible for monetary reward. Report can be either a duplicate of another report from any bug bounty platform or a duplicate of the problem internally tracked by Mail.Ru security team. Usually, access to original report or some information from internal task tracker is provided to reporter of Duplicate. In some cases information may not be provided, if a Duplicate contains less information or less critical exploitation vector than original report.

The report is considered as a duplicated to another report from any bug bounty platform, if there is original report is in "New" or "Triaged" state with an earlier report date/time or lower report number of if it updates the report in "N/A" or "Need more info" state and original report is in "N/A" or "Need more info" state for less than 1 week or sufficient information is provided in original report by researcher since the report is transferred to "N/A" or "Need more info" state.

The report is considered as a duplicate to internal task if there is a task in internal task tracker which is tracked by Mail.Ru security team on the time of the duplicate report.

Also, public 0-day/1-day vulnerabilities may be considered as a duplicate within few days after vulnerability details publication, if vulnerability is known to our team from public sources and we are working to mitigate or patch it.

Invalid reports

=====

Report in "N/A" or "Need more info" state which is stale in this state for more than a week without sufficient new information provided is considered as invalid and does not participate in bug bounty.

Reward payment

=====

We will pay you a reward if you are the first person to report a given vulnerability.

The bounty decision will be made within 30 days after triage (this is a maximum period - we'll probably award sooner). A message will appear in your bug report, indicating that the vulnerability you reported has been confirmed and a reward has been granted.

Payments are made through HackerOne.

Vulnerability disclosure

=====

Vulnerability must be disclosed only with accordance with bug bounty platform disclosure policy.

Request for vulnerability disclosure must be submitted via bug bounty platform report interface. We usually disclosure reports within 4 weeks after disclosure request or fixing time, but we can request up to 3 months of additional time before vulnerability details are published. This time is required to distribute the fixed version and check it for regressions.

No vulnerability disclosure, including partial is allowed before vulnerability is disclosed on bug bounty platform.

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.

Mail.ru does not disclosure and do not grant you any rights to disclosure vulnerabilities in 3rd party products or services, unless these rights are explicitly given to you by affected 3rd party.