Program rules and policy
• Please provide detailed reports with reproducible steps.
• Submit a separate report for each discovered vulnerability unless you need to chain several vulnerabilities.
• When duplicates occur, we only reward the first report that we receive (provided that the vulnerability described in the report can be fully reproduced).
• Include vulnerabilities that share a similar cause in a single report (for example, if you discover a vulnerability in a library used in multiple domains within the scope).
• If fixing a vulnerability reported earlier also fixes the vulnerability described in a later report, only the former report will be rewarded.
• Avoid actions that might result in privacy violations, destruction of data, or interruption or degradation of our services. Use only your own accounts. You can interact with the accounts of other users only if they explicitly consent to it.
• Do not run scans that may lead to degraded performance or denial of service of the target applications.
• When testing our email service, register your account by specifying an external email address that includes "bugbounty" so that we know you are not a malicious actor.
• Do not open or modify our clients' accounts.
• Do not carry out social engineering attacks, including phishing.
• Do not spam.
• Do not conduct physical attacks of any kind.
• After gaining initial access, participants are forbidden from lateral movement and post-exploitation.
• We accept reports of 0-day vulnerabilities if the vulnerabilities were publicly disclosed more than two weeks before the report submission.
• RCE, SQL, and SSRF vulnerabilities discovered outside of the critical infrastructure will receive smaller rewards. Within the critical infrastructure, the host rm.rambler-co.ru (10.99.2.223) must be available; the expected response is 302.
Report requirements
The report must be exhaustive and intelligible to the reviewer. It must include all the steps, commands, and dependencies necessary to reproduce the vulnerability. Provide detailed steps that specify what is vulnerable and how it can be exploited. You must also present evidence that backs up your findings, such as screenshots of requests and results or videos demonstrating the entire attack kill chain.
Be sure to describe the potential risks related to the vulnerability. We would appreciate it if you would also provide recommendations for remediation.
Since lateral movement is prohibited, some vulnerabilities can be demonstrated with the following data:
• SQL injection: database version.
• XXE or XML injection: demonstration of XXE without DoS.
• XSS: output of the alert or log message.
• RCE: hostname, id, ifconfig.
• SSRF: curl to the internal domain (rm.rambler-co.ru (10.99.2.223); the expected response from the host is 302).
Rewards
The rewards we offer are based on the CVSS 3.0 vulnerability scoring system, but we also use our own vulnerability management policy that defines severity levels differently. The relevant severity score ranges are provided in the table below.
| Severity level | Reward |
|---|
| Critical (9.9–10.0) | ₽55,000–₽150,000 |
| High (8.0–9.8) | ₽30,000–₽55,000 |
| Medium (4.0–7.9) | ₽3,000–₽25,000 |
| Low (0.1–3.9) | ₽0–₽3,000 |
Vulnerabilities
We prioritize the following critical vulnerabilities:
• RCE
• Injections
• SSRF
• LFI/RFI
• XXE
LiveJournal
Researchers are welcome to report vulnerabilities in this domain:
•
www.livejournal.com
as well as vulnerabilities in domains on the subnet 81.19.74.0/24.
Rewards are only provided for server-side vulnerabilities of high and critical severity. Vulnerabilities that mainly expose clients (XSS, CSRF, and so on)—unless high-privilege accounts are targeted (for example, XSS in the admin panel)—will be considered, but no reward is provided for them.
Out-of-scope submissions and vulnerabilities
• Clickjacking.
• Login/Logout CSRF.
• Man-in-the-middle (MITM) attacks.
• Use of social engineering methods.
• Self-XSS.
• Any malicious activities that may lead to denial of service.
• Output of automated scanners without a viable proof of concept (PoC).
• HTTP header injections without significant impact (including CRLF).
• SPF, DKIM, or DMARC misconfigurations.
• Lack of SSL/TLS best practices.
• Attacks that require physical access to the company's equipment.
• Vulnerabilities in third-party libraries without immediate security impact.
• Lack of other best practices without immediate security impact.
• Vulnerabilities only applicable to outdated browser versions.
• Obsolete DNS entries.
• Lack of security flags in non-critical cookies.
• Information leaks through the Referer header.
• Information leaks through /status or /metrics without demonstrable security impact.
The following vulnerabilities will be accepted as Informative unless they impose direct or indirect financial risks:
• Open redirect vulnerabilities if they are not associated with a more critical attack vector.
• Vulnerabilities that can be exploited to drive up user metrics (such as ratings, reactions, and number of followers or reposts) but do not lead to direct financial losses (for example, as in the case of a prize contest), excluding CSRF.