# What reports and vulnerabilities are accepted
As part of the Bug Bounty program, we review reports of real vulnerabilities that may affect the security of the cloud platform services and K2 Cloud customer data.

### Priority
- Remote Code Execution (RCE);
- Injections (SQL, XML, SSTI, etc.);
- Reading or writing arbitrary files (LFI, RFI);
- SSRF (with demonstration of real impact);
- Access control vulnerabilities (IDOR, vertical/horizontal escalation);
- Authentication and authorization deficiencies;
- Business logic errors allowing bypass of financial/functional restrictions;
- Disclosure of sensitive or confidential information;
- Other vulnerabilities capable of affecting platform/data operation or security.

### Special attention
Critical scenarios related to gaining control over infrastructure, bypassing cloud isolation, accessing other customers' resources, violating service integrity and availability.
- - -
# Program scope
The program scope covers all resources that are part of the K2 Cloud platform:

### Web console for managing cloud resources
* [console.k2.cloud](https://console.k2.cloud)

### Cloud platform service domains
* autoscaling.ru-msk.k2.cloud
* autoscaling.ru-spb.k2.cloud
* backup.ru-msk.k2.cloud
* backup.ru-spb.k2.cloud
* cloudtrail.ru-msk.k2.cloud
* cloudtrail.ru-spb.k2.cloud
* cloudwatch.ru-msk.k2.cloud
* cloudwatch.ru-spb.k2.cloud
* directconnect.ru-msk.k2.cloud
* directconnect.ru-spb.k2.cloud
* ec2.ru-msk.k2.cloud
* ec2.ru-spb.k2.cloud
* efs.ru-msk.k2.cloud
* efs.ru-spb.k2.cloud
* eks.ru-msk.k2.cloud
* eks.ru-spb.k2.cloud
* elb.ru-msk.k2.cloud
* elb.ru-spb.k2.cloud
* ext.ru-msk.k2.cloud
* ext.ru-spb.k2.cloud
* iam.k2.cloud
* paas.ru-msk.k2.cloud
* paas.ru-spb.k2.cloud
* primary.k2.cloud
* route53.k2.cloud
* ru-msk.console.k2.cloud
* ru-spb.console.k2.cloud
* s3.ru-msk.k2.cloud
* s3.ru-spb.k2.cloud

The current [API reference and description](https://docs.k2.cloud/en/api/index.html) of platform services are always available on our [public documentation website](https://docs.k2.cloud/en/).

- - -
# What is not accepted within the program
Some categories of issues are not accepted within the K2 Cloud Bug Bounty program and are not subject of bounty.

### Findings without practical value
- automated reports from scanners and other tools, if no proof of manual vulnerability exploitation is provided;
- disclosure of non-confidential or publicly available information: software version, username, public profiles, image metadata, technical headers and parameters;
- messages about best-practices non-compliance (e.g., absence of certain HTTP headers or CSP/DMARC/SPF/DNSSEC settings) are not accepted as standalone vulnerabilities unless real security impact is demonstrated (e.g., possibility of clickjacking attack, email spoofing, etc.);
- messages about open ports, IP addresses, DNS records without practical exploit;
- vulnerabilities related only to product/protocol version (e.g., "OpenSSL X.Y.Z is used"), without real exploitation scenario;
- reports about "logical" or "UI" errors without security impact.

### Theoretical or impractical vulnerabilities
- Blind SSRF and open redirects if security impact is not demonstrated or possibility of exploitation for access to sensitive data is not shown;
- theoretical attacks not confirmed by practical Proof of Concept;
- problems related to demo stands, test environments, training domains and services if there is no threat to main infrastructure.

### Methods excluded from the program
- attacks affecting service availability (DoS, flood, spam, brute-force, performance tests, resource exhaustion);
- social engineering attacks (phishing, interaction with customers, partners or company employees);
- vulnerabilities requiring physical access, modified or compromised devices, etc.

### Other exclusions
- vulnerabilities in third-party services, client projects or external integrations that do not affect K2 Cloud platform security and its users
- problems related to absence of obfuscation or code reversal possibility without confirmed security impact;
- errors discovered by current or former company employees (within a year after dismissal);
- information obtained from public buckets in K2 Cloud;
- vulnerabilities of the 0-day and 1-day classes may be considered duplicates within several weeks after their public disclosure; the decision on reward payment is made individually and is not guaranteed.
- - -
# Testing rules and ethics
To ensure service security and proper program operation, follow these principles.

### Test responsibly
- use only your accounts or specially allocated test accounts;
- do not disrupt service operation, do not delete or modify other users' data;
- avoid actions that may lead to data loss, impact on other users or customers;
- do not do actions that may affect service availability for customers (DoS, flood, brute-force, etc.);
- do not use automated scanning tools with high intensity.

### Prohibited
- researching vulnerabilities in **K2 Cloud customer infrastructures**: this applies to all addresses in the form of \*.elastic.k2.cloud, s3.ru-msk.k2.cloud/\*, \*.website.ru-msk.k2.cloud, s3.ru-spb.k2.cloud/\* and \*.website.ru-spb.k2.cloud (however, you may investigate similar resources that you have created yourself);
- social engineering: phishing, spam, attempts to gain access through customers, partners or company employees;
- physical impact on equipment, offices, data centers and other company facilities;
- publishing or disclosing vulnerability information before they are fixed and without written consent from K2 Cloud;
- using discovered vulnerabilities for personal gain or bypassing tariff limitations.

### Restrictions on especially sensitive categories
- to confirm vulnerabilities like RCE, SQL injections, LFI/RFI, SSRF and other potentially dangerous bugs, use the minimal impact and safe exploits for Proof of Concept (e.g., sleep, reading /etc/passwd, request demonstration);
- for dangerous operations (privilege escalation, infrastructure interference) - coordinate actions with the K2 Cloud security team before testing at [bugbounty@k2.cloud](mailto:bugbounty@k2.cloud).

### Maintain confidentiality
- all information about discovered vulnerabilities must remain between the researcher and K2 Cloud security team until written permission for publication is obtained.

### Participation principles
- follow ethics and laws - your actions must comply with information security rules and applicable legislation;
- follow program conditions - review the rules before starting testing;
- respect team decisions - if you disagree, justify your position and provide evidence, we are open to dialogue;
- the final reward decision is made by the K2 Cloud team.
- - -
# Report formatting requirements
Reports are accepted exclusively on the Standoff365 platform. To expedite review of your request and increase your chances of receiving a reward, include in the report:
- **Vulnerability name and description**
- **Category**
- **CVE (if available)**
- **Criticality level analysis according to CVSS v3.1**
- **Address (or component) of the affected service**
- **Step-by-step exploitation scenario description:**
 - how the vulnerability was discovered;
 - what actions, parameters or conditions are needed for reproduction;
 - who and how can exploit the vulnerability.
- **Technical Proof of Concept (PoC):**
 - request/response examples, commands, scripts;
 - screenshots, video - if this helps verify the vulnerability (links to external sources are prohibited);
 - testing date and time.
- **Impact assessment:**
 - what data, services, users or infrastructure may be affected.
- **Remediation recommendations**
- **Your K2 Cloud account login (if used)**

> Each report should describe one vulnerability. If the exploit is built on a chain of vulnerabilities, you may include them in one report. In this case, the description must be made as clear as possible and all required information for each vulnerability must be indicated in the report. 
> Screen recording and screenshots are welcome but do not replace detailed textual description and PoC. 
> Reports without necessary data for reproduction may be returned for revision.

 Please ensure the report is structured and easy to read. Brief text error checking will make it more understandable and expedite review.
- - -
# Report processing and rewards
### Review process
- All reports are checked by the K2 Cloud security team.
- We usually provide the first response within **5 business days**.
- Full report review, validity determination and criticality level assessment usually takes up to **14 business days**.
- The decision on vulnerability seriousness, need for remediation and reward amount is made individually, considering: technical novelty, real impact level, exploitation complexity, affected services, potential mass impact and other factors.
- Rewards are paid only for the first valid reports on a specific vulnerability (duplicates are not paid).
- Vulnerabilities without confirmed security impact or with theoretical scenarios may be recognized as informative and remain unpaid.
- The reward amount is determined individually and depends on vulnerability seriousness and its security impact.
- Reward amount determination is carried out within **30 calendar days** after vulnerability validity confirmation and final report status establishment.
- In exceptional cases, review or payment timeframes may be increased, but in such cases we will definitely notify the researcher about reasons and estimated timelines.

### Reward amounts
|Vulnerability type|Reward range|Explanation|
|---|---|---|
|Remote Code Execution (RCE), access to internal infrastructure|150 000 — 500 000 ₽|Implies confirmed ability to execute arbitrary code on internal infrastructure servers of the cloud platform or gain access to internal services/networks. Theoretical scenarios and reports without PoC are not paid.|
|Server-side injections (SQLi, XML, SSTI, etc.)|50 000 — 200 000 ₽|Important are cases where the vulnerability leads to reading/changing data or system compromise. Reports based only on DBMS version or without confirmed data access are not paid.|
|Reading/writing arbitrary files (LFI, RFI, XXE)|50 000 — 150 000 ₽|Special attention is given to cases of accessing sensitive system or user files, or the ability to upload and execute files.|
|Privilege escalation (vertical or horizontal)|30 000 — 90 000 ₽|Horizontal - access to other users' data. Vertical - user → admin. Especially valuable are scenarios allowing management of others' resources or execution of admin functions.|
|Insecure Deserialization with confirmed impact|30 000 — 90 000 ₽|Only cases where the vulnerability leads to: - remote code execution (RCE); - privilege escalation or bypass of control mechanisms; - unauthorized access to confidential data; - manipulation of critical object attributes (e.g., role, access rights). Attacks leading exclusively to denial of service (DoS) are considered out of scope.|
|SSRF (with proven security impact)|20 000 — 60 000 ₽|The vulnerability must allow access to internal services, cloud metadata or perform malicious actions. Blind SSRF without demonstrated impact (e.g., without data leakage or filter bypass) is not paid.|
|Access control vulnerabilities, IDOR, disclosure of critical/confidential data|20 000 — 60 000 ₽|These include cases where one user can access data or operations of another. Information about access to public or insignificant data (e.g., nicknames) may be recognized as informative and remain unpaid.|
|Authentication and session management errors|20 000 — 60 000 ₽|Category includes login bypass, session fixation or theft, token compromise. Comments like "session lives too long" without exploit are not paid.|
|XSS (only with proven impact: token theft, action execution on behalf of user)|20 000 — 60 000 ₽|Important are substantial cases where, for example, XSS allows stealing tokens, executing actions on behalf of users or affecting sensitive data. Self-XSS or XSS affecting only the researcher is not paid.|
|CSRF (only if it affects critical functions)|20 000 — 60 000 ₽|Valuable are cases where the attack allows changing passwords, managing users and their rights, changing important service settings, billing parameters, etc. Logout CSRF or insignificant actions may be recognized as informative and remain unpaid.|
|Business logic errors, bypass of financial and functional restrictions|individually|Reward is determined individually as impact may be unique. Example: bypassing paid features or tariff restrictions.|
|Other confirmed vulnerabilities|individually|Main condition - real confirmed impact on user or infrastructure security.|

### How we determine criticality and reward amount
Vulnerability criticality assessment is conducted by the K2 Cloud security team and is always based on a combination of factors. After receiving a report, we consider not only technical details but also practical risk for customers and services. The analysis considers, among other things:
- how the vulnerability can affect user data and their availability;
- scale of the problem: does it affect one customer, a separate service, or infrastructure as a whole;
- level of preparation and conditions required for an attacker to exploit (e.g., presence of special rights or chains of multiple bugs);
- probability of discovery and attack repetition by other researchers or attackers;
- need for end-user involvement or possibility to automate the attack;
- possible business consequences, including reputational risks and customer trust.

This combination of criteria allows us to assess severity as objectively as possible and prioritize remediation.
For unification of assessment, we use **CVSS v3.1**, but the final decision is always made by the security team based on context and specifics of the particular case.

### How criticality relates to payouts
The rules of the program specify a reward range for each vulnerability category. The specific amount paid to the researcher depends on the vulnerability's criticality level:
- vulnerabilities with limited impact receive rewards closer to the lower range boundary;
- more serious problems that may affect multiple services or users are assessed in the middle of the range;
- the most dangerous cases (mass impact, critical business or customer damage) are rewarded closer to the upper range boundary.

> For some categories (e.g., **XSS** or **CSRF**) maximum impact is usually limited to the scope of a single user or session. In such cases, rewards are distributed within low and medium criticality levels, and the upper range limit applies only in the presence of truly non-standard impact (e.g., XSS in admin panel, bypass of protective mechanisms, or using XSS as part of a chain for a more serious attack).
 
The payout amount is directly related to the risk level of the discovered vulnerability.

### Duplicate handling rules
We pay a reward only for the first received report (provided it contains all the information necessary to reproduce the vulnerability). Any subsequent reports covering the same vulnerability will be marked as duplicates. Reports describing similar attack vectors may also be considered duplicates if our security team believes that information from a single report is sufficient to fix all possible attack vectors or issues.
The original report may be submitted either by an external researcher or be a description of the issue prepared by the K2 Cloud team.
- - -
# Technical details and support
### Access to K2 Cloud
To obtain access to a test account in K2 Cloud for research purposes:
1. Write to [bugbounty@k2.cloud](mailto:bugbounty@k2.cloud).
2. In the email, provide a link to your confirmed profile on the Standoff365 platform.
3. We will provide access and necessary consultations.

### Contacting the team
For questions about Bug Bounty participation, report formatting, or policy clarification, write to [bugbounty@k2.cloud](mailto:bugbounty@k2.cloud).
We are always open to constructive dialogue with researchers.

### Updating and changing rules
K2 Cloud reserves the right to change Bug Bounty program conditions, as well as report assessment criteria and payment procedures without prior notice.
- - -
# Let's make K2 Cloud safer together
We thank everyone who helps make K2 Cloud safer and more reliable for customers!

Your research is valued, and we are ready to cooperate honestly and openly with everyone interested in real improvement of information security level of our services.

All questions, wishes and suggestions for program development are accepted at [bugbounty@k2.cloud](mailto:bugbounty@k2.cloud).

K2 Cloud

[K2 Cloud](https://k2.cloud/) is a cloud provider with integrator expertise. We build and protect cloud infrastructure for our customers and strive to deliver the highest possible service reliability.
To make our cloud platform even more secure, we are launching a Bug Bounty program and invite information security professionals to collaborate with us in identifying vulnerabilities.

[K2 Cloud](https://k2.cloud/) is a cloud provider with integrator expertise. We build and protect cloud infrastructure for our customers and strive to deliver the highest possible service reliability.
To make our cloud platform even more secure, we are launching a Bug Bounty program and invite information security professionals to collaborate with us in identifying vulnerabilities.

Programs