K2 Cloud
Bounty Range
Up to $6,000
external program
K2 Cloud
[/en-US/vendors/k2cloud](Company: K2 Cloud)
[https://k2.cloud/](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.
Submit report Rewards are paid to individual entrepreneurs and self-employed persons
Description Vulnerabilities Ranking Versions
Latest changes
Program description
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.
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.
Critical scenarios related to gaining control over infrastructure, bypassing cloud isolation, accessing other customers' resources, violating service integrity and availability.
The program scope covers all resources that are part of the K2 Cloud platform:
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 [https://docs.k2.cloud/en/api/index.html](API reference and description) of platform services are always available on our [https://docs.k2.cloud/en/](public documentation website).
Some categories of issues are not accepted within the K2 Cloud Bug Bounty program and are not subject of bounty.
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.
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.
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.
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.
To ensure service security and proper program operation, follow these principles.
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.
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.
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 mailto:[email protected].
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.
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.
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.
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:
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. |
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.
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.
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.
To obtain access to a test account in K2 Cloud for research purposes:
Write to mailto:[email protected].
In the email, provide a link to your confirmed profile on the Standoff365 platform.
We will provide access and necessary consultations.
For questions about Bug Bounty participation, report formatting, or policy clarification, write to mailto:[email protected].
We are always open to constructive dialogue with researchers.
K2 Cloud reserves the right to change Bug Bounty program conditions, as well as report assessment criteria and payment procedures without prior notice.
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 mailto:[email protected].
Launched September 1, 2025 Edited March 19, 12:46
Program format Vulnerabilities
Reward for vulnerabilities
up to ₽500K
[https://standoff365.com/en-US/regulation-on-contests#reward](Excl. tax)
Top hackers Overall ranking) Score
[https://standoff365.com/en-US/profile/byq](
@byq Anton
)5K
[https://standoff365.com/en-US/profile/Casual](
@Casual
)4.7K
[https://standoff365.com/en-US/profile/Zenmovie](
@Zenmovie
)1.5K
Program statistics ₽296,000 Paid in total
₽37,000 Average payment
₽154,000 Paid in the last 90 days
43 Valid reports
105 Submitted reports
Description Vulnerabilities Ranking Versions
Description
Submit report