## 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.
- Be sure to 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.
- 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, you must not proceed with lateral movement or post-exploitation.
- We accept reports of 0-day vulnerabilities if the vulnerabilities were publicly disclosed more than two weeks before the report submission.
- Reports of 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 from the host 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.
- The report must 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 amount        |
|-------------------|----------------------|
| Critical (9.9–10) | ₽500,000             |
| High (8.0–9.8)    | ₽35,000–₽150,000     |
| Medium (4.0–7.9)  | ₽5,000–₽35,000       |
| Low (0.1–3.9)     | Up to ₽5,000         |

## Severity scoring criteria
We classify vulnerabilities as critical only if they allow access to the corporate network. Therefore, we ask program participants to prove each instance of network penetration by receiving a response from https://rm.rambler-co.ru (10.99.2.223); the expected response from this host is 302.
In addition to that, attacks on Rambler ID resulting in a full leak of user accounts and data are also considered critical.
We rate the following attacks as high-severity:
		1. Attacks that lead to the compromise of a user account and require no more than a single action by the user for successful exploitation. 
		2. Attacks that lead to the compromise of a high-privileged user account—in particular, stored XSS and cache poisoning.
		3. Attacks on users that lead to further attacks on id.rambler.ru.
	The severity of other attacks is determined based on their CVSS scores.


## Vulnerabilities
We prioritize the following critical vulnerabilities:
- RCE
- Injections
- SSRF
- LFI/RFI
- XXE

### Notes on reporting certain types of vulnerabilities
**XSS** 
  1. The severity of an XSS vulnerability can be rated as High only if it is a stored XSS vulnerability in internal services (such as the admin panel or support panel).
  2.  If you find several XSS vulnerabilities in the same forms and locations, but in different settings, describe them in a single report.
  3. It is highly appreciated when the report includes a video demonstrating vulnerability exploitation or a detailed description with screenshots.

**CRLF**
  1. Reports on CRLF vulnerabilities are accepted if they have a security impact other than setting of arbitrary cookies.
  2. If you set arbitrary HTTP headers, the attack vector described in the report must be realistic.
  3. If you inject HTML tags, it must be demonstrated right in the browser (simply providing the server response from Burp Suite or similar tools is not enough).

**DoS**
  1. DoS vulnerabilities must be reported as software vulnerabilities with a CVE identifier.
  2. For a DoS vulnerability report to be accepted, no PoC is required—you can just indicate the vulnerable software version used, with supporting evidence.

**CVE**
  1. When reporting a CVE-\d\d\d\d-[0-9]* vulnerability, please include a PoC and vulnerability description with references to authoritative sources such as MITRE.
  2. If you find a vulnerable version of a dependency, library, infrastructure software, and so on, specify the method used to determine the version, if possible.
  3. Vulnerability reports that do not include a PoC (except for DoS vulnerability reports) will not be accepted.


## Out-of-scope submissions
- 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), except for CSRF.


## Vulnerability disclosure policy
This program allows for the disclosure of discovered vulnerabilities **with the permission of the company's representative no sooner than 30 days after the report submission date**. The company also reserves the **right to refuse or indefinitely delay publication of the report** without explanation.

## Scope
- *.afisha.ru
- *.daily.afisha.ru
- *.eda.ru
(Notes on special projects within the scope: Subdomains of the main project may host special projects with low criticality that are not included in the scope of this program. To verify whether a domain is within the program scope, you can check if its IP address falls within the range of the subnet 81.19.64.0/19. Reports on vulnerabilities found in domains with IP addresses from other subnets are accepted either without a reward or with a lower severity level assigned.)

## Domains outside the scope:
- school.eda.ru

Afisha

Afisha company runs the Afisha.ru media service, Afisha Daily media outlet, Afisha Picnic festival, Afisha Restaurants project, Eda.ru website, and Afisha mobile applications. On Afisha.ru, you can always find up-to-date information about various offline and online activities—movies, concerts, theater performances, and exhibitions—and purchase tickets for events of interest.

Rambler&Co ranks first among media holdings in Russia by monthly audience size, with over 47.7 million people (according to Mediascope, Cross Web, March 2022). It includes Lenta.ru, Gazeta.Ru, the Rambler portal, Championat, Sekret Firmy, Motor.ru, Ferra.ru, and several other media assets. Due to the diverse thematic focus of its platforms, the holding covers almost the entire spectrum of interests and needs of various audiences.

Rambler&Co

## 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.
- Be sure to 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, you must not proceed with lateral movement or post-exploitation.
- We accept reports of 0-day vulnerabilities if the vulnerabilities were publicly disclosed more than two weeks before the report submission.
- Reports of 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 from the host 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.
- The report must 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 amount        |
|-------------------|----------------------|
| Critical (9.9–10) | ₽500,000             |
| High (8.0–9.8)    | ₽35,000–₽150,000     |
| Medium (4.0–7.9)  | ₽5,000–₽35,000       |
| Low (0.1–3.9)     | Up to ₽5,000         |


## Severity scoring criteria
We classify vulnerabilities as critical only if they allow access to the corporate network. Therefore, we ask program participants to prove each instance of network penetration by receiving a response from https://rm.rambler-co.ru (10.99.2.223); the expected response from this host is 302.
In addition to that, if a participant manages to conduct an attack on Rambler ID through the program's scope, only a vulnerability leading to a full leak of user accounts and data will be considered critical.
We rate the following attacks as high-severity:
		1. Attacks that lead to the compromise of a user account and require no more than a single action by the user for successful exploitation. 
		2. Attacks that lead to the compromise of a high-privileged user account—in particular, stored XSS and cache poisoning.
		3. Attacks on users that lead to further attacks on id.rambler.ru.
	The severity of other attacks is determined based on their CVSS scores.


## Vulnerabilities
We prioritize the following critical vulnerabilities:
- RCE
- Injections
- SSRF
- LFI/RFI
- XXE


### Notes on reporting certain types of vulnerabilities
**XSS** 
  1. The severity of an XSS vulnerability can be rated as High only if it is a stored XSS vulnerability in internal services (such as the admin panel or support panel).
  2.  If you find several XSS vulnerabilities in the same forms and locations, but in different settings, describe them in a single report.
  3. It is highly appreciated when the report includes a video demonstrating vulnerability exploitation or a detailed description with screenshots.

**CRLF**
  1. Reports on CRLF vulnerabilities are accepted if they have a security impact other than setting of arbitrary cookies.
  2. If you set arbitrary HTTP headers, the attack vector described in the report must be realistic.
  3. If you inject HTML tags, it must be demonstrated right in the browser (simply providing the server response from Burp Suite or similar tools is not enough).

**DoS**
  1. DoS vulnerabilities must be reported as software vulnerabilities with a CVE identifier.
  2. For a DoS vulnerability report to be accepted, no PoC is required—you can just indicate the vulnerable software version used, with supporting evidence.

**CVE**
  1. When reporting a CVE-\d\d\d\d-[0-9]* vulnerability, please include a PoC and vulnerability description with references to authoritative sources such as MITRE.
  2. If you find a vulnerable version of a dependency, library, infrastructure software, and so on, specify the method used to determine the version, if possible.
  3. Vulnerability reports that do not include a PoC (except for DoS vulnerability reports) will not be accepted.


## Out-of-scope submissions
- 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), except for CSRF.


## Vulnerability disclosure policy
This program allows for the disclosure of discovered vulnerabilities **with the permission of the company's representative no sooner than 30 days after the report submission date**. The company also reserves the **right to refuse or indefinitely delay publication of the report** without explanation.

## Scope
- *.championat.com (Notes on special projects within the scope: Subdomains of the main project may host special projects with low criticality that are not included in the scope of this program. To verify whether a domain is within the program scope, you can check if its IP address falls within the range of the subnet 81.19.64.0/19. Reports on vulnerabilities found in domains with IP addresses from other subnets are accepted either without a reward or with a lower severity level assigned.)
- tickets.championat.com

Rambler&Co. Sport

Championat is a leading sports portal on the Runet. It provides the fastest and most complete coverage of all major events in the sports world, including high-quality exclusive content, analytics, detailed match statistics, photos and videos, and live broadcasts.

## 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.
- Be sure to 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, you must not proceed with lateral movement or post-exploitation.
- We accept reports of 0-day vulnerabilities if the vulnerabilities were publicly disclosed more than two weeks before the report submission.
- Reports of 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 from the host 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.
- The report must 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 amount        |
|-------------------|----------------------|
| Critical (9.9–10) | ₽500,000             |
| High (8.0–9.8)    | ₽35,000–₽150,000     |
| Medium (4.0–7.9)  | ₽5,000–₽35,000       |
| Low (0.1–3.9)     | Up to ₽5,000         |


## Severity scoring criteria
We classify vulnerabilities as critical only if they allow access to the corporate network. Therefore, we ask program participants to prove each instance of network penetration by receiving a response from https://rm.rambler-co.ru (10.99.2.223); the expected response from this host is 302.
In addition to that, attacks on Rambler ID resulting in a full leak of user accounts and data are also considered critical.
We rate the following attacks as high-severity:
		1. Attacks that lead to the compromise of a user account and require no more than a single action by the user for successful exploitation.		
2. Attacks that lead to the compromise of a high-privileged user account—in particular, stored XSS and cache poisoning.
		3. Attacks on users that lead to further attacks on id.rambler.ru.
	The severity of other attacks is determined based on their CVSS scores.


## Vulnerabilities
We prioritize the following critical vulnerabilities:
- RCE
- Injections
- SSRF
- LFI/RFI
- XXE


### Notes on reporting certain types of vulnerabilities
**XSS** 
  1. The severity of an XSS vulnerability can be rated as High only if it is a stored XSS vulnerability in internal services (such as the admin panel or support panel).
  2.  If you find several XSS vulnerabilities in the same forms and locations, but in different settings, describe them in a single report.
  3. It is highly appreciated when the report includes a video demonstrating vulnerability exploitation or a detailed description with screenshots.

**CRLF**
  1. Reports on CRLF vulnerabilities are accepted if they have a security impact other than setting of arbitrary cookies.
  2. If you set arbitrary HTTP headers, the attack vector described in the report must be realistic.
  3. If you inject HTML tags, it must be demonstrated right in the browser (simply providing the server response from Burp Suite or similar tools is not enough).

**DoS**
  1. DoS vulnerabilities must be reported as software vulnerabilities with a CVE identifier.
  2. For a DoS vulnerability report to be accepted, no PoC is required—you can just indicate the vulnerable software version used, with supporting evidence.

**CVE**
  1. When reporting a CVE-\d\d\d\d-[0-9]* vulnerability, please include a PoC and vulnerability description with references to authoritative sources such as MITRE.
  2. If you find a vulnerable version of a dependency, library, infrastructure software, and so on, specify the method used to determine the version, if possible.
  3. Vulnerability reports that do not include a PoC (except for DoS vulnerability reports) will not be accepted.


## Out-of-scope submissions
- 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), except for CSRF.



## Vulnerability disclosure policy
This program allows for the disclosure of discovered vulnerabilities **with the permission of the company's representative no sooner than 30 days after the report submission date**. The company also reserves the **right to refuse or indefinitely delay publication of the report** without explanation.

## Scope
- *.rambler.ru 
(Notes on special projects within the scope: Subdomains of the main project may host special projects with low criticality that are not included in the scope of this program. To verify whether a domain is within the program scope, you can check if its IP address falls within the range of the subnet 81.19.64.0/19 Reports on vulnerabilities found in domains with IP addresses from other subnets are accepted either without a reward or with a lower severity level assigned.)
- The scope does not include any domains within *.rambler.ru that contain *top100* as part of the domain name.

Rambler&Co. The Rambler portal: mail and news aggregator

Being a leading portal on the Runet, Rambler aggregates news, offers thematic media and entertainment content, and provides mail and other services. Its monthly audience amounts to tens of millions of users. It is part of the Rambler&Co media group.

## 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.
- Be sure to 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.
- 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, you must not proceed with lateral movement or post-exploitation.
- We accept reports of 0-day vulnerabilities if the vulnerabilities were publicly disclosed more than two weeks before the report submission.
- Reports of 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 from the host 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.
- The report must 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 amount        |
|-------------------|----------------------|
| Critical (9.9–10) | ₽500,000             |
| High (8.0–9.8)    | ₽35,000–₽150,000     |
| Medium (4.0–7.9)  | ₽5,000–₽35,000       |
| Low (0.1–3.9)     | Up to ₽5,000         |


## Severity scoring criteria
We classify vulnerabilities as critical only if they allow access to the corporate network. Therefore, we ask program participants to prove each instance of network penetration by receiving a response from https://rm.rambler-co.ru (10.99.2.223); the expected response from this host is 302.
In addition to that, attacks on Rambler ID resulting in a full leak of user accounts and data are also considered critical.
We rate the following attacks as high-severity:
		1. Attacks that lead to the compromise of a user account and require no more than a single action by the user for successful exploitation. 
		2. Attacks that lead to the compromise of a high-privileged user account—in particular, stored XSS and cache poisoning.
		3. Attacks on users that lead to further attacks on id.rambler.ru.
	The severity of other attacks is determined based on their CVSS scores.


## Vulnerabilities
We prioritize the following critical vulnerabilities:
- RCE
- Injections
- SSRF
- LFI/RFI
- XXE


### Notes on reporting certain types of vulnerabilities
**XSS** 
  1. The severity of an XSS vulnerability can be rated as High only if it is a stored XSS vulnerability in internal services (such as the admin panel or support panel).
  2.  If you find several XSS vulnerabilities in the same forms and locations, but in different settings, describe them in a single report.
  3. It is highly appreciated when the report includes a video demonstrating vulnerability exploitation or a detailed description with screenshots.

**CRLF**
  1. Reports on CRLF vulnerabilities are accepted if they have a security impact other than setting of arbitrary cookies.
  2. If you set arbitrary HTTP headers, the attack vector described in the report must be realistic.
  3. If you inject HTML tags, it must be demonstrated right in the browser (simply providing the server response from Burp Suite or similar tools is not enough).

**DoS**
  1. DoS vulnerabilities must be reported as software vulnerabilities with a CVE identifier.
  2. For a DoS vulnerability report to be accepted, no PoC is required—you can just indicate the vulnerable software version used, with supporting evidence.

**CVE**
  1. When reporting a CVE-\d\d\d\d-[0-9]* vulnerability, please include a PoC and vulnerability description with references to authoritative sources such as MITRE.
  2. If you find a vulnerable version of a dependency, library, infrastructure software, and so on, specify the method used to determine the version, if possible.
  3. Vulnerability reports that do not include a PoC (except for DoS vulnerability reports) will not be accepted.


## Out-of-scope submissions
- 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), except for CSRF.


## Vulnerability disclosure policy
This program allows for the disclosure of discovered vulnerabilities **with the permission of the company's representative no sooner than 30 days after the report submission date**. The company also reserves the **right to refuse or indefinitely delay publication of the report** without explanation.

## Scope

- *.Lenta.ru
- *.Gazeta.ru
- *.Moslenta.ru
- *.Secretmag.ru
- *.Ferra.ru
- *.Quto.ru
- *.Motor.ru
- *.Letidor.ru
- *.Wmj.ru
- *.Passion.ru

(Notes on special projects within the scope: Subdomains of the main projects may host special projects with low criticality that are not included in the scope of this program. To verify whether a domain is within the program scope, you can check if its IP address falls within the range of the subnet 81.19.64.0/19. Reports on vulnerabilities found in domains with IP addresses from other subnets are accepted either without a reward or with a lower severity level assigned.)

Rambler&Co. Main media assets

Rambler&Co ranks first among Russian media groups by monthly audience, with over 45.2 million visitors (according to Mediascope's Cross Web project for 2023). It includes Lenta.ru, Gazeta.Ru, the Rambler portal, Championat, Sekret Firmy ("The Firm's Secret"), Motor.ru, Ferra.ru, and other media assets. With its diverse range of topics and content, the group covers most interests and needs of various audiences.

## 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.
- Be sure to 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.
- 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, you must not proceed with lateral movement or post-exploitation.
- We accept reports of 0-day vulnerabilities if the vulnerabilities were publicly disclosed more than two weeks before the report submission.
- Reports of 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 from the host 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.
- The report must 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 amount        |
|-------------------|----------------------|
| Critical (9.9–10) | ₽500,000             |
| High (8.0–9.8)    | ₽35,000–₽150,000     |

## Severity scoring criteria
We classify vulnerabilities as critical only if they allow access to the corporate network. Therefore, we ask program participants to prove each instance of network penetration by receiving a response from https://rm.rambler-co.ru (10.99.2.223); the expected response from this host is 302.
We rate the following attacks as high-severity:
		1. Attacks that lead to the compromise of a user account and require no more than a single action by the user for successful exploitation. 
		2. Attacks that lead to the compromise of a high-privileged user account—in particular, stored XSS and cache poisoning.
	The severity of other attacks is determined based on their CVSS scores.


## Vulnerabilities
We prioritize the following critical vulnerabilities:
- RCE
- Injections
- SSRF
- LFI/RFI
- XXE

### Notes on reporting certain types of vulnerabilities
**XSS** 
  1. The severity of an XSS vulnerability can be rated as High only if it is a stored XSS vulnerability in internal services (such as the admin panel or support panel).
  2.  If you find several XSS vulnerabilities in the same forms and locations, but in different settings, describe them in a single report.
  3. It is highly appreciated when the report includes a video demonstrating vulnerability exploitation or a detailed description with screenshots.

**CRLF**
  1. Reports on CRLF vulnerabilities are accepted if they have a security impact other than setting of arbitrary cookies.
  2. If you set arbitrary HTTP headers, the attack vector described in the report must be realistic.
  3. If you inject HTML tags, it must be demonstrated right in the browser (simply providing the server response from Burp Suite or similar tools is not enough).

**DoS**
  1. DoS vulnerabilities must be reported as software vulnerabilities with a CVE identifier.
  2. For a DoS vulnerability report to be accepted, no PoC is required—you can just indicate the vulnerable software version used, with supporting evidence.

**CVE**
  1. When reporting a CVE-\d\d\d\d-[0-9]* vulnerability, please include a PoC and vulnerability description with references to authoritative sources such as MITRE.
  2. If you find a vulnerable version of a dependency, library, infrastructure software, and so on, specify the method used to determine the version, if possible.
  3. Vulnerability reports that do not include a PoC (except for DoS vulnerability reports) will not be accepted.

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-privileged accounts are targeted (for example, XSS in the admin panel)—will be considered, but no reward is provided for them.



## Out-of-scope submissions
- 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), except for CSRF.


## Vulnerability disclosure policy
This program allows for the disclosure of discovered vulnerabilities **with the permission of the company's representative no sooner than 30 days after the report submission date**. The company also reserves the **right to refuse or indefinitely delay publication of the report** without explanation.

## Scope
- www.livejournal.com

Rambler&Co. LiveJournal blogging platform

LiveJournal (LJ) is a blogging platform that allows users to keep an online journal or diary. On LiveJournal, you can publish posts and leave comments, maintain collective blogs (communities) as well as befriend other users and follow their posts through your friend feed.

Programs